D4312: New bookflow extension for bookmark-based branching

[smf (Sean Farley)]

smf added a comment.


  Thanks for submitting your patch, it’s clearly a work of passion and I appreciate that. I know feature branches is a much sought-after behavior. However, I must express my objection to this direction in bookmarks. (apologies in advance)
  
  I think the core issue at hand is the difference between data models. In particular, there are two huge differences:
  
  - mapping (one-to-many vs one-to-one) and
  - garbage collection
  
  A bit of background: I've written many versions of this ref-like behavior over the years, including one during my time at Bitbucket. My experience with each of these extensions never felt right and I ended up throwing them all away.
  
  As programmers, we like to abstract and create functional mappings around data. But we can't hack our way around the difference between a one-to-many relation vs a one-to-one relation. At a fundamental mathematical level, the two relations are not the same. For the last ten years, millions of Mercurial repos have been created that have (named) branches that are stored in the metadata. This is pretty ingrained in each developer's mind: one commit <-> one branch name. I think that changing this at this point would cause unnecessary frustration for our users.
  
  For hosting sites like Bitbucket, this is even worse. Having two branching models is just impossible. A simple example is writing the branch api: should it return named branches? bookmarks? both? What happens when there is a call to create a branch? Create a branch? bookmark? both??? There are other rough edges as well: documentation, user tutorials, UI/UX, etc. The lessons I learned at Bitbucket helped me understand that core Mercurial should not recommend bookmarks as feature branches.
  
  It doesn't stop there, though. Possibly the biggest misunderstanding is what and how anonymous heads work and why they don't disappear like they do in git. It is straight-up impossible to remove anonymous heads in Mercurial and trying to paper over them just makes things worse. I've tried assigning auto-generated bookmarks, auto-marking obsolescence markers, auto-hiding commits locally, etc; anything I could think of. Nothing ever really worked in my experience.
  
  Perhaps the show stopper, though, is evolve. Much like Mercurial, evolve views the world through  changesets. Changesets and their successors / predecessors are related by obsolescence markers and form a DAG, just like changesets of a repo are in a DAG. These relations have a starting point and an ending point and the most natural fit to that is, of course, storing the branch name in the actual changeset. When needing to evolve changsets, the only practical (perhaps even only possible) way to determine which branch it lived on is with named branches. Bookmarks / refs lose that information. Therefore, trying to shoehorn that model into evolve or even core is reinventing what branches already achieve.
  
  Everything I tried in the bookmarks world fought against the core design principles of Mercurial. For those reasons, I think it is best to stick to one branching model and keep bookmarks (as much as possible) in third-party extensions (or if my dreams come true: in hg-git). As I've witnessed over the years, while at both Mercurial and Bitbucket, users will assume an implicit blessing for behavior when a feature is included in hgext. See for example, the nightmare of largefiles (and that need causing Facebook's rewrite in lfs), eol, keyword, etc, etc. We can put as many "features of last resort" warnings that we want but the ultimate protection we have to save ourselves the headache is to keep things out of hgext.
  
  All of this is not to say I don't want feature branches in Mercurial, I do. It's something Erik and I have thought a lot about and we both want to improve on (named) branches that allow feature workflows and work better with phases and evolve. I have even worked over the last few months on this exact approach and, on my side, I will use this as a fire to get my own work out the door. I would welcome and appreciate any kind of help in planning, coding, or even just spitballing.

REVISION DETAIL
  https://phab.mercurial-scm.org/D4312

To: idlsoft, #hg-reviewers, pulkit, marcink
Cc: smf, markand, marcink, durin42, jwatt, pulkit, mercurial-devel