search

schacon / hg-git

mercurial to git bridge, pushed to directly from the hg-git plugin in Hg
GNU General Public License v2.0
620 stars 71 forks source link

push from hg --> git always deletes submodule references from destination #255

Closed keithmarshall closed 10 years ago

keithmarshall commented 11 years ago

I'm running hg version 2.1 on LinuxMint Debian Edition. I maintain the mingw-get project for mingw.org; it is hosted at git://mingw.git.sourceforge.net/gitroot/mingw/mingw-get, and requires git://mingw.git.sourceforge.net/gitroot/mingw/build-aux as a git submodule, (the .gitmodules file in mingw-get refers to the read-only URI for build-aux).

Personally, I dislike git; I want to manage the mingw-get repository via hg. To achieve this, I have enabled the git extension for hg, and have created hg clones of both the mingw-get and build-aux repositories into a common local sandbox. Within the local mingw-get clone, I have mapped the subrepo reference via the local build-aux clone, as "build-aux = ../build-aux" in .hgsub; (I can't map it directly to the gitroot on SF, because that makes it impossible to ever push).

This arrangement works reasonably well: I can create arbitrary local clones in the same sandbox directory, and I can push my changes to the git origin on SF. However, there is one critical failure: every time I push, the build-aux submodule reference is deleted from the origin repository; (the .gitmodules file itself remains intact, but the actual submodule reference is deleted). To reinstate it, I can find no other workaround than to also keep a git clone of the origin, updated to the state prevailing after the hg push, in which I then must:

git submodule add git://mingw.git.sourceforge.net/gitroot/mingw/build-aux git commit -m 'Reinstate lost build-aux submodule yet again!' git push

This is annoying. Furthermore, it pollutes the git repository with repeated commits, for no purpose other than to repeatedly repair this hg screw-up. If I didn't find git so repulsive, I would just use it, and forget about hg.

durin42 commented 11 years ago

This should be fixed in tip. Is it not for you?

On Sep 3, 2012, at 2:40 AM, keithmarshall wrote:

I'm running hg version 2.1 on LinuxMint Debian Edition. I maintain the mingw-get project for mingw.org; it is hosted at git://mingw.git.sourceforge.net/gitroot/mingw/mingw-get, and requires git://mingw.git.sourceforge.net/gitroot/mingw/build-aux as a git submodule, (the .gitmodules file in mingw-get refers to the read-only URI for build-aux).

Personally, I dislike git; I want to manage the mingw-get repository via hg. To achieve this, I have enabled the git extension for hg, and have created hg clones of both the mingw-get and build-aux repositories into a common local sandbox. Within the local mingw-get clone, I have mapped the subrepo reference via the local build-aux clone, as "build-aux = ../build-aux" in .hgsub; (I can't map it directly to the gitroot on SF, because that makes it impossible to ever push).

This arrangement works reasonably well: I can create arbitrary local clones in the same sandbox directory, and I can push my changes to the git origin on SF. However, there is one critical failure: every time I push, the build-aux submodule reference is deleted from the origin repository; (the .gitmodules file itself remains intact, but the actual submodule reference is deleted). To reinstate it, I can find no other workaround than to also keep a git clone of the origin, updated to the state prevailing after the hg push, in which I then must:

git submodule add git://mingw.git.sourceforge.net/gitroot/mingw/build-aux git commit -m 'Reinstate lost build-aux submodule yet again!' git push

This is annoying. Furthermore, it pollutes the git repository with repeated commits, for no purpose other than to repeatedly repair this hg screw-up. If I didn't find git so repulsive, I would just use it, and forget about hg.

Reply to this email directly or view it on GitHub: https://github.com/schacon/hg-git/issues/255

keithmarshall commented 11 years ago

I don't know. It certainly remains an issue with the latest version available from LMDE's APT repositories.

I googled "push hg git delete submodule" and found only http://tinyurl.com/9st3hle, which seems kind of tangential to the issue. In the absence of anything more concrete, I didn't anticipate that a Mercurial build from tip might include a fix. I'd much prefer to stick with the APT releases generally, but if this issue is resolved by a more recent build, I'll certainly give it a try.

Just for clarification, I have three APT packages installed, namely mercurial, mercurial-common and mercurial-git. The former two are both version 2.1-1, and I assume these are derived directly from primary selenic.com releases. The latter is version 0.3.1-1; does this come from the same stable? IOW, is it the tip cloned from http://selenic.com/hg that I need to build? Or, do I need some other resource for the hg-git extension.

durin42 commented 11 years ago

hg-git comes from http://bitbucket.org/durin42/hg-git.

keithmarshall commented 11 years ago

Why did you close this? I said I'd give tip a try; I didn't agree that the issue had been resolved.

How do I reopen it? I have cloned https://bitbucket.org/durin42/hg-git and pointed my git extension config to it; after a subsequent push of mingw-get to the SF git repository, the gitlink for build-aux has been destroyed yet again, so no, tip does not fix this for me.

durin42 commented 11 years ago

Please contact the mailing list for support - I don't know enough about our submodules support to help you, but those on the list might.

durin42 commented 11 years ago

I just looked - this really really should be fixed by the 'next' bookmark. Try that.

wuzzeb commented 11 years ago

I had the same problem, and I can confirm that updating to the next bookmark fixes it. But just updating hg-git to the next bookmark does not directly fix the problem because pushes will still delete submodules. I needed to clone a fresh repository before pushes would not delete submodules, presumably because hg-git only creates the .hgsub files on first clone instead of on pulls?

durin42 commented 11 years ago

Yeah, you'll probably need to reclone, which sucks.

On Mon, Sep 17, 2012 at 1:01 AM, John Lenz notifications@github.com wrote:

I had the same problem, and I can confirm that updating to the next bookmark fixes it. But just updating hg-git to the next bookmark does not directly fix the problem because pushes will still delete submodules. I needed to clone a fresh repository before pushes would not delete submodules, presumably because hg-git only creates the .hgsub files on first clone instead of on pulls?

— Reply to this email directly or view it on GitHubhttps://github.com/schacon/hg-git/issues/255#issuecomment-8605020.

keithmarshall commented 11 years ago

Well, I had been using the 'master' bookmark, on which the issue remains. However, the 'next' bookmark does not fix the issue for me; if anything, it makes matters worse! Yeah, I agree that the need to clone anew sucks, the more so when I can't even do that successfully!

Back trace from the failing clone operation follows below. For all the intelligence I can glean from it, it might as well be in Martian; perhaps you can make more sense of it.

$ hg clone git+ssh://me@mingw.git.sourceforge.net/gitroot/mingw/mingw-get destination directory: mingw-get ["git-upload-pack '/gitroot/mingw/mingw-get'"] importing git objects into hg * unknown exception encountered, please report by visiting * http://mercurial.selenic.com/wiki/BugTracker * Python 2.7.2+ (default, Nov 30 2011, 19:22:03) [GCC 4.6.2] * Mercurial Distributed SCM (version 2.1) * Extensions loaded: git, record Traceback (most recent call last): File "/usr/bin/hg", line 38, in mercurial.dispatch.run() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 27, in run sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 64, in dispatch return _runcatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 87, in _runcatch return _dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 683, in _dispatch cmdpats, cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 465, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 737, in _runcommand return checkargs() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 691, in checkargs return cmdfunc() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 680, in d = lambda: util.checksignature(func)(ui, _args, _cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 456, in check return func(_args, *_kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 1157, in clone branch=opts.get('branch')) File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 350, in clone destrepo.clone(srcrepo, heads=revs, stream=stream) File "/usr/lib/python2.7/dist-packages/mercurial/localrepo.py", line 2265, in clone return self.pull(remote, heads) File "/home/keith/src/hg/hg-git/hggit/hgrepo.py", line 14, in pull return git.fetch(remote.path, heads) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 178, in fetch self.import_git_objects(remote_name, refs) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 619, in import_git_objects self.import_git_commit(commit) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 672, in import_git_commit gitmodules = self.parse_gitmodules(git_commit_tree) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 1243, in parse_gitmodules for section in tt.keys(): AttributeError: 'ConfigFile' object has no attribute 'keys'

durin42 commented 11 years ago

next is unreleased because it depends on a prerelease version of dulwich. You're just going to have to wait, unless you want to install dulwich tip as well. On Sep 17, 2012 4:37 PM, "keithmarshall" notifications@github.com wrote:

Well, I had been using the 'master' bookmark, on which the issue remains. However, the 'next' bookmark does not fix the issue for me; if anything, it makes matters worse! Yeah, I agree that the need to clone anew sucks, the more so when I can't even do that successfully!

Back trace from the failing clone operation follows below. For all the intelligence I can glean from it, it might as well be in Martian; perhaps you can make more sense of it.

$ hg clone git+ssh://me@mingw.git.sourceforge.net/gitroot/mingw/mingw-get destination directory: mingw-get ["git-upload-pack '/gitroot/mingw/mingw-get'"] importing git objects into hg * unknown exception encountered, please report by visiting * http://mercurial.selenic.com/wiki/BugTracker * Python 2.7.2+ (default, Nov 30 2011, 19:22:03) [GCC 4.6.2] * Mercurial Distributed SCM (version 2.1) * Extensions loaded: git, record Traceback (most recent call last): File "/usr/bin/hg", line 38, in mercurial.dispatch.run() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 27, in run sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 64, in dispatch return _runcatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 87, in _runcatch return _dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 683, in _dispatch cmdpats, cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 465, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 737, in _runcommand return checkargs() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 691, in checkargs return cmdfunc() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 680, in d = lambda: util.checksignature(func)(ui, _args, _cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 456, in check return func(_args, *_kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 1157, in clone branch=opts.get('branch')) File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 350, in clone destrepo.clone(srcrepo, heads=revs, stream=stream) File "/usr/lib/python2.7/dist-packages/mercurial/localrepo.py", line 2265, in clone return self.pull(remote, heads) File "/home/keith/src/hg/hg-git/hggit/hgrepo.py", line 14, in pull return git.fetch(remote.path, heads) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 178, in fetch self.import_git_objects(remote_name, refs) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 619, in import_git_objects self.import_git_commit(commit) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 672, in import_git_commit gitmodules = self.parse_gitmodules(git_commit_tree) File "/home/keith/src/hg/hg-git/hggit/git_handler.py", line 1243, in parse_gitmodules for section in tt.keys(): AttributeError: 'ConfigFile' object has no attribute 'keys'

— Reply to this email directly or view it on GitHubhttps://github.com/schacon/hg-git/issues/255#issuecomment-8632010.

keithmarshall commented 11 years ago

I guess I can wait; this actually doesn't interfere with my work flow at all, (but it might affect a git user, if any wished to collaborate in my development effort).

However, the implication of "presumably because hg-git only creates the .hgsub files ..." disturbs me. If hg-git creates .hgsub files, presumably based on the content of .gitmodules from the remote, without respecting any .hgsub already committed in that remote, then any hg clone from a git repository, which specifies a read-only URL in .gitmodules, will become effectively useless. This is so, because on a push hg itself will always attempt to push the submodule first; (personally, I consider this to be a design flaw in Mercurial's submodule support -- why is it necessary to push a submodule which has not changed?). If the submodule clone is read-only, that preliminary push must fail, and in failing, will abort the subsequent push of the main clone, where the changes to be pushed actually occurred.