Best practices for merging?

[Tuncer Ayaz]

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?