Re: A question about git-rev-list

From: David Kastrup <dak@gnu.org>
Date: Jul 16, 2007, 21:16 UTC
Message-ID: <85bqecm4mn.fsf@lola.goethe.zz>
In-Reply-To: <alpine.LFD.0.999.0707161258560.20061@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 29 quoted lines

> On Mon, 16 Jul 2007, David Kastrup wrote:
>> 
>> if I do
>> 
>> git-rev-list --remove-empty HEAD --not some-commit -- filename | tail -1
>> 
>> do I have any guarantee that the commit id I get (if any) is a direct
>> descendant of some-commit?
>
> No. You get the guarantee that
>
>  - it's some kind of parent of HEAD
>  - it's *not* a parent of some-commit
>
> But the trivial case is a simple history like
>
> 	 /-B-\
> 	A     D
>        \-C-/
>
> (where "A" is the root commit, and "D" is the current HEAD, and there are 
> two development lines from A to  D).
>
> If you now do
>
> 	git-rev-list HEAD --not C
>
> you would generally see B on the list of commits, even though it's 
> obviously not a direct descendant of C.

Ok, thanks. As explained in a different posting, I try to tackle this now with the equivalent of

git-rev-list HEAD --parents --not B -- somefile.c | awk '/ B/{print $1}'

This will give me one descendant if there is one. The problem I have with that is that "somefile.c" renders commits uninteresting, but not if they have interesting parents (what do their parents have to do with it?). So if I have

A -> B -> B1 -> C -> HEAD

where somefile.c does not change between B and B1, then git-rev-list HEAD --not B -- somefile.c spews out HEAD C and that's it. Quite as expected. However, git-rev-list HEAD --not B --parents -- somefile.c spews out HEAD C C B1 B1 B

and look and behold, B1 became interesting because of its unlisted parent B.

There is something wrong with that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum