Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
