push ignores --dry-run and -n options and does the push about git

[fingolfin]

@VVSiz he already achieved that in the sense that it is part of the "contrib" dir of git.git . It was added there a couple of releases ago. But unfortunately, it seems felipe lost interest in this project for the time being, respectively he shifted his attention to other stuff for the time being.

In this particular case, I suspect that the issue is not caused bit felipe's code, but rather is due to a deficency of the git remote-helper protocol. I might be wrong, though -- but it might be a good idea raising this subject on the git development mailing list.

Finally, a shameless plug: If you like felipe's git-remote-hg, maybe also check out our "fork" of it, which has received lots of bug fixes and improvements compared to the code here: https://github.com/buchuki/gitifyhg

[felipec]

Yeah, fingolfin is correct, this is probably an issue in the remote-helper infrastructure, but it's fine to keep track of it here.

As for gitifyhg, what is the official remote-hg missing that gitifyhg fulfills?

[fingolfin]

Among the things in which gitifyhg differs compared to this remote-hg utility are the following. Note that some of these might be outdated with your recent changes, I was not yet able to review and/or test them. Nor is the list exhaustive.

• many new test cases (sadly still including quite some xfails). Several of the tests (both passing and xfailing) fail when used with remote-hg. U
• improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits)
• failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state (this is much easier to do thanks to the fact that gitifyhg always makes a clone, even if the hg repository is local to begin with)
• git notes are used to associate to each git commit the sha1 of the corresponding hg commit, to help users figure out that mapping
• internally, the marks are using the hg sha1s instead of the hg rev ids (the latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states)
• Better handling of various hg errors (e.g. dusty-phillips/gitifyhg@74b71f4)
• support for creating hg tags from git (i.e. pushing light git tags to heavy hg tags)
• the test suite is run after each push on Travis CI against several git / mercurial combinations; in particular, unlike all other remote-hg implementations I know, we explicit promise (and test) compatibility with a specific range of Mercurial versions (not just the one the dev happens to have installed right now)
• renaming a gitifyhg remote just works; doing that with remote-hg triggers a re-clone of the remote repository (if it works at all, I don't remember). See dusty-phillips/gitifyhg@68ce89bb32.

[fingolfin]

Oh, and I should add that at least one feature from the git contrib remote-hg was dropped in gitifyhg: Support for hg-git compatibility. None of us is using that, nor hg-git, so instead of leaving untested and unsupported code in, it was removed.

[felipec]

My reply is here:

http://article.gmane.org/gmane.comp.version-control.git/219909

As for hg-git, it's the more widely used mercurial-git bridge, and as such there's tremendous value in comparing the output of any tool, to the one of hg-git. When running the git.git that compare such output, gitifyhg doesn't pass a single one of those tests.

[felipec]

Fixed in commit 6c3986b.

However, a patch from Git is needed as well: http://article.gmane.org/gmane.comp.version-control.git/225012.