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
-
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
