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

Junio C Hamano [off-list ref] 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