On Fri, Feb 13, 2015, at 11:43 AM, Nathan Froyd wrote: > 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:
I believe the scenario gps is envisioning is actually: - push some changesets to mozreview - autoland rebases and lands those changesets on central - you pull central and your original changesets are obsoleted -Ted _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
