On Wed, May 31, 2017 at 10:34:55AM -0700, Sean Farley wrote: > David Soria Parra <d...@experimentalworks.net> writes: > > > On Wed, May 31, 2017 at 10:50:15PM +0900, Yuya Nishihara wrote: > >> On Mon, 29 May 2017 23:28:20 +0900, Yuya Nishihara wrote: > >> > On Mon, 29 May 2017 14:45:39 +0200, Denis Laxalde wrote: > >> > > >> > I agree it's a bit puzzling, but I also think it's an acceptable > >> > extension to > >> > the `~` operator as long as descendants history is linear. However, from > >> > implementation POV, it would be unnecessarily expensive to make sure > >> > there's > >> > no more than one child. > >> > >> So I'm against the current proposal. FWIW, if we can define the first > >> descendant as the nearest child in revision number space, the computation > >> will be cheaper. > > > > I considered this and decided to not introduce this notion of nearest > > child. I feel that the notion of revnumber as an ordering is unintuitive for > > users of a decentralized version control system as it adds an concept of > > ordering on the existing dag, > > But this is what Mercurial has always done.
I think we have always used it as an optional method rather than a way to disambiguate. > > and rev numbers are rarely used by users for > > ordering (hence people use :: far more than : in revsets). > > I don't think that's sound reasoning. As a counter argument, Bitbucket > manually sorts each git repo so that it has a faux rev number. We then > use that number for children / descendant calculations. > > > I feel while the > > computation is faster it might often lead to unexpected results. The user > > must > > know the revision numbers of children in order to know what 'hg update .~-2' > > would do. That's why I felt restricting it the way i did in the patch was > > more > > sensibile for userbility. > > I'm unsure. On one hand, I'd like to get something through. But on the > other, we have years of precedence of using rev numbers. I don't mind changing the proposal if we agree. I prefer having something in and don't feel too strongly about my current approach, although i think it's much more user friendly than relying on revnumbers. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel