Best practices for merging?
jan.stolarek at p.lodz.pl
Mon Feb 1 07:21:20 UTC 2016
> rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward.
I was under the impression - perhaps incorrect - that it is our policy to avoid merge commits, ie.
do only fast-forward merges. And when I look at git history I see very few merge commits.
> This lets me look at the repo history and easily see where a feature branch landed and get a
> good idea of what changes it contains.
I always considered merge commits to be obscuring history, both making it hard to read and
understand. Two commits instead of one does not sound desirable. And you can always see what
changes were introduced by a patch, with or without merge commit. But perhaps I am missing
> This lets me look at the repo history
> and easily see where a feature branch landed and get a good idea of what
> changes it contains. I have used this approach in the past with GHC,
> e.g., SIMD support and typed TH.
> For smaller sets of changes, I might skip the merge commit, but I still
> break up my changes into discreet bits, which helps anyone reading the
> change set to see what's going on.
> It seems the current policy is to submit changes via Phab and then,
> after approval, squash everything into a single patch and apply it with
> arc. At least that is my reading of
> Is that what I should be doing?
> For feature branches, is that also what is advised?
> ghc-devs mailing list
> ghc-devs at haskell.org
Lodz University of Technology
TreÅÄ tej wiadomoÅci zawiera informacje przeznaczone tylko dla adresata.
JeÅ¼eli nie jesteÅcie PaÅstwo jej adresatem, bÄ
dÅº otrzymaliÅcie jÄ
prosimy o powiadomienie o tym nadawcy oraz trwaÅe jej usuniÄcie.
This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.
More information about the ghc-devs