Best practices for merging?

[Geoffrey Mainland]

On 02/01/2016 09:44 AM, Jan Stolarek wrote:
>> If there are multiple commits then a merge commit can serve to logically
>> group them.
> The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the 
> commits come one after another they are still logically grouped, with or without a merge commit.

In a purely linear history, it is not immediately clear how the commits
are grouped---there is just a single stream of commits, so in effect,
there is only one "group."

> I also wonder what is the preferred way of viewing history for most of the people. I either use 
> `git log` or github, but rarely resort to gitk. Only the latter makes the non-linear commits 
> explicitly visible. The former two just collapse everything into a linear history and is such a 
> setting merge commits are a major clutter. So perhaps that's why I don't like them. Perhaps 
> people who tend to use gitk are more keen on merge commits?

I use gitk extensively, so perhaps that's why I like using empty merge
commits to mark groups of patches. This lets me scroll through the repo
history and see when major features landed.

For my recent fix, I can see why one might prefer a fast-forward merge.
But for feature branches that have 10-15 (or more) commits, especially
when multiple people have contributed to a feature branch, an empty
merge commit marks (and documents) that this group of patches implements
a significant feature. If these 10-15 commits were merged fast-forward,
then it would not be immediately obvious that they were all part of the
same group, nor would it be obvious from scrolling through the history
that they were all part of significant feature X landing.

If one doesn't use gitk, I can see why empty merge commits would not be
so appealing.

In the past, the GHC history has been littered with merge commits, some
of them non-empty, often because of a git pull without --rebase. So our
history is certainly not merge free---even recently. I would agree that
those kinds of merges are not desirable, and non-empty merge commits are
especially unpleasant.

Squashing large change sets into a single patch is also undesirable---it
makes figuring out exactly what changed more difficult and makes
bisecting less useful.

Again, I'm not trying to impose a workflow---I just wasn't sure if there
was a new recommended workflow.

Cheers,
Geoff

>> For instance, in the case of Geoff's recent fix, 
>>
>>     $ git log --graph --oneline origin/master
>>     * e5a0a89 Suppress substitution assertions to fix tests
>>     * a883c1b Missing @since annotations in GHC.Generics
>>     * f8e2b7e Minor doc fixes to GHC.Generics
>>     * 34519f0 When encountering a duplicate symbol, show source of the
>> first symbol *   669cbef Fix Trac issue #11487.
>>
>>     |\
>>     | * 6544f8d Properly track live registers when saving the CCCS.
>>     | * 90f688e Code formatting cleanup.
>>     | * 4d0e4fe Add type signatures.
>>     |/
>>
>>     * b61f5f7 Put docs in /usr/share/doc/ghc-<version>
>>
>> Here we see that those three commits were developed on a feature branch,
>> which was then merged into master in 669cbef.
>>
>> For what it's worth I quite like this practice. That being said, in GHC
>> we rarely have changes broken up into multiple commits like this, in
>> part due to Phab's poor support for fine-grained changes.
>>
>> Cheers,
>>
>> - Ben
>