Re: How does git follow branch history across a merge commit?

["Steven E. Harris" <seh@panix.com>]

Junio C Hamano <gitster@pobox.com> writes:

> If you merge competition into your master, the resulting commit will
> have your master as its first parent.  If check out competition and
> merge master in your example, the resulting merge will have
> compatition as the first parent.

I see, having run a few more experiments to confirm this.

I missed the point that merge commits are not "predecessor neutral";
they apparently have a bias indicating "/this branch/ received content
from /that branch/ (or /those branches/)".

To try to recreate my confusing scenario, I tried this:

,----
| git checkout competition
| git merge master
| # This fast-forwarded "competition" be equivalent to "master".
| git checkout 'HEAD^'
| # This wound up again at "master"'s predecessor, not "competition"'s.
`----

It seems that since fast-forward merges don't produce a commit, the
merge record remains in place recording that branch "competition" came
into branch "master". Even though we're checked out to branch
"competition" here, following its history back in time requires some
manual intervention. Do you concur, or is my example perhaps flawed?

-- 
Steven E. Harris