1. 28 12月, 2005 1 次提交
    • L
      Add a "git-describe" command · 908e5310
      Linus Torvalds 提交于
      It shows you the most recent tag that is reachable from a particular
      commit is.
      
      Maybe this is something that "git-name-rev" should be taught to do,
      instead of having a separate command for it. Regardless, I find it useful.
      
      What it does is to take any random commit, and "name" it by looking up the
      most recent commit that is tagged and reachable from that commit. If the
      match is exact, it will just print out that ref-name directly. Otherwise
      it will print out the ref-name, followed by the 8-character "short SHA".
      
      IOW, with something like Junios current tree, I get:
      
      	[torvalds@g5 git]$ git-describe parent
      	refs/tags/v1.0.4-g2414721b
      
      ie the current head of my "parent" branch (ie Junio) is based on v1.0.4,
      but since it has a few commits on top of that, it has added the git hash
      of the thing to the end: "-g" + 8-char shorthand for the commit
      2414721b.
      
      Doing a "git-describe" on a tag-name will just show the full tag path:
      
      	[torvalds@g5 git]$ git-describe v1.0.4
      	refs/tags/v1.0.4
      
      unless there are _other_ tags pointing to that commit, in which case it
      will just choose one at random.
      
      This is useful for two things:
      
       - automatic version naming in Makefiles, for example. We could use it in
         git itself: when doing "git --version", we could use this to give a
         much more useful description of exactly what version was installed.
      
       - for any random commit (say, you use "gitk <pathname>" or
         "git-whatchanged" to look at what has changed in some file), you can
         figure out what the last version of the repo was. Ie, say I find a bug
         in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do:
      
      	[torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6
      	refs/tags/v2.6.14-rc4-g39ca371c
      
         and I now know that it was _not_ in v2.6.14-rc4, but was presumably in
         v2.6.14-rc5.
      
      The latter is useful when you want to see what "version timeframe" a
      commit happened in.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      908e5310
  2. 23 12月, 2005 1 次提交
  3. 22 12月, 2005 3 次提交
    • J
      Versioning scheme changes. · c8941686
      Junio C Hamano 提交于
      HPA suggests it is simply silly to imitate Linux versioning
      scheme where the leading "2" does not mean anything anymore, and
      I tend to agree.
      
      The first feature release after 1.0.0 will be 1.1.0, and the
      development path leading to 1.1.0 will carry 1.0.GIT as the
      version number from now on.  Similarly, the third maintenance
      release that follows 1.0.0 will not be 1.0.0c as planned, but
      will be called 1.0.3.  The "maint" branch will merge in fixes
      and immediately tagged, so there is no need for 1.0.2.GIT that
      is in between 1.0.2 (aka 1.0.0b) and 1.0.3.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c8941686
    • J
      GIT 1.0.0a · e4e79a21
      Junio C Hamano 提交于
          - Avoid misleading success message on error (Johannes)
          - objects/info/packs: work around bug in http-fetch.c::fetch_indices()
          - http-fetch.c: fix objects/info/pack parsing.
          - An off-by-one bug found by valgrind (Pavel)
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      e4e79a21
    • J
      Post 1.0.0 development track. · 5d9d11db
      Junio C Hamano 提交于
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      5d9d11db
  4. 20 12月, 2005 2 次提交
  5. 18 12月, 2005 1 次提交
    • J
      fetch-pack: -k option to keep downloaded pack. · ad897215
      Junio C Hamano 提交于
      Split out the functions that deal with the socketpair after
      finishing git protocol handshake to receive the packed data into
      a separate file, and use it in fetch-pack to keep/explode the
      received pack data.  We earlier had something like that on
      clone-pack side once, but the list discussion resulted in the
      decision that it makes sense to always keep the pack for
      clone-pack, so unpacking option is not enabled on the clone-pack
      side, but we later still could do so easily if we wanted to with
      this change.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      ad897215
  6. 15 12月, 2005 1 次提交
  7. 07 12月, 2005 1 次提交
  8. 06 12月, 2005 1 次提交
    • J
      Clean up compatibility definitions. · 4050c0df
      Junio C Hamano 提交于
      This attempts to clean up the way various compatibility
      functions are defined and used.
      
       - A new header file, git-compat-util.h, is introduced.  This
         looks at various NO_XXX and does necessary function name
         replacements, equivalent of -Dstrcasestr=gitstrcasestr in the
         Makefile.
      
       - Those function name replacements are removed from the Makefile.
      
       - Common features such as usage(), die(), xmalloc() are moved
         from cache.h to git-compat-util.h; cache.h includes
         git-compat-util.h itself.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4050c0df
  9. 04 12月, 2005 1 次提交
    • J
      Add compat/setenv.c, use in git.c. · e40b61fb
      Jason Riedy 提交于
      There is no setenv() in Solaris 5.8.  The trivial calls to
      setenv() were replaced by putenv() in a much earlier patch,
      but setenv() was used again in git.c.  This patch just adds
      a compat/setenv.c.
      
      The rule for building git$(X) also needs to include compat.
      objects and compiler flags.  Those are now in makefile vars
      COMPAT_OBJS and COMPAT_CFLAGS.
      Signed-off-by: NE. Jason Riedy <ejr@cs.berkeley.edu>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      e40b61fb
  10. 02 12月, 2005 1 次提交
  11. 01 12月, 2005 1 次提交
  12. 25 11月, 2005 1 次提交
  13. 22 11月, 2005 2 次提交
  14. 21 11月, 2005 1 次提交
  15. 20 11月, 2005 3 次提交
  16. 19 11月, 2005 1 次提交
  17. 18 11月, 2005 1 次提交
  18. 17 11月, 2005 1 次提交
  19. 16 11月, 2005 2 次提交
    • A
      C implementation of the 'git' program, take two. · 8e49d503
      Andreas Ericsson 提交于
      This patch provides a C implementation of the 'git' program and
      introduces support for putting the git-* commands in a directory
      of their own. It also saves some time on executing those commands
      in a tight loop and it prints the currently available git commands
      in a nicely formatted list.
      
      The location of the GIT_EXEC_PATH (name discussion's closed, thank gods)
      can be obtained by running
      
      	git --exec-path
      
      which will hopefully give porcelainistas ample time to adapt their
      heavy-duty loops to call the core programs directly and thus save
      the extra fork() / execve() overhead, although that's not really
      necessary any more.
      
      The --exec-path value is prepended to $PATH, so the git-* programs
      should Just Work without ever requiring any changes to how they call
      other programs in the suite.
      
      Some timing values for 10000 invocations of git-var >&/dev/null:
      	git.sh: 24.194s
      	git.c:   9.044s
      	git-var: 7.377s
      
      The git-<tab><tab> behaviour can, along with the someday-to-be-deprecated
      git-<command> form of invocation, be indefinitely retained by adding
      the following line to one's .bash_profile or equivalent:
      
      	PATH=$PATH:$(git --exec-path)
      
      Experimental libraries can be used by either setting the environment variable
      GIT_EXEC_PATH, or by using
      
      	git --exec-path=/some/experimental/exec-path
      
      Relative paths are properly grok'ed as exec-path values.
      Signed-off-by: NAndreas Ericsson <ae@op5.se>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      8e49d503
    • J
      diff: make default rename detection limit configurable. · 3299c6f6
      Junio C Hamano 提交于
      A while ago, a rename-detection limit logic was implemented as a
      response to this thread:
      
      	http://marc.theaimsgroup.com/?l=git&m=112413080630175
      
      where gitweb was found to be using a lot of time and memory to
      detect renames on huge commits.  git-diff family takes -l<num>
      flag, and if the number of paths that are rename destination
      candidates (i.e. new paths with -M, or modified paths with -C)
      are larger than that number, skips rename/copy detection even
      when -M or -C is specified on the command line.
      
      This commit makes the rename detection limit easier to use.  You
      can have:
      
      	[diff]
      		renamelimit = 30
      
      in your .git/config file to specify the default rename detection
      limit.  You can override this from the command line; giving 0
      means 'unlimited':
      
      	git diff -M -l0
      
      We might want to change the default behaviour, when you do not
      have the configuration, to limit it to say 20 paths or so.  This
      would also help the diffstat generation after a big 'git pull'.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      3299c6f6
  20. 15 11月, 2005 1 次提交
  21. 14 11月, 2005 2 次提交
  22. 13 11月, 2005 1 次提交
  23. 12 11月, 2005 3 次提交
  24. 08 11月, 2005 1 次提交
  25. 07 11月, 2005 1 次提交
  26. 06 11月, 2005 3 次提交
  27. 04 11月, 2005 1 次提交
    • J
      Add 'ours' merge strategy. · 64da9e60
      Junio C Hamano 提交于
      This adds the coolest merge strategy ever, "ours".  It can take
      arbitrary number of foreign heads and merge them into the
      current branch, with the resulting tree always taken from our
      branch head, hence its name.
      
      What this means is that you can declare that the current branch
      supersedes the development histories of other branches using
      this merge strategy.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      64da9e60
  28. 03 11月, 2005 1 次提交