Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 04 4月, 2006 4 次提交
  3. 03 4月, 2006 5 次提交
  5. 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
  9. 31 3月, 2006 8 次提交
  11. 30 3月, 2006 6 次提交
  13. 29 3月, 2006 2 次提交
    • J
      rev-list --boundary · 384e99a4
      由 Junio C Hamano 提交于 
      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 ...
        \0
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      384e99a4
    • J
      rev-list: memory usage reduction. · 9181ca2c
      由 Junio C Hamano 提交于 
      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: NJunio C Hamano <junkio@cox.net>
Acked-by: NLinus Torvalds <torvalds@osdl.org>
      9181ca2c
  15. 28 3月, 2006 5 次提交
    • J
      rev-list --no-merges: argument parsing fix. · 5cdeae71
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      5cdeae71
    • M
      xdiff: Show function names in hunk headers. · acb72577
      由 Mark Wooding 提交于 
      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: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      acb72577
    • J
      Add ALL_LDFLAGS to the git target. · 9c48666a
      由 Jason Riedy 提交于 
      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: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9c48666a
    • J
      GIT 1.3.0 rc1 · dff86e28
      由 Junio C Hamano 提交于 
      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: NJunio C Hamano <junkio@cox.net>
      dff86e28
    • J
      Merge branch ak/svn · 65b5e41e
      由 Junio C Hamano 提交于
      65b5e41e
  17. 27 3月, 2006 1 次提交