martinvonz added a comment.
In https://phab.mercurial-scm.org/D3715#58383, @durin42 wrote: > I'm in favor, but feel like I've got enough conflict of interest I shouldn't land the patches. > > @smf @lothiraldan this might be of interest to both of you? In https://phab.mercurial-scm.org/D3715#58507, @lothiraldan wrote: > In https://phab.mercurial-scm.org/D3715#58383, @durin42 wrote: > > > I'm in favor, but feel like I've got enough conflict of interest I shouldn't land the patches. > > > > @smf @lothiraldan this might be of interest to both of you? > > > The proposition of making namespaces behave differently than branches, and potentially making two namespaces behave differently (one with `multinode=True` and the other with `multinode=False`) make my spider sense tickle. But I will take time to see the exact implications of that series. As I said in the commit message, I think branches should have multinode=True, but we can't do that for BC reasons. Bookmarks and tags clearly identify a single commit per name (at least in my mind). How about we introduce the multinode option and default it to False for now, but plan to change the default to True later and then let only branches have the old behavior (i.e. multinode=False) and discourage extensions from setting multinode=False? That would result in consistency between namespaces (except for the legacy case of branches) while giving existing extensions some time to adapt (perhaps by making namemap return at most one node if they view their names as identifying a single commit). Btw, the topics extension was just an example. We have an internal extension that's the reason for this patch. I don't use topics, so I don't care too much if topics decide to have one commit per name or not (but if I did use topics, I think I would definitely view it as having multiple nodes per name). REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D3715 To: martinvonz, #hg-reviewers, durin42 Cc: durin42, smf, lothiraldan, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
