Pushing from 'master' creates / updates 'master' bookmark in hg repository

[fingolfin]

In the current gitifyhg, if I "git push" while on the "fake" master branch created by gitifyhg, then this ends up creating a new bookmark "master" in the remote hg repository (resp. it updates that bookmark if it already exists).

This is highly undesirable for me (we don't use hg bookmarks), and I think this didn't use to be the case, so for me this is a very annoying regressions.

On a probably related note: I just had several instances of gitifyhg dieing with strange issues, and at least one was caused by a remote repository becoming corrupted (the ".hg/bookmarks" file somehow ended up a corrupt "master" bookmark entry). I can't say 100% whether this was caused by gitifyhg, but it seems likely... Anyway, I can't quantify this, so for now just consider this as a further motivation why I think this bug should be fixed ASAP :-).

[alexsydell]

This should be easier to understand and fix once #65 is merged in. After that refactor (which shouldn't change any behavior), it's easy to see from ref_to_name_reftype, name_reftype_to_ref, and make_gitify_ref that we turn the default branch into a master bookmark. The simplest fix is probably to map it to refs/hg/origin/branches/master instead of refs/hg/origin/bookmarks/master. The downside is that we'll clobber any actual branch called 'master' that you might have, but on the other hand we're already clobbering any bookmark called 'master'. The correct fix is to probably not special-case the default branch and just leave it called default in git.

As a slight aside, this leads me back to our previous discussion of mapping branches to refs/heads/BRANCH instead of refs/heads/branches/BRANCH, and mapping bookmarks to refs/heads/bookmarks/BOOKMARK. The reason you ran into this issue is that while you thought you were on the master branch, you were actually on the master bookmark; that's because we're all used to pure git repos which typically keep their branches directly under heads. And that's why I'd rather have bookmarks be the special case in git - branches would show up normally, and while bookmarks would still look like a branch to git, at least they'd be a branch called 'bookmarks/BOOKMARK'.

[dusty-phillips]

I'm also becoming increasingly annoyed with the special casing of master and default, although changing it without forcing people to re-clone all their repos may be even more annoying.

I am also more inclined to not create bookmarks unless the user has explicitly requested it (refs/heads/bookmarks/ being a good way to request it). However, I suspect that defaulting to named branches is going to cause problems as well. Imagine the uproar if a named branch is accidentally created! At least bookmarks can be deleted. So I'm currently in favour of refusing to push a branch if the user has not explicitly named it either bookmarks/ or branches/, and make a separate decision as to whether to special case master and default.

[alexsydell]

I agree it would be a breaking change, but probably one worth doing. Two options to ease the pain could be to either a) start erroring on old repos and force people to re-clone or b) flip some sort of bit in marks-hg to keep this functionality for older gitifyhg repos.

I'm not sure I agree with your second point. Since branches are lightweight by default (i.e., created via 'git branch' or 'git checkout -b') they won't get pushed to the remote, so a user would have to intentionally create the branch on the remote. Feels strange to me that in a normal git repo pushing /refs/heads/BRANCH would create the branch but would error out (or not create a branch) if the remote is gitifyhg.

As far as uproar about accidentally creating named branches, I think that should fall either under what I just said (you're doing it intentionally) or if you're working on a project that dislikes named branches you'll just have to be aware of that (it's not gitifyhg's job to save you here).

To summarize, based on the hg repos I've seen a user should either live in bookmark land, where they only work with bookmarks (I think it's fine to force them into refs/heads/bookmarks/BOOKMARK here) or in branch (plus optionally bookmarks) land, where branches are allowed in the remote repo (and if so, why are we changing git behavior that everyone is used to?). There are very likely other common use patterns that I'm not aware of, and I'd love more discussion around those that could potentially prove me wrong.

[jedbrown]

@alexsydell The problem is that named branches are permanent. We had a couple pull requests that were accidentally developed as named branches over the years and even though we "closed" them, Mercurial still reminds us about them and they were a recurring annoyance (until two weeks ago when we switched to Git, yay). With Git, we're accustomed to being really casual about branches because they are just tools that we use to manipulate the commit DAG rather than a property of the DAG itself.

I think that having Gitifyhg make commits on named branches without being doubly sure that the user really wanted them would be a mistake. To be honest, considering that Hg branches can have many heads, including heads with disjoint history, they would map better to Hg-branch: branch-name tags at the end of a commit message than to Git branches.