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

From: Steven E. Harris <seh@panix.com>
Date: Aug 28, 2009, 23:50 UTC
Message-ID: <831vmv5wh7.fsf@torus.sehlabs.com>
In-Reply-To: <7vmy5jbjkr.fsf@alter.siamese.dyndns.org>

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