On Sun, 25 May 2008, Johannes Sixt wrote:
>
> But why does this:
>
> $ git rev-list --full-history HEAD -- a
> B
> A
>
> not list M (note the lack of --parents)?
Because when we don't ask for --parents, the whole problem is *much*
simpler. The parent rewriting means that the history has to all "fit
together". But when you don't need parenthood, then suddenly that doesn't
matter at all - who cares if it fits together or not, when you can't *see*
that it doesn't fit together anyway?
In this case, it's "simplify_commit()", and this piece of code in
particular (note how it's even commented!):
...
/* Commit without changes? */
if (commit->object.flags & TREESAME) {
/* drop merges unless we want parenthood */
if (!revs->rewrite_parents)
return commit_ignore;
...
ie if we're looking at a commit that doesn't actually introduce any
changes of its own (it took all the changes from at least _one_ of its
parents - ie it got TREESAME set because the tree was identical to one of
the parents), then if we don't have 'rewrite_parents' set, we just drop
that commit, because it is uninteresting.
IOW, we dropped 'M' because there was no point in showing it: we know
nobody refers to it (because no other commit will list it as a parent!),
and the commit itself didn't actually introduce any changes (because all
the changes came from 'B').
But we can *not* drop that merge commit when we do the parenthood
tracking, because if we did so, we'd just have an "empty spot" in history
(we have other commits that point to that emrge and list it as a parent).
Of course, in your trivial example, that didn't actually happen (because
'M' was the top commit), but try it with something more complex.
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
