Max Horn wrote: > On 23.04.2014, at 22:54, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > Max Horn wrote: > >> On 21.04.2014, at 22:37, Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 situations/ > > Yeah, hm, no. We can agree to disagree, I guess. Right, except one of us has evidence to back this up: * There hasn't been a single person coming to the Git mailing (or git-fc's bugtracker) reporting that they haven't been able to do something. This means if there's any situation where git-remote-hg doesn't work well, it hasn't been reported, and therefore the reasonable thing to assume is that if there are any, they are marginal at best. > It might also depend on what you call "basic" or "complex" usage... > > For example, whenever I need to > - close a branch > - fix a branch with multiple heads > - deal with phases > I need to switch to hg. I am pretty sure there are more things that make > that necessary, but luckily they don't happen to me. The fact that there are complex things you can't do, doesn't mean there isn't any complex usage supported at all. > Out of curiosity: How do you yourself use git-remote-hg in your daily work? I don't. > But I am worried about people hitting the edge cases where it does not quite > work -- and then people are lost. And which people are those? Are they imaginary by any chance? > This is what concerns me -- and this concern would be alleviate if there was > a list of known things that do not work (and perhaps cannot work, at least > for now, due to fundamental differences between hg and git which need major > work to bridge over). That list is empty at the moment, because again, nobody has come reporting anything they cannot do. The things that have been reported, I've fixed. > Anyway, despite my criticism, I'd like to emphasis that I am actually quite > happy and grateful that your git-remote-hg exists and that you continue > improving it and the surrounding infrastructure. I just wish you could do it > while not acting like an asshole most of the time, but I'll survive that, > too *shrug*. I am being straight-forward, not an asshole. If *you* have issues, why don't *you* list them? The people that have reported anything back about git-remote-hg/bzr, have reported success, or their issue was resolved. Even better would be if *you* fixed the issues you have. > >> 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. > > There are projects who do exactly that, although I believe most of them use > bookmarks, so the issue should indeed not affect those. Anyway, they do the > wrong thing ;-). Still, if you are forced with such a repository, it's not > very helpful to be told that this is your own fault... Nobody said it's their fault, what I'm saying is that those people don't exist, or haven't bothered to report such issues. > But this kind of issue also happens in any other scenario were heads are not > mapped to a git reference. And where is that? > At the very least, it also happens for closed hg branches. These are quite > common, and I also run into that in real life. If a branch is closed, it's ignored by git-remote-hg, so that doesn't cause a problem. If there's any scenario where it would be a problem, it's certain more complex than having a closed branch. > [And to reply to a claim you made in another mail: No, I am not deliberately > "hoarding" issues to make you look bad. But analyzing a breakage you run into > and then properly writing it up takes time; and when you know you will likely > be insulted when reporting it doesn't really help to motivate me to sit > down and do that...] Show me exactly where anybody did insult you for reporting an issue. > > In practice that's very unlikely, and proof of that is that nobody has reported > > such issues. > > No, that logic is flawed. For example, It could also mean that not many > people are using the tool, and of those not many bother to report issues via > your github bug tracker. Yes, it could mean that as well, if that's your contention then it doesn't matter either; most people are not being affected. > >> 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. > > Agreed. But in the meantime, I think users should still be warned about it. > Or perhaps git-remote-hg could detect this and print a more helpful message > that tells the user what is wrong...? Yes, the tool could do that, but that is not something that should prevent the move out of contrib, so it's not relevant for $subject. > >> 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 > > [I assume you meant one of the links to be for -bzr; but your point is clear in any case]. > > Great! But my point was not that there is no documentation, rather that > there is none in the git repository. Since you already have some > documentation, this should be easy enough to resolve; e.g. for starters, > those links could be included in the repository. Though I think that if the > helpers are moved out of contrib, they'd deserve a proper help page. Yes, it should be trivial to copy that documentation. This is not a make-or-break point against the move. > >> 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 > > At the time of writing, I was not aware that you had fixed the bug with the > marks file getting trashed. I did not yet have a chance to test your fix, > but I trust it works, so yeah, that resolve that. Excellent, thanks. > > So, for now, there are just some "known limitations", but that's fine, I > guess. > > Note that there are more limitations than those I listed above; not because > I want to "hoard" them, but because it seems rather trivial to come up with > those if one thinks about it for 5 minutes, so I simply assume(d?) you are > aware of most of them. Here's what I can think of right now; this still may > not be complete; nor do I mean to say those should hold up anything; I merely > want to get them out to prevent any future accusations about "hoarding" > stuff) > > - close hg branches cannot be referenced from git, and thus not easily > reopened (at least not from their old tip) Easy to fix: closed-branches/$name, or only refs/hg/$remote/closed-branches/$name. Hardly an issue. Nobody has reported this. > - multiple tips/heads of a hg branch cannot be referenced; only a single > "random" head (in the sense that it is not documented how it is chosen) > is visible Not random, the tip of the branch. And who cares? > - more name clashes, e.g. the somewhat hypothetical case of having a hg > branch "foo" and a hg bookmark "branches/foo" Very important (not). > - renaming remotes is a bit problematic (this is IMHO a shortcoming of the > remote helpers interface, not of git-remote-{hg,bzr}). I.e. it > can result in commits being re-exported, and hence in diverging history. That's not true. That's an issue of gitifyhg, not git-remote-hg. > - Not sure if this is still a problem, but I was seeing some issues when > a hg remote pruned some commits. Of course this is a bad thing to do in > the first place, but sadly it sometimes happens. IIRC this resulted in a > truncated marks file (which, as I understand, should be fixed already), > but I am a bit fuzzy on the details (it was quite some time ago, and since > something bad and exceptional was done on the hg side, I didn't bother to > look closer at it. I don't see how that could be of any issue issue since the mark files have been updated. I don't see how any of these should prevent the move out of contrib, so how is that relevant to the $subject? Most of these are so marginal that I wouldn't even bother documenting them. Maybe making a list as a to-consider, or to-think-about-fixing-later would make sense, but with the exception of closed branches and foo vs foo/bar, I don't see much point in worrying about these myself. Of course patches are welcome. -- 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