On Thu, Apr 4, 2013 at 12:11 PM, Jed Brown <j...@59a2.org> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>
>> I still don't see any good reason why a user might prefer gitifyhg,
>> even more importantly, why gitifyhg developers don't contribute to
>> remote-hg.
>
> Felipe, I read your blog announcement [1] and got the impression that
> remote-hg was ready for daily use. When I tried to use it, it promptly
> crashed in my first attempt to clone. I opened up the script, fixed
> whatever caused the first stack trace and made it slighly further before
> it crashed again. I couldn't tell what was expected to work, what was a
> known problem, and what was an unknown problem. Many things clearly did
> not work and it had the look of a project that was not getting active
> use. I felt that it was wildly oversold and that putting it into
> git.git was premature.
Where is the evidence? You say remote-hg doesn't work, I say it does,
the difference is that I have evidence to prove it.
There's no bug report, no mail, no log of any kind, no repository to
check, no nothing. What are developers supposed to do with this
comment? Nothing, it's not constructive.
> I tried gitifyhg later and it basically worked out of the box. All
> known problems were marked by 'xfail' test cases. At that time,
> remote-hg failed almost all the gitifyhg tests.
Because gitifyhg tests are testing gitifyhg, not proper behavior. For example:
def test_push_conflict_default(git_dir, hg_repo):
git_repo = clone_repo(git_dir, hg_repo)
sh.cd(hg_repo)
make_hg_commit("b")
sh.cd(git_repo)
make_git_commit("c")
assert sh.git.push(_ok_code=1).stderr.find("master -> master
(non-fast-forward)") > 0
remote-hg doesn't fail with the non-fast-forward error, in fact, it
doesn't fail at all, it pushes correctly, and that's reported as a
failure.
> I contributed a few
> things to gitifyhg, including the notes support (essential when talking
> via email with other people using Mercurial). Since then, the last
> major project I'm involved with has switched to Git so I rarely need
> gitifyhg or remote-hg any more.
So what is the purpose of this anecdote? Are you going to provide
something of value, or is this just an attempt to root for the project
you have contributed to?
> FWIW, I also thought Dusty's original announcement oversold gitifyhg, but
> it was closer to the truth and upon cloning the repo, it was more clear
> what didn't work.
This is *one* data-point, you can't make such overreaching
generalizations from *one* data-point; you will often be wrong.
> The early history of gitifyhg is quite chaotic and I
> didn't realize at first how much code turned out to be borrowed from
> remote-hg. I don't know whether you wrote all of remote-hg or borrowed
> significant parts from elsewhere. To be honest, I don't really care,
> but it would be good to coalesce around one project that is well-tested
> and has documented behavior so that the poor folks stuck with Mercurial
> upstreams can have dependable behavior.
Indeed, and mails like this don't help one iota to achieve that. We
need data, arguments, and code, and you are not providing any.
Now, if you can go fetch the log of the error you had, that would be
great, otherwise I'll turn to something productive, like improving
remote-hg.
Cheers.
--
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
