To reproduce: - create a git repo - create a mercurial repo - add the git repo to the mercurial one as a sub-repo - clone the mercurial repo into the repo-1 - create a new branch in the repo-1/sub-repo - made any changes in the repo-1/sub-repo - commit and push the changes via mercurial (for repo-1) - clone the mercurial repo into another repo (repo-2) - go to the subrepo and check that current branch not the branch from origin - it is new and named as 'origin/<branch>'. - make any changes, commit and push repo with mercurial => new branch added to origin named 'origin/<branch>' This bug can be simply fixed by changing if remote not in tracking: # create a new local tracking branch local = remote.split('/', 2)[2] checkout(['-b', local, remote]) with if remote not in tracking: # create a new local tracking branch local = remote.split('/', 3)[3] checkout(['-b', local, remote]) in the subrepo.py I have tested this fix for version 2.5.2 - it works.
Please send your patch to mailing list: http://mercurial.selenic.com/wiki/ContributingChanges Thank you
No data loss (you still have your git repo) -> not critical.
Fixed by http://selenic.com/repo/hg/rev/811e253226c3 pozheg <pozheg@gmail.com> subrepo: clone of git sub-repository creates incorrect git branch (issue3870) Mercurial handles git subrepos by incorrect way. If the mercurial repo has a git sub-repo and somebody started a new branch in the subrepo and push it into git, the next one who will clone the whole repo will get incorrect branch name in the git subrepo. (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/2b34d004e644 Kevin Bullock <kbullock@ringworld.org> subrepo: add regression test for issue3870 (please test the fix)