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

[Max Horn <max@quendi.de>]

[-- Attachment #1: Type: text/plain, Size: 5988 bytes --]

Hi,

I am going to step away from this painful discussion and also this mailing
list, but I owed it to send one last reply with two of the problems I am
still seeing, simply in the hope that this will benefit some future
git-remote-hg users, but also to dispel any claims I was "hoarding" bugs to
somehow hurt Felipe.

Beyond that, I refuse to further "discuss" with Felipe on anything. It leads
nowhere, and he is so full of himself that it seems impossible to reason
with him. I will also refrain from countering everything he said, even
though I am sure he'll construe this as me admitting that he is right. I
don't care enough to try to keep up the flames *shrug*.  In the end,
everybody here can interpret this in whichever way they like.

Ah well, OK, I can't resist one last retort to one point Felipe wrote:

On 24.04.2014, at 02:23, Felipe Contreras <felipe.contreras@gmail.com> wrote:

> Max Horn wrote:
[...]
> 
>> Out of curiosity: How do you yourself use git-remote-hg in your daily work?
> 
> I don't.

So you don't eat your own dog-food (at most you sometimes snack on it)?
That would explain a lot...



Now to the issues: The following results are based on git "next" at revision
e8486314780a4. In addition, I cobbled together fixes from Felipe's
repository, namely the commit [1] he claimed to have fixed the multi head
issue I mentioned, as well as the changes from the fc/remote/fixes branch on
his github repository [2].

It is very well possible that this is still not the latest and greatest, and
that I missed some important patch that changes everything -- it's hard to
tell given the multitude of branches in Felipe's repository. Anyway, to
avoid confusion, I put my merged version of the script into a Gist [3], so
if I made a mistake there, it should be easy to discover.

Given that, the following script (which Felipe already knows from his
issue tracker [4]) still causes a fast-import crash after which "git pull"
from the remote hg repository is impossible, and the user has no idea
how to recover.

-- 8< --
#!/bin/sh -ex
rm -rf hgrepo gitrepo

# Create a multi-head repository
hg init hgrepo
cd hgrepo
echo a > a && hg add a && hg commit -m a
echo b > b && hg add b && hg commit -m b
hg update 0
echo c > c && hg add c && hg commit -m c
cd ..

# Clone it via remote-hg
git clone "hg::hgrepo" gitrepo

cd gitrepo
git gc --prune=now
git pull  # error
-- 8< --

Which results in this:

WARNING: Branch 'default' has more than one head, consider merging
fatal: object not found: 61780798228d17af2d34fce4cfbdf35556832472
fast-import: dumping crash report to .git/fast_import_crash_78219
fatal: Error while running fast-import

Any subsequent pulls then give something like this:

WARNING: Branch 'default' has more than one head, consider merging
fatal: mark :6 not declared
fast-import: dumping crash report to .git/fast_import_crash_78834
fatal: Error while running fast-import


What happens here is that a hg branch with two heads is created; this
repository is cloned via git-remote-hg. Both heads of the hg branch are
imported to git, but only one is referenced by a git ref. We then prune, and
end up with a "missing" commit that is still referenced by the marks file.

Note that the "next" version I used has fc/transport-helper-sync-error-fix,
but this did not stop "git fast-import" from trashing the marks file. :-(



The second script is similar but uses a closed branch to trigger essentially
the same issue. Background: closed branches are ignored by git-remote-hg,
meaning that no git ref is created for them, which can again lead to a
commit without a git ref but referenced by the marks file(s). However,
reproducing the bug in this case is a bit more complicated, because the
problem is obscured by another bug (?): Namely, if a hg branch is closed,
then git-remote-hg starts ignoring it, but does not seem to remove the ref
created for that branch.  So, the git user will not see that the remote
branch was closed (which is a bug, I'd say); on the upside, since the ref is
still around, no dangling commit is produced.

But we can "work around" this by re-opening the hg branch at a different
position, i.e. as child of an unrelated commit, which does *not* have the
commits of the original branch as parents. If we do that, git-remote-hg
moves the git ref to point to the new branch tip, and again we end up with a
dangling commit (the git commit corresponding to the former hg branch tip).

Again, this is something me and also colleagues "discovered" in real life
usage. So don't be fooled by the somewhat convoluted test script. This *does*
happen.

-- 8< ---
#!/bin/sh -ex

rm -rf hgrepo gitrepo

# Create a repository with two branches
hg init hgrepo
cd hgrepo
echo a > a && hg add a && hg commit -m a
hg update 0
hg branch foobar
echo b > b && hg add b && hg commit -m b
hg update default
cd ..

# Clone it via remote-hg
git clone "hg::hgrepo" gitrepo
cd gitrepo
git gc --prune=now
git pull
cd ..

# close the branch
cd hgrepo
hg update foobar
hg commit --close-branch -m "close branch"
hg update default
cd ..

cd gitrepo
git gc --prune=now
git pull
# This pull should trigger the issue, but for some reason, the ref
# origin/branches/foobar is still around, and so nothing happens.
cd ..

cd hgrepo
hg update default
hg branch -f foobar
echo c > c && hg add c && hg commit -m c
hg update default
cd ..

cd gitrepo
git gc --prune=now
git pull
# at this point, origin/branches/foobar is gone
git gc --prune=now
git pull      # now we get the error
-- 8< --


Goodbye,
Max


[1] https://github.com/felipec/git/commit/fbaae8caa51804a655fd6bc5727763b64e3c2e9f
[2] https://github.com/felipec/git/commit/1bf5fc892ebaa4a07dcd71ef96f8a8f5c876cb5f
[3] https://gist.github.com/fingolfin/11296352
[4] https://github.com/felipec/git/issues/56#issuecomment-40305442


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 235 bytes --]