Best practices for merging?

[Ben Gamari]

Jan Stolarek <jan.stolarek at p.lodz.pl> writes:

>> 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.
>
> 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?
>
Indeed I make quite frequent use of gitk (even git log --graph is pretty
usable).

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160201/b01ab0cf/attachment.sig>