Best practices for merging?

[Tuncer Ayaz]

On 31 January 2016 at 22:01, Geoffrey Mainland wrote:
> 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!

I'll have to deal a lot more with Phabricator in another project soon,
and your question reminded me to figure out why this happens, etc.
Open source communication has conditioned me to discuss publicly, so I
may have hijacked the thread. Sorry.

For anybody who's curious: I actually looked this up and it seems that
Facebook decided to default to squash for cleaning up branches that
are full of fixup commits and thereby make phab not support branches
with a clean history, where each commit gets you a working state (not
some in-between broken revision). So it's to support all those devs
who do not create patch sets. There are some suggestions like setting
history.immutable in .arcconfig or invoking land with --merge. Will
try these the next time I use arc.