Max Horn wrote:
> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contre...@gmail.com> wrote:
> > The remote-helpers in contrib/remote-helpers have proved to work, be
> > reliable, and stable. It's time to move them out of contrib, and be
> > distributed by default.
> Really? While I agree that git-remote-hg by now works quite well for basic
> usage in simple situation, there are still unresolved bugs and fundamental
> issues with it.
s/basic usage in simple situation/complex usage in the vast majority of
> E.g. I recently showed you a reproducible use case involving git-remote-hg
> that puts the helper into a broken state from which it is difficult for a
> normal user to recover. Namely when a hg branch has multiple heads, then
> git-remote-hg exports all of those to git, but only adds a git ref for one of
> them; after pruning unreferenced commits, the fast-import marks file
> references git commits that now are missing, prompting git fast-import to
> crash and trash the marks file. Afterwards, attempts to push or pull from the
> remote hg repository are answered with an error.
Yes, and how often does that happen? A normal user would only see this if a
branch remains with multiple heads in Mercurial for more than one month or so.
In practice that's very unlikely, and proof of that is that nobody has reported
Either way, I just fixed it .
> There are more issues related to unresolved clashes between the git and hg
> ways of naming things. E.g. I am collaborating on a hg repository that has
> branches "foo" and "foo/bar" which git-remote-hg cannot handle because it
> translates them to git branch names, and, well, git cannot handle that.
I don't see this as a limitation of git-remote-hg, ideally Git remote-helpers
should have a standardized way to let users map external branch names.
> It may be hard to deal with some of them, and admittedly I wouldn't
> necessarily expect that all of these are handled from the outset, i.e. "in
> version 1.0". But I think at the very least, users should be warned about
> these things.
> More broadly speaking, there is currently no documentation at all in git.git
> for those remote helpers, which I find worrisome.
Here is the documentation:
> That said, I don't know what the criteria are for moving something out of
> contrib. Perhaps it is OK to move an undocumented remote-helper with known
> bugs out of contrib.
There are no known bugs. This is the list of open bugs:
Now if you want to label the limitation of Git that you can't have both 'foo'
and 'foo/bar' as a bug of git-remote-hg, that's up to you, but it's something
nobody had reported before, so it definitely can't be labeled as a "known bug".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html