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@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_Revis...
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l