"Object [hash] already has a mark" on pushing about git-remote-hg HOT 14 CLOSED

Do you have a series of steps to reproduce this?

from git-remote-hg.

I am also having this issue hg version 2.4.1 and git 1.8.1.4.. however I can not push changes. as it promptly rejects the change claiming it's a non-fast-forward push? and that my branch is behind,.. however it is not.. it's the same as the remote..

from git-remote-hg.

Do you have a series of steps to reproduce this?

On our private repo at work, it happens on just about every push. I'm not sure how I'd go about getting it to be reproducible on a fresh repo, though.

from git-remote-hg.

same here, any solution? git 2.3 hg 2.8.2

from git-remote-hg.

@dfens to everybody who runs into this: If you have a way to reproduce it, I can look into it. Otherwise, this is just stabbing in the dark :-/

from git-remote-hg.

@fingolfin For what it's worth, I'm not using the bridge anymore; I just decided to never work on a Mercurial project again. ;-) More seriously, I think @felipec has abandoned the project; your fork seems to be active, and should probably be the first stop for people trying to get this working.

from git-remote-hg.

I actually just realized that I found a reproducible example for this... :) See fingolfin#2

@tomxtobin Yeah, it seems this is abandoned -- unfortunely, it still seems to be the number 1 hit on Google for git-remote-hg

from git-remote-hg.

@felipec I don't know if you're reading, but any thoughts to giving official blessing to @fingolfin's fork? If you're willing, an official pointer in the README would go a long way. :-)

from git-remote-hg.

@fingolfin
I have found test case to reproduce this issue.

1. Clone big repo. (In my case it contains ~18000 branches)
2. Add to remote mercurial repo commit in some .
3. Then make "git fetch" (in my case it takes near 3 hours)
4. While previous command working open new terminal and make "git fetch origin branches/"
5. Wait until "git fetch" from 3 will finished.
6. Add to local git repo commit to .
7. git push origin
8. ... error: Object [hash] already has a mark ...

from git-remote-hg.

@sayadyan Thanks, that is quite helpful. This suggests that at least one source of this bug is a concurrency issue. It might also suggest a way to easily reproduce the issue. E.g. instead of cloning a big repo, one could insert an artificial delay into git-remote-hg, triggered by an environment flag; then start one operation with that flag enabled; and start a second operation without the flag.

But I can't promise I'll get to work on this anytime soon.

from git-remote-hg.

Concurrency is not supported. Only one command should be run at a time.

from git-remote-hg.

Unfortunately, I may be working on a Mercurial repo in the near future, so I have a renewed interest in seeing this bug fixed. ;-) @felipec, if you're back to working on the project, it's great timing!

For what it's worth, the original issue I reported was not a result of my running concurrent operations.

from git-remote-hg.

Yeah, I thought so. The concurrency issue is a different thing.

from git-remote-hg.

If anybody is still experiencing this, feel free to comment and I'll reopen, in the meantime.

from git-remote-hg.