1. 04 Apr, 2006 5 commits
  2. 03 Apr, 2006 2 commits
    • Jim Radford's avatar
      fix repacking with lots of tags · 40e907bf
      Jim Radford authored
      Use git-rev-list's --all instead of git-rev-parse's to keep from
      hitting the shell's argument list length limits when repacking
      with lots of tags.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • J. Bruce Fields's avatar
      Documentation: revise top of git man page · 23091e95
      J. Bruce Fields authored
      I'm afraid I'll be accused of trying to suck all the jokes and the
      personality out of the git documentation.  I'm not!  Really!
      That said, "man git" is one of the first things a new user is likely try,
      and it seems a little cruel to start off with a somewhat obscure joke
      about the architecture of git.
      So instead I'm trying for a relatively straightforward description of what
      git does, and what features distinguish it from other systems, together
      with immediate links to introductory documentation.
      I also did some minor reorganization in an attempt to clarify the
      classification of commands.  And revised a bit for conciseness (as is
      obvious from the diffstat--hopefully I didn't cut anything important).
      Signed-off-by: default avatarJ. Bruce Fields <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 02 Apr, 2006 9 commits
  4. 01 Apr, 2006 3 commits
    • Linus Torvalds's avatar
      Make path-limiting be incremental when possible. · 2a0925be
      Linus Torvalds authored
      This makes git-rev-list able to do path-limiting without having to parse
      all of history before it starts showing the results.
      This makes things like "git log -- pathname" much more pleasant to use.
      This is actually a pretty small patch, and the biggest part of it is
      purely cleanups (turning the "goto next" statements into "continue"), but
      it's conceptually a lot bigger than it looks.
      What it does is that if you do a path-limited revision list, and you do
      _not_ ask for pseudo-parenthood information, it won't do all the
      path-limiting up-front, but instead do it incrementally in
      This is an absolutely huge deal for anything like "git log -- <pathname>",
      but also for some things that we don't do yet - like the "find where
      things changed" logic I've described elsewhere, where we want to find the
      previous revision that changed a file.
      The reason I put "RFC" in the subject line is that while I've validated it
      various ways, like doing
      	git-rev-list HEAD -- drivers/char/ | md5sum
      before-and-after on the kernel archive, it's "git-rev-list" after all. In
      other words, it's that really really subtle and complex central piece of
      software. So while I think this is important and should go in asap, I also
      think it should get lots of testing and eyeballs looking at the code.
      Btw, don't even bother testing this with the git archive. git itself is so
      small that parsing the whole revision history for it takes about a second
      even with path limiting. The thing that _really_ shows this off is doing
      	git log drivers/
      on the kernel archive, or even better, on the _historic_ kernel archive.
      With this change, the response is instantaneous (although seeking to the
      end of the result will obviously take as long as it ever did). Before this
      change, the command would think about the result for tens of seconds - or
      even minutes, in the case of the bigger old kernel archive - before
      starting to output the results.
      NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
      the "--parents" flag to actually generate a pseudo-history of the
      resulting commits won't actually see the improvement in interactivity,
      since that forces git-rev-list to do the whole-history thing after all.
      MAYBE we can fix that too at some point, but I won't promise anything.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Linus Torvalds's avatar
      Move "--parent" parsing into generic revision.c library code · 7b0c9966
      Linus Torvalds authored
      Not only do we do it in both rev-list.c and git.c, the revision walking
      code will soon want to know whether we should rewrite parenthood
      information or not.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Makefile: many programs now depend on xdiff/lib.a having been built. · 8eef8e09
      Junio C Hamano authored
      The dependency was not properly updated when we added this
      library, breaking parallel build with $(MAKE) -j.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  5. 31 Mar, 2006 2 commits
  6. 30 Mar, 2006 12 commits
  7. 29 Mar, 2006 2 commits
    • Junio C Hamano's avatar
      rev-list --boundary · 384e99a4
      Junio C Hamano authored
      With the new --boundary flag, the output from rev-list includes
      the UNINTERESING commits at the boundary, which are usually not
      shown.  Their object names are prefixed with '-'.
      For example, with this graph:
                    C side
      	A---B---D master
      You would get something like this:
      	$ git rev-list --boundary --header --parents side..master
      	D B
              tree D^{tree}
              parent B
              ... log message for commit D here ...
              \0-B A
              tree B^{tree}
              parent A
              ... log message for commit B here ...
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      rev-list: memory usage reduction. · 9181ca2c
      Junio C Hamano authored
      We do not need to track object refs, neither we need to save commit
      unless we are doing verbose header.  A lot of traversal happens
      inside prepare_revision_walk() these days so setting things up before
      calling that function is necessary.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      Acked-by: default avatarLinus Torvalds <[email protected]>
  8. 28 Mar, 2006 5 commits
    • Junio C Hamano's avatar
    • Mark Wooding's avatar
      xdiff: Show function names in hunk headers. · acb72577
      Mark Wooding authored
      The speed of the built-in diff generator is nice; but the function names
      shown by `diff -p' are /really/ nice.  And I hate having to choose.  So,
      we hack xdiff to find the function names and print them.
      xdiff has grown a flag to say whether to dig up the function names.  The
      builtin_diff function passes this flag unconditionally.  I suppose it
      could parse GIT_DIFF_OPTS, but it doesn't at the moment.  I've also
      reintroduced the `function name' into the test suite, from which it was
      removed in commit 3ce8f089.
      The function names are parsed by a particularly stupid algorithm at the
      moment: it just tries to find a line in the `old' file, from before the
      start of the hunk, whose first character looks plausible.  Still, it's
      most definitely a start.
      Signed-off-by: default avatarMark Wooding <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Jason Riedy's avatar
      Add ALL_LDFLAGS to the git target. · 9c48666a
      Jason Riedy authored
      For some reason, I need ALL_LDFLAGS in the git target only on
      AIX.  Once it builds, only one test "fails" on AIX 5.1 with
      1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
      odd tool problem in the tester + my setup and not a real bug.
      Signed-off-by: default avatarJason Riedy <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      GIT 1.3.0 rc1 · dff86e28
      Junio C Hamano authored
      All of the things that were not in the "master" branch were
      either cooked long enough in "next" without causing problems
      (e.g. insanely fast rename detector or true built-in diff) or
      isolated in a specific subsystem (e.g. tar-tree and svnimport).
      So I am clearing the deck to prepare for a 1.3.0.  Remaining
      wrinkles, if any, will be ironed in the "master" branch.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Merge branch ak/svn · 65b5e41e
      Junio C Hamano authored