rev-list: stop when the file disappears
authorLinus Torvalds <torvalds@osdl.org>
Wed, 18 Jan 2006 22:47:30 +0000 (14:47 -0800)
committerJunio C Hamano <junkio@cox.net>
Sat, 28 Jan 2006 08:08:38 +0000 (00:08 -0800)
commit461cf59f8924f174d7a0dcc3d77f576d93ed29a4
tree0ad53270720a087ca68ba1837a12c403c5c07b9b
parent6b94f1e404afc552e5139c4357331843f5be61ad
rev-list: stop when the file disappears

The one thing I've considered doing (I really should) is to add a "stop
when you don't find the file" option to "git-rev-list". This patch does
some of the work towards that: it removes the "parent" thing when the
file disappears, so a "git annotate" could do do something like

git-rev-list --remove-empty --parents HEAD -- "$filename"

and it would get a good graph that stops when the filename disappears
(it's not perfect though: it won't remove all the unintersting commits).

It also simplifies the logic of finding tree differences a bit, at the
cost of making it a tad less efficient.

The old logic was two-phase: it would first simplify _only_ merges tree as
it traversed the tree, and then simplify the linear parts of the remainder
independently. That was pretty optimal from an efficiency standpoint
because it avoids doing any comparisons that we can see are unnecessary,
but it made it much harder to understand than it really needed to be.

The new logic is a lot more straightforward, and compares the trees as it
traverses the graph (ie everything is a single phase). That makes it much
easier to stop graph traversal at any point where a file disappears.

As an example, let's say that you have a git repository that has had a
file called "A" some time in the past. That file gets renamed to B, and
then gets renamed back again to A. The old "git-rev-list" would show two
commits: the commit that renames B to A (because it changes A) _and_ as
its parent the commit that renames A to B (because it changes A).

With the new --remove-empty flag, git-rev-list will show just the commit
that renames B to A as the "root" commit, and stop traversal there
(because that's what you want for "annotate" - you want to stop there, and
for every "root" commit you then separately see if it really is a new
file, or if the paths history disappeared because it was renamed from some
other file).

With this patch, you should be able to basically do a "poor mans 'git
annotate'" with a fairly simple loop:

push("HEAD", "$filename")
while (revision,filename = pop()) {
for each i in $(git-rev-list --parents --remove-empty $revision -- "$filename")

pseudo-parents($i) = git-rev-list parents for that line

if (pseudo-parents($i) is non-empty) {
show diff of $i against pseudo-parents
continue
}

/* See if the _real_ parents of $i had a rename */
parent($i) = real-parent($i)
if (find-rename in $parent($i)->$i)
push $parent($i), "old-name"
}

which should be doable in perl or something (doing stacks in shell is just
too painful to be worth it, so I'm not going to do this).

Anybody want to try?

Linus
rev-list.c