1. 07 4月, 2006 2 次提交
  2. 06 4月, 2006 2 次提交
  3. 05 4月, 2006 8 次提交
  4. 04 4月, 2006 8 次提交
  5. 03 4月, 2006 7 次提交
  6. 02 4月, 2006 6 次提交
  7. 01 4月, 2006 3 次提交
    • L
      Make path-limiting be incremental when possible. · 2a0925be
      Linus Torvalds 提交于
      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
      "get_revision()".
      
      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: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      2a0925be
    • L
      Move "--parent" parsing into generic revision.c library code · 7b0c9966
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      7b0c9966
    • J
      Makefile: many programs now depend on xdiff/lib.a having been built. · 8eef8e09
      Junio C Hamano 提交于
      The dependency was not properly updated when we added this
      library, breaking parallel build with $(MAKE) -j.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      8eef8e09
  8. 31 3月, 2006 4 次提交