Problem cloning a project whose subpath remote path has changed

Ludovic Chabant ludovic at chabant.com
Mon Mar 13 14:11:44 UTC 2017


Ah interesting, I didn't catch that the subrepo was also changing types (you like danger :) )

I think I would just delete the subrepo folder and do an update so Mercurial can recreate the repo by itself from the right URL.
For these kinds of things you basically need workarounds since subrepo workflows are still considered experimental/last-recourse stuff and don't support all situations.

l u d o .
. 8 0 17 80

> On Mar 13, 2017, at 06:49, Cathryn Griffiths <cathryn at ffctn.com> wrote:
> 
> Hi Ludovic,
> 
> Thanks for the reply and the suggested fix! I tried it out but unfortunately it didn't solve the problem in my case. Since I've changed the subrepo from a git subrepo to an hg subrepo, I can't just update the git remote - I'd need to delete the git subrepo, then add the hg repo, but that doesn't work. For example, immediately after I get the error message, if I go into the subrepo, it has the files and file structure of the git repo. If I delete the subrepo file entirely and try to commit the subrepo folder deletion, I get an abort message:
> 
> abort: last update was interrupted
> (use 'hg update' to get a consistent checkout)
> 
> Oddly enough, if I do hg update, it correctly pulls down the correct hg subrepo and does a checkout to the correct revision. 
> 
> Any other tips? 
> Thanks for your help!
> 
> Cathryn
> 
> 
>> On Sun, Mar 12, 2017 at 7:18 PM Ludovic Chabant <ludovic at chabant.com> wrote:
>> Hey,
>> 
>> I've run into that problem a couple times -- especially when you branch a sub-repo to write a patch, and therefore update your `.hgsub`, but then pull the changes from another clone of the parent repo.
>> 
>> I can't remember exactly what I do in this situation but I believe it goes like this:
>> 
>> 1) Pull the changes and update. Get the error message.
>> 2) Go into the sub-repo and update the origin URL. If it's a Mercurial sub-repo, edit the `hgrc` with the new path, and if it's a Git sub-repo, rename the origin remote.
>> 3) Run `hg update` again.
>> 
>> Good luck! :)
>>> Cathryn Griffiths March 8, 2017 6:37 AM via Postbox
>> 
>>> Hi all, 
>>> 
>>> I'm having trouble cloning one of my mercurial project repos that has a subrepo whose remote path has changed during the course of the project. I was hoping the community could provide some guidance on either how to fix this and/or why this is happening. 
>>> 
>>> Here's the situation: 
>>> 
>>> My project has a subrepo whose remote path has changed (Original path [Version 1]: git at bitbucket.org:<subrepoversion1>; New path [Version 2]: ssh://hg@bitbucket.org/<subrepoversion2>). I changed the path in the .hgsub file from that of Version 1 to that of Version 2. The .hgsubstate file was also updated to include the latest commit from Version 2. 
>>> 
>>> When I clone my project, the subrepo that gets cloned is that of Version 1, not Version 2. The cloning process then tries to checkout the commit that's provided in the .hgsubstate file. Since that commit belongs to subrepo Version 2, the clone aborts and shows an error message that "revision f3c8dab575b2d97eade69b06da1fcc2a06ba40eb does not exist in subrepo deps/ff-libs". Here's the output from the clone: 
>>> 
>>> requesting all changes 
>>> adding changesets 
>>> adding manifests 
>>> adding file changes 
>>> added 10 changesets with 114 changes to 95 files 
>>> cloning subrepo deps/ff-libs from git at bitbucket.org:<subrepoversion1> 
>>> Cloning into '<myprojectpath>/deps/ff-libs'... 
>>> remote: Counting objects: 3923, done. 
>>> remote: Compressing objects: 100% (1703/1703), done. 
>>> remote: Total 3923 (delta 2850), reused 3061 (delta 2202) 
>>> Receiving objects: 100% (3923/3923), 1.28 MiB | 0 bytes/s, done. 
>>> Resolving deltas: 100% (2850/2850), done. 
>>> Checking connectivity... done. 
>>> checking out detached HEAD in subrepo deps/ff-libs 
>>> check out a git branch if you intend to make changes 
>>> 79 files updated, 0 files merged, 0 files removed, 0 files unresolved 
>>> updating to branch default 
>>> pulling subrepo deps/ff-libs from git at bitbucket.org:<subrepoversion1> 
>>> abort: revision f3c8dab575b2d97eade69b06da1fcc2a06ba40eb does not exist in subrepo deps/ff-libs 
>>>  (in subrepo deps/ff-libs) 
>>> 
>>> 
>>> Here's the .hgsub file contents: 
>>> 
>>> deps/ff-libs = ssh://hg@bitbucket.org/<subrepoversion2> 
>>> 
>>> 
>>> ... and the .hgsubstate file contents: 
>>> 
>>> f3c8dab575b2d97eade69b06da1fcc2a06ba40eb deps/ff-libs 
>>> 
>>> 
>>> Why is the cloning process pulling subrepo Version 1 and not subrepo Version 2? 
>>> 
>>> In case it's relevant, I'm using Mercurial version 3.7.3 on Ubuntu 16.04. 
>>> 
>>> Thanks! 
>>> 
>>> Cathryn 
>> 
>>> _______________________________________________
>>> Mercurial mailing list
>>> Mercurial at mercurial-scm.org
>>> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>> 
>> 
>> -- 
>> Sent from Postbox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170313/2e469691/attachment-0002.html>


More information about the Mercurial mailing list