Excerpts from Pierre-Yves David's message of 2017-03-13 11:57:08 -0700: > > On 03/13/2017 09:23 AM, Durham Goode wrote: > > On 3/13/17 2:48 AM, Jun Wu wrote: > >> # HG changeset patch > >> # User Jun Wu <qu...@fb.com> > >> # Date 1489395002 25200 > >> # Mon Mar 13 01:50:02 2017 -0700 > >> # Node ID 6ae6d1069ba1d4089afaeb0bb8ef2411983a1292 > >> # Parent 0280ee091bd0ae33aa0a67b0c8a55ccffd2e0718 > >> # Available At > >> https://bitbucket.org/quark-zju/hg-draft > >> > >> # hg pull > >> https://bitbucket.org/quark-zju/hg-draft > >> -r 6ae6d1069ba1 > >> obsolete: allow cycles > >> > >> Now we can handle cycles nicely, allow them to be created. Some practical > >> examples: > >> > >> - To revive X, just create a marker X -> X, with a newer date. > >> - To prune X again, just create a marker X -> (), with a newer date. > >> - The above two could be repeated. > >> > >> - To unamend A -> B, just create a marker B -> A, with a newer date. > >> > >> It's now possible for "touch" and "unamend" to reuse hashes (therefore > >> more > >> user-friendly). And it's no longer necessary to write "*_source" in > >> commit > >> metadata to workarounds obs cycles. The hacky inhibit extension also > >> becomes > >> unnecessary. > >> > >> Finally. I have been wanting all these for a long time. > > > > Seems pretty elegant, though I haven't fully understood it yet. Maybe > > you guys talked about this in person, but what effect (if any) does this > > have on exchange? > > We did not really discuss this at the sprint :-/ > > This probably has effect on two aspects of pull and push: > > * Computation of the relevant markers for a None
Note sure what "None" means here. Just want to mention, in terms of exchange, we have 2 choices: 1. Exchange the filtered markers. 2. Exchange the unfiltered markers. I think either will work. 1 is simpler because we don't need to introduce a separate "unfiltered" layer. 2 may be nicer if people want the full history of evolution. > * Computation of "head replacement" when pushing branches obsoleting > another one. > > The proposal have some very interesting aspect, I'll try to do a deep > review of its impact on the general concept soon™ (probably not this week) > > Cheers, > _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
