Re: A question about git-rev-list

Linus Torvalds [off-list ref] writes:

On Mon, 16 Jul 2007, David Kastrup wrote:

quoted

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