On Fri, Apr 5, 2013 at 4:30 PM, Max Horn <m...@quendi.de> wrote:

> On 04.04.2013, at 08:42, Felipe Contreras wrote:

> Please consider that the willingness of people to collaborate with you in any 
> way is directly related to how you treat them. That includes bug reports. The 
> way you acted towards Jed, who was very calmly and matter-of-factly 
> explaining things, was IMHO completely inappropriate and unacceptable

He did not provide any bug report at all, also, he was not willing to
collaborate, as he clearly stated; he won't work git-hg bridges no

> Indeed, I should augment my list of reasons why people might not want to 
> contribute to remote-hg by one major bullet point: You. And please, don't 
> feel to compelled to tell us that Junio is really the maintainer of remote-hg 
> and not you: Whether this is true or not doesn't matter for this point.

Oh but it does. The only reason my remote-hg managed to land in the
mainline is because I showed it was superior to the other
remote-hg[1], and that there really was no point in trying to salvage
the other code base. Maybe this turns out to be a mistake, and the
other remote-hg manages to improve and surpass my remote-hg, but it
seems rather unlikely at this point.

Similarly, you could *show* that gitifyhg is superior than remote-hg,
why it makes sense to use that instead of trying to improve this code
base, but you don't, because you can't, because it doesn't make sense.

Ultimately this is not about people, this is about the code. A
sensible person that is not emotionally attached to any code, would
simply look at the code, and if what you claim is true (that remote-hg
has many issues), this sensible person would start cherry picking
patches from gitifyhg, send them to the git mailing list explaining
why they make sense. Eventually, remote-hg in git.git would become
essentially gitifyhg (albeit better because it would have received
more review from other git developers). Codewise this would make

And this sensible person would replace me as the go-to person for
remote-hg. And he would probably have a friendly and wonderful
personality, and you can accept him as your messiah and what not. But
this wouldn't change the fact that codewise this is the best way to

But the fact of the matter is that either a) remote-hg is perfectly
fine, or b) this sensible person doesn't exist.

>> , I find it
>> annoying that you claim to know what is important for users, as if
>> somehow knowing that gitifyhg doesn't work with the user's version of
>> mercurial (e.g. 1.8) is better than remote-hg's situation; where it
>> *actually works*, but it's not mentioned. Yeah, mentioning that it
>> doesn't work is better than working, right.
> I'll leave it to everybody to read what you wrote there, and contrast it with 
> the following, and draw their own conclusions...

Keep in mind that it's not me the one that claims remote-hg is
superior because it supports 1.8, as you seem try to portray. Rather,
it's _you_ the one that claims superiority because gitifyhg *mentions*
support until 1.9 (which remote-hg also supports).

It's not important who supports the most ancient version of mercurial
that nobody uses anyway, what is important is that *mentioning* or not
mentioning which ancient version of mercurial is supported doesn't
make one project superior to the other.

But perhaps this point is too subtle for you to understand, so there:

Now it's mentioned that remote-hg too, supports up to version 1.9. Can
we agree now, that nobody has any advantage, either on version
support, or the mentioning of version support?

> Indeed, util.url was only added in 1.9.3. OK, let's work around that. Then 
> local clones work. But of course in reality, most users will want to interact 
> with a remote repository. But that's still broken:


And it was _you_ the one that sent the commit that broke it to the git
mailing list to be pushed.

> Right, clone() changed. And some more stuff. See 
> <https://github.com/fingolfin/gitifyhg/commit/d3d37a7a853f3c8a1907bdaf933844128d5e7d81>.

Indeed, that might be useful, but that doesn't mean remote-hg doesn't
work with 1.8; it works perfectly fine for local repositories, and all
the tests pass.

> There also was a good reason why I stopped at that point, but I don't 
> remember the details right now. And quite frankly, I have zero incentive to 
> even try to remember. But anyway, I don't think it's that useful to add 
> support for 1.8, too, since one can't get back much further anyway. And 
> upgrading to a newer Mercurial is (a) quite easy (even if you don't have 
> root, just install it into $HOME), and (b) using a newer Mercurial version is 
> a good idea for other reasons, too.

If supporting 1.8 is not useful because most people have newer
versions, then mentioning support for 1.9 doesn't give any advantage.
Thanks for wasting our time on something nobody cares anyway.

>>> BTW, I just pulled you hg-next branch, and run "make test" in that. The 
>>> tests in test-hg-hg-git.sh actually all failed (with remote-hg). Do I need 
>>> to do something special for those to work?
>> No, they should just work. Perhaps you have an old version of hg-git
>> (I have v0.4). You can check the errors with
>> GIT_TEST_OPTS="--verbose".
> Yup, that was it, thanks. It would be kinda nice if the test code could check 
> for suitable versions of mercurial and hg-git (and python, I guess) and warn 
> the user if necessary.

Yes, but how many people run these tests? And how many people have
hg-git in the first place? And how many people care about
test-hg-hg-git? I'll guess not so many, so I'm not really looking
forward to see what are the issues with older versions of hg-git.

> As for your complaints about not getting proper credit in the gitifyhg README 
> etc.: I agree that it is very much lacking in this regard, and will work 
> towards rectifying this (indeed, I already suggested this to the other 
> gitifyhg devs).


> I'll also look into using sharness for gitifyhg test (which is based on the 
> git test suite), as I also don't like the current test setup in gitifyhg, and 
> indeed, the other gitifyhg devs agree. This would also make it easier to 
> share and compare tests between remote-hg and gitifyhg if desired.

That would be really good.

> Jed and me already explained why e.g. forced push makes remote-hg an absolute 
> no-go for me and several other people.

% git config remote-hg.force-push false

Problem solved. You don't need to work on a another project to avoid this.

> Whether you accept this or not is irrelevant -- it sadly won't change the 
> reality I and others have to deal with at work and elsewhere.

The reality is you lack imagination. I've yet to see a single argument
that shows a problem with using a dedicated branch to push bookmarks.

> I won't reply to all the other stuff you wrote, as it just causes too much 
> bile to raise up re-reading it, and I am not sure I could manage to reply in 
> an even remotely neutral tone. So I'll refrain from attempting, as I am not 
> interested in a fight between the two projects, or anybody for that matter. 
> Nor do I see this as a competition where the "best" wins -- if somebody 
> prefers remote-hg over gitifyhg, or the other way around, I don't care much, 
> as long as at least one of the tools satisfy their needs.
> Rather, all *I* am interested is using git to access a couple hg repositories 
> that I absolutely must access. And helping several friend and colleagues who 
> are in the precise same situation.

So you are unable to argue why is it that gitifyhg is necessary, or
good. I take this as evidence that you are too emotionally invested to
accept the possibility that there's no good reason for the existence
of gitifyhg.

gitifyhg is not technically, or in any way, superior to remote-hg. You
should just give it up, and try to move as much code as possible to
remote-hg (is there any that will be useful?), and perhaps maintain a
branch to make remote-hg behave as you want (I already provided an
example), but on top of remote-hg. You can have your own github repo,
with your own wiki, and your own releases as you have it now. Then it
would be easier to share code, and if gitifyhg turns out to be truly
superior, it would be easier to simply merge those patches that enable
gitifyhg behavior, which you claim make all the difference in the

It would be great if we could all work together in remote-hg, but
given the fact that at no point in time did you consider to "fix"
remote-hg, and that you spend considerable amounts of time claiming
that gitifyhg is superior, specially in remote-hg's own bug tracker,
rather than sending patches for remote-hg, which would prove your
point much more easily (if it was correct), I don't think you are
allowing for that possibility.


[1] https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg

Felipe Contreras
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

Reply via email to