Definitely -- it's less clear than it could be because I don't call out
"--no-ff" explicitly (I'm hedging my bets against Mercurial adding something
similar some day), but for all practical purposes I mean "--no-ff" when I say
"having a strict policy where your master/trunk contains only merge commits" and
"or create an abstraction layer (merge commits)".
On Aug 10, 2012, at 8:29 PM, Daniel Friesen wrote:
On Fri, 10 Aug 2012 17:06:12 -0700, Evan Priestley
<epriestley(a)phacility.com> wrote:
[...]
That said, there is also a (purely advisory) document here extolling the virtues of
amending (if not during development, at least before pushing changes to the remote):
http://www.phabricator.com/docs/phabricator/article/Recommendations_on_Reviā¦
Looks to me like the same mistakes I see all the time. ie: Thinking about commit history
as a single linear tree. Almost none of the arguments in the "Why" section are
valid when you --no-ff instead of squashing.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l