smf added a comment.
In https://phab.mercurial-scm.org/D4312#79581, @durin42 wrote: > In https://phab.mercurial-scm.org/D4312#79573, @smf wrote: > > > In https://phab.mercurial-scm.org/D4312#79509, @durin42 wrote: > > > > > There's been some good discussion on this. I'm sympathetic to both arguments here, namely: "we could improve bookmarks and make them less bad" and "bookmarks are a dead end and nobody should use them and we shouldn't improve them" (or thereabouts - I'm summarizing complicated positions to less than a sentence, so bear with me.) I think not following up on our plans to at least make plausible incremental improvements to bookmarks serves our users poorly, and this extension merits landing as an experimental extension. We can always spin it back out if we get unhappy with it. > > > > > > Obviously, I can't say I'm too happy with this. Allowing users to shoot themselves in the foot even more is pretty bad. > > > That ship has sailed: bookmarks exist, and are more visible than features like rebase. > > > > > > >> I'm going to land this patch largely as-is on default, with the following tweaks: I'm adding (EXPERIMENTAL) to the docstring of the extension so we can iterate its behavior, some misc. check-code fixes, tweak the commit message slightly to make check-commit happy. > > > > When I bring up community issues (including at this sprint) I thought this project was more than just one person. Having to constantly put up the good fight is completely negated if no one is going to listen and just ship this anyways. Bookmark related features belong as a third-party extension just like hgsubversion, hg-git, etc. > > ...it is? You're the only voice of objection that I'm seeing. I see some mostly indifference from BitBucket and some pretty good enthusiasm from the contributor, rhodecode, Kevin, etc. And it's experimental, so we can dump it if I've made the wrong choice. If I've missed some other /objections/ (as contrasted with what I perceive to be indifference - maybe I'm misreading Erik?) please point out my error. I hung out with Erik yesterday and he said he was too frustrated and tired of explaining himself to reply to this thread. I can't say I really blame him. The previous discussion outlines why having (and encouraging) two branching models is bad for the ecosystem. This is based on Erik and mine’s years of experience working on Bitbucket. The more important and pressing issues are exchanging obs markers and improving named branching. A cash donation in those directions has gone unused and it is frustrating that the weight of Bitbucket’s experience and resources has gone ignored. This will not help the *average* user and sends a mixed (and dangerous) message that bookmarks should be used. For a team that truly wants this feature, hosting this extension as a package on pypi is the best solution. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D4312 To: idlsoft, #hg-reviewers, pulkit, marcink Cc: evzijst, krbullock, mharbison72, smf, markand, marcink, durin42, jwatt, pulkit, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
