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 <[email protected]> > 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_Revision_Control.html > > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
