1. 18 Aug, 2010 2 commits
  2. 22 Feb, 2010 1 commit
    • Linus Torvalds's avatar
      Move 'builtin-*' into a 'builtin/' subdirectory · 81b50f3c
      Linus Torvalds authored
      This shrinks the top-level directory a bit, and makes it much more
      pleasant to use auto-completion on the thing. Instead of
      
      	[torvalds@nehalem git]$ em buil<tab>
      	Display all 180 possibilities? (y or n)
      	[torvalds@nehalem git]$ em builtin-sh
      	builtin-shortlog.c     builtin-show-branch.c  builtin-show-ref.c
      	builtin-shortlog.o     builtin-show-branch.o  builtin-show-ref.o
      	[torvalds@nehalem git]$ em builtin-shor<tab>
      	builtin-shortlog.c  builtin-shortlog.o
      	[torvalds@nehalem git]$ em builtin-shortlog.c
      
      you get
      
      	[torvalds@nehalem git]$ em buil<tab>		[type]
      	builtin/   builtin.h
      	[torvalds@nehalem git]$ em builtin		[auto-completes to]
      	[torvalds@nehalem git]$ em builtin/sh<tab>	[type]
      	shortlog.c     shortlog.o     show-branch.c  show-branch.o  show-ref.c     show-ref.o
      	[torvalds@nehalem git]$ em builtin/sho		[auto-completes to]
      	[torvalds@nehalem git]$ em builtin/shor<tab>	[type]
      	shortlog.c  shortlog.o
      	[torvalds@nehalem git]$ em builtin/shortlog.c
      
      which doesn't seem all that different, but not having that annoying
      break in "Display all 180 possibilities?" is quite a relief.
      
      NOTE! If you do this in a clean tree (no object files etc), or using an
      editor that has auto-completion rules that ignores '*.o' files, you
      won't see that annoying 'Display all 180 possibilities?' message - it
      will just show the choices instead.  I think bash has some cut-off
      around 100 choices or something.
      
      So the reason I see this is that I'm using an odd editory, and thus
      don't have the rules to cut down on auto-completion.  But you can
      simulate that by using 'ls' instead, or something similar.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      81b50f3c
  3. 05 Aug, 2009 1 commit
  4. 25 May, 2009 1 commit
  5. 03 Oct, 2008 1 commit
  6. 30 Jul, 2008 1 commit
  7. 29 Jul, 2008 1 commit
  8. 13 Jul, 2008 1 commit
    • Stephan Beyer's avatar
      Make usage strings dash-less · 1b1dd23f
      Stephan Beyer authored
      When you misuse a git command, you are shown the usage string.
      But this is currently shown in the dashed form.  So if you just
      copy what you see, it will not work, when the dashed form
      is no longer supported.
      
      This patch makes git commands show the dash-less version.
      
      For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
      generates a dash-less usage string now.
      Signed-off-by: default avatarStephan Beyer <s-beyer@gmx.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1b1dd23f
  9. 14 May, 2008 1 commit
  10. 15 Jul, 2007 1 commit
  11. 10 Jan, 2007 1 commit
  12. 20 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      simplify inclusion of system header files. · 85023577
      Junio C Hamano authored
      This is a mechanical clean-up of the way *.c files include
      system header files.
      
       (1) sources under compat/, platform sha-1 implementations, and
           xdelta code are exempt from the following rules;
      
       (2) the first #include must be "git-compat-util.h" or one of
           our own header file that includes it first (e.g. config.h,
           builtin.h, pkt-line.h);
      
       (3) system headers that are included in "git-compat-util.h"
           need not be included in individual C source files.
      
       (4) "git-compat-util.h" does not have to include subsystem
           specific header files (e.g. expat.h).
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      85023577
  13. 16 Aug, 2006 1 commit
  14. 02 Jul, 2006 1 commit
  15. 29 Jun, 2006 2 commits
  16. 17 May, 2006 1 commit
  17. 08 May, 2006 1 commit
  18. 24 Mar, 2006 1 commit
  19. 29 Nov, 2005 1 commit
  20. 11 Nov, 2005 2 commits
  21. 24 Aug, 2005 1 commit
  22. 12 Aug, 2005 2 commits
    • Junio C Hamano's avatar
      merge-base.c: pathological case fix. · b4ad66b7
      Junio C Hamano authored
      Also add some illustration requested by Linus.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      b4ad66b7
    • Linus Torvalds's avatar
      [PATCH] Speed up git-merge-base a lot · 0b9442d6
      Linus Torvalds authored
      In commit 4f7eb2e5 I fixed git-merge-base
      getting confused by datestamps that caused it to traverse things in a
      non-obvious order.
      
      However, my fix was a very brute-force one, and it had some really
      horrible implications for more complex trees with lots of parallell
      development. It might end up traversing all the way to the root commit.
      
      Now, normally that isn't that horrible: it's used mainly for merging, and
      the bad cases really tend to happen fairly rarely, so if it takes a few
      seconds, we're not in too bad shape.
      
      However, gitk will also do the git-merge-base for every merge it shows,
      because it basically re-does the trivial merge in order to show the
      "interesting" parts. And there we'd really like the result to be
      instantaneous.
      
      This patch does that by walking the tree more completely, and using the
      same heuristic as git-rev-list to decide "ok, the rest is uninteresting".
      
      In one - hopefully fairly extreme - case, it made a git-merge-base go from
      just under five seconds(!) to a tenth of a second on my machine.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      0b9442d6
  23. 31 Jul, 2005 1 commit
    • Linus Torvalds's avatar
      Fix merge-base from getting confused. · 4f7eb2e5
      Linus Torvalds authored
      On Sat, 30 Jul 2005, Linus Torvalds wrote:
      > 
      > Yup, it's git-merge-base, and it is confused by the same thing that 
      > confused git-rev-list.
      
      Hmm.. Here's a tentative fix. I'm not really happy with it, and maybe
      somebody else can come up with a better one. I think this one ends up
      being quite a bit more expensive than the old one (it will look up _all_
      common parents that have a child that isn't common, and then select the
      newest one of the bunch), but I haven't really thought it through very
      much.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4f7eb2e5
  24. 20 May, 2005 1 commit
    • Linus Torvalds's avatar
      sparse cleanup · e99d59ff
      Linus Torvalds authored
      Fix various things that sparse complains about:
       - use NULL instead of 0
       - make sure we declare everything properly, or mark it static
       - use proper function declarations ("fn(void)" instead of "fn()")
      
      Sparse is always right.
      e99d59ff
  25. 19 May, 2005 1 commit
  26. 18 May, 2005 1 commit
  27. 01 May, 2005 1 commit
    • Linus Torvalds's avatar
      Add "get_sha1()" helper function. · 3c249c95
      Linus Torvalds authored
      This allows the programs to use various simplified versions of
      the SHA1 names, eg just say "HEAD" for the SHA1 pointed to by
      the .git/HEAD file etc.
      
      For example, this commit has been done with
      
      	git-commit-tree $(git-write-tree) -p HEAD
      
      instead of the traditional "$(cat .git/HEAD)" syntax.
      3c249c95
  28. 24 Apr, 2005 2 commits
  29. 18 Apr, 2005 1 commit
  30. 17 Apr, 2005 2 commits