On Fri, Feb 13, 2015 at 1:40 AM, Gregory Szorc <g...@mozilla.com> wrote:
> Truth be told, unless you are collaborating with other people using > evolution, the benefit of enabling obsolescence on user repos is probably > marginal. The bigger wins come from enabling obsolescence on the main > repos. For example, when your push to MozReview gets landed by Autoland, > Autoland can write an obsolescence marker so the next time you pull > mozilla-central, your client will automatically clean up your old pushed > commits that have since been rebased and landed. No manual branch/bookmark > management necessary: Mercurial automatically sees the old commits have > "evolved" and it hides them from you. It's "next generation" version > control and I can't wait to experiment with time-saving workflows which it > will enable. On long-lived git branches that might have several bugs pending in them, I can do: - push some changesets to inbound; - wait for them to merge to central; - pull central and rebase; and those pushed commits are "hidden" from me as well; they no longer appear in the log from central to HEAD. I don't understand why this feature is so groovy. Is the scenario that is interesting really: - push some changesets to mozreview; - get some of them approved; - push those changes to inbound/central; - rebase your project branch; - push remaining changesets to mozreview; and then Mercurial has enough information to know about the changesets you've already pushed to central, and it hides those from mozreview? -Nathan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
