Best practices for merging?

[Geoffrey Mainland]

On 01/31/2016 02:47 PM, Tuncer Ayaz wrote:
> On 31 January 2016 at 19:24, Joachim Breitner wrote:
>> Hi,
>>
>> Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland:
>>> My usual git workflow is to work on a feature branch, get a nice
>>> clean set of patches, each of which implements a discrete bit of
>>> functionality, rebase onto master, and then merge with an empty
>>> merge commit, i..e, *not* fast-forward.
>> if you want to go through the trouble, you are certainly welcome to do
>> so. The fact that phab squashes commits into one is more an artifact
>> of its VCS-agnosticity rather than a deliberate decision by us.
>>
>> When I want a git history (or just my nice git commit messages)
>> preserved, I create a phab differetian revision as usual, but then
>> manually amend the git commit to contain the line Differential
>> Revision: https://phabricator.haskell.org/Dnnnn and push, once the DR
>> has been accepted, by normal git means. I just have to remember to
>> indicate in the DR (e.g. in the summary) that I want to do it this
>> way.
> FWIW, I agree with Geoffrey, and in addition to the benefits he listed,
> I appreciate that committing "kernel.org-style" improves bisect'ability.
> I used to dislike merge commits myself until I realized the usefulness
> of finding merge points in the history. So, I don't understand how
> collapsing everything into one big commit can make any sense.
>
> Is it really impossible to tell phabricator (or arcanist) to preserve
> a carefully prepared patch set, and if so, why does it insist on that?

Not that I don't think these things are worth discussing, but to be
clear, I was not trying to impose my preferred git workflow on GHC :) I
was just looking for clarification, which Joachim provided---thanks!

Cheers,
Geoff