Thread (10 messages) 10 messages, 2 authors, 2016-06-15

Re: [PATCH v2 2/3] remote-helpers: move out of contrib

From: Felipe Contreras <hidden>
Date: 2016-06-15 23:00:48

Max Horn wrote:
On 21.04.2014, at 22:37, Felipe Contreras [off-list ref] wrote:
quoted
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 situations/
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
such issues.

Either way, I just fixed it [1].
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:
https://github.com/felipec/git/wiki/git-remote-hg
https://github.com/felipec/git/wiki/git-remote-hg
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:

https://github.com/felipec/git/issues

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".

[1] https://github.com/felipec/git/commit/fbaae8caa51804a655fd6bc5727763b64e3c2e9f

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help