Max Horn wrote: > I am going to step away from this painful discussion and also this mailing > list, but I owed it to send one last reply with two of the problems I am > still seeing, simply in the hope that this will benefit some future > git-remote-hg users, but also to dispel any claims I was "hoarding" bugs to > somehow hurt Felipe. > > Beyond that, I refuse to further "discuss" with Felipe on anything. It leads > nowhere, and he is so full of himself that it seems impossible to reason > with him. I will also refrain from countering everything he said, even > though I am sure he'll construe this as me admitting that he is right. I > don't care enough to try to keep up the flames *shrug*. In the end, > everybody here can interpret this in whichever way they like. I don't construe anything as an admission that I'm right. The $subject is that git-remote-hg/bzr are ready to be moved out of contrib, that's my contention and I don't see why would anyone think that it's not right. > Ah well, OK, I can't resist one last retort to one point Felipe wrote: > > On 24.04.2014, at 02:23, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > > Max Horn wrote: > [...] > > > >> Out of curiosity: How do you yourself use git-remote-hg in your daily work? > > > > I don't. > > So you don't eat your own dog-food (at most you sometimes snack on it)? > That would explain a lot... Fortunately I don't use Mercurial in my daily work, so I can't use git-remote-hg on my daily work. It's not a matter of will. > Now to the issues: The following results are based on git "next" at revision > e8486314780a4. In addition, I cobbled together fixes from Felipe's > repository, namely the commit [1] he claimed to have fixed the multi head > issue I mentioned, as well as the changes from the fc/remote/fixes branch on > his github repository [2]. > > It is very well possible that this is still not the latest and greatest, and > that I missed some important patch that changes everything -- it's hard to > tell given the multitude of branches in Felipe's repository. Anyway, to > avoid confusion, I put my merged version of the script into a Gist [3], so > if I made a mistake there, it should be easy to discover. > > Given that, the following script (which Felipe already knows from his > issue tracker [4]) still causes a fast-import crash after which "git pull" > from the remote hg repository is impossible, and the user has no idea > how to recover. > > -- 8< -- > #!/bin/sh -ex > rm -rf hgrepo gitrepo > > # Create a multi-head repository > hg init hgrepo > cd hgrepo > echo a > a && hg add a && hg commit -m a > echo b > b && hg add b && hg commit -m b > hg update 0 > echo c > c && hg add c && hg commit -m c > cd .. > > # Clone it via remote-hg > git clone "hg::hgrepo" gitrepo > > cd gitrepo > git gc --prune=now > git pull # error > -- 8< -- > > Which results in this: > > WARNING: Branch 'default' has more than one head, consider merging > fatal: object not found: 61780798228d17af2d34fce4cfbdf35556832472 > fast-import: dumping crash report to .git/fast_import_crash_78219 > fatal: Error while running fast-import > > Any subsequent pulls then give something like this: > > WARNING: Branch 'default' has more than one head, consider merging > fatal: mark :6 not declared > fast-import: dumping crash report to .git/fast_import_crash_78834 > fatal: Error while running fast-import Clearly you are doing something wrong, because 'next' with the git-remote-hg you put in gist[1] doesn't trigger this issue. I tested. > What happens here is that a hg branch with two heads is created; this > repository is cloned via git-remote-hg. Both heads of the hg branch are > imported to git, No, they are not. You must be using a version of git-remote-hg other than the one you said you did. > The second script is similar but uses a closed branch to trigger essentially > the same issue. Background: closed branches are ignored by git-remote-hg, > meaning that no git ref is created for them, which can again lead to a > commit without a git ref but referenced by the marks file(s). However, > reproducing the bug in this case is a bit more complicated, because the > problem is obscured by another bug (?): Namely, if a hg branch is closed, > then git-remote-hg starts ignoring it, but does not seem to remove the ref > created for that branch. So, the git user will not see that the remote > branch was closed (which is a bug, I'd say); on the upside, since the ref is > still around, no dangling commit is produced. > > But we can "work around" this by re-opening the hg branch at a different > position, i.e. as child of an unrelated commit, which does *not* have the > commits of the original branch as parents. If we do that, git-remote-hg > moves the git ref to point to the new branch tip, and again we end up with a > dangling commit (the git commit corresponding to the former hg branch tip). > > Again, this is something me and also colleagues "discovered" in real life > usage. So don't be fooled by the somewhat convoluted test script. This *does* > happen. > > -- 8< --- > #!/bin/sh -ex > > rm -rf hgrepo gitrepo > > # Create a repository with two branches > hg init hgrepo > cd hgrepo > echo a > a && hg add a && hg commit -m a > hg update 0 > hg branch foobar > echo b > b && hg add b && hg commit -m b > hg update default > cd .. > > # Clone it via remote-hg > git clone "hg::hgrepo" gitrepo > cd gitrepo > git gc --prune=now > git pull > cd .. > > # close the branch > cd hgrepo > hg update foobar > hg commit --close-branch -m "close branch" > hg update default > cd .. > > cd gitrepo > git gc --prune=now > git pull > # This pull should trigger the issue, but for some reason, the ref > # origin/branches/foobar is still around, and so nothing happens. > cd .. > > cd hgrepo > hg update default > hg branch -f foobar > echo c > c && hg add c && hg commit -m c > hg update default > cd .. > > cd gitrepo > git gc --prune=now > git pull > # at this point, origin/branches/foobar is gone > git gc --prune=now > git pull # now we get the error > -- 8< -- Fixed. http://pastie.org/9113797 [1] https://gist.github.com/fingolfin/11296352 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html