A question about git-rev-list

Hi,

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?  I _think_ --remove-empty might be
necessary for that option, but have no idea whether this hunch is
correct.  Do I need additional options like --topo-order, or is that
unnecessary?

Thanks,

-- 
David Kastrup

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.

No amount of flags will change that. Of course, B might not show up 
for _other_ reasons (ie simply because it doesn't change "filename" at 
all), but generally you must always think of git-rev-list (and git log) as 
a _set_ operation.

There are no git operations that will look for "chain of commits from C to 
D" if that is what you want. No such chain necessarily even exists, and 
quite often it is ambiguous when it *does* exist (ie there is not a single 
chain from A to D, there are two chains).

You could add some kind of function that looks for the "shortest chain of 
commits from X to Y", but that would really be something fundamentally 
different from what git-rev-list gives you.

			Linus