Re: who's on first? - following first parent and merge-management

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2012, 07:37 UTC
Message-ID: <7vwr6woo8p.fsf@alter.siamese.dyndns.org>
In-Reply-To: <jj6s47$m98$1@dough.gmane.org>

Neal Kreitzinger <nkreitzinger@gmail.com> writes:

Show 5 quoted lines

> Please advise on "first parent" intent, best-practices, and pitfalls,
> or documentation that explains it.  (I haven't found documentation
> that directly explains "first parent theory and practice".  I've seen
> many references to "first parent" and its implied meaning that I'm
> supposed to "just know" or deduce).

A short conclusion: if you take "first parentness" very seriously, neither of your two approaches are optimal, but that does not make you a bad person. It is just that "log --first-parent" is not the best way to get an overview of the history for your workflow.

The mechanical definition of "first parent" is that:

 - A merge is a commit with more than one parent.

 - When you run "merge", you are on one commit, HEAD, taking changes
   made by "other branches" you are merging into "your history"
   (whose definition is "the commit-dag leading to your HEAD
   commit"), and record the resulting tree as a new commit.

 - This new commit records all its parents, one of them being your
   old "HEAD" and the rest being "other branches" you merged into
   "your history".  They are recorded in that order in the resulting
   commit ("git cat-file commit HEAD" after a merge to see them).

Hence, the first parent of a merge is the HEAD the committer was at when s/he ran "git merge".

It's late so I won't go into the details of what the implications of this is in this message. Perhaps tomorrow when/if I have time.