Git-subrepo: git subrepo pull failure: Can't find a common ancestor

[mykmelez]

After cloning a subrepo last week, I tried to pull its latest changes today, only to be told: "git-subrepo: Can't find a common ancestor between refs/subrepo/embedding/spidernode/fetch and subrepo/embedding/spidernode. This might be the case if someone used push --force on the subrepo. You need to find out why and possibly reclone the subrepo."

No one has used push --force on the subrepo, and the revision I cloned last week is an ancestor of the latest commit on refs/subrepo/embedding/spidernode/fetch:

> git log subrepo/embedding/spidernode
commit d397804ca7e097112f1719126eac10864bd9f076
Author: Myk Melez <[email protected]>
Date:   Wed Jan 4 14:17:48 2017

    git subrepo clone --branch=master https://github.com/mozilla/spidernode.git embedding/spidernode

    subrepo:
      subdir:   "embedding/spidernode"
      merged:   "4470dab"
    upstream:
      origin:   "https://github.com/mozilla/spidernode.git"
      branch:   "master"
      commit:   "4470dab"
    git-subrepo:
      version:  "0.3.0"
      origin:   "https://github.com/ingydotnet/git-subrepo"
      commit:   "e4abaf4"
> git log refs/subrepo/embedding/spidernode/fetch | grep 4470dab
commit 4470dab42116e6fc191437e5ddb815a4e53e3ab1

After reviewing existing issues like #233, which led me to #216, I checked out the issue/216-B branch of git-subrepo and then tried pulling again, which succeeded:

> git subrepo pull embedding/spidernode
Subrepo 'embedding/spidernode' pulled from 'https://github.com/mozilla/spidernode.git' (master).
> git log embedding/spidernode
commit 19b6c0dc8045ad3cb19536e54aa86a8360215d58
Author: Myk Melez <[email protected]>
Date:   Thu Jan 12 13:13:08 2017

    git subrepo pull (merge) embedding/spidernode

    subrepo:
      subdir:   "embedding/spidernode"
      merged:   "eae120a"
    upstream:
      origin:   "https://github.com/mozilla/spidernode.git"
      branch:   "master"
      commit:   "eae120a"
    git-subrepo:
      version:  "0.4.0"
      origin:   "https://github.com/ingydotnet/git-subrepo"
      commit:   "b645cc9"

So perhaps this is a duplicate (or a subset) of #216. But I figured it might be useful to track it separately, given that the symptoms I observed didn't lead directly to that issue.

[grimmySwe]

Good job! Are you using the issue/216-B branch right now?

[mykmelez]

I switched back to master after completing the pull last week, but I haven't actually tried another pull since then. Presumably I'll need to switch back to issue/216-B when I do.

[dkebler]

I am getting the same error message when I do this.

1. Make a copy (locally) of a subrepo directory I wish to turn into new subrepo
2. Create a new empty remote repo
3. edit .gitrepo and change the remote= to point to the new empty remote repo
4. Make edits to new subrepo directory then commit and push them in main repo
5. do a git subrepo push newsubrepodir
   that's when the identical error message occurs.

If this is caused by bug ok, but maybe there is a best practices way to do what I am doing which is using an existing subrepo as a template for a new one.

So...I also checked out the issue/216-B branch and then tried the push again. It worked but...

there was error about invalid commit which I suspect is because the .gitepo file has erroneous commit and parents from the other subrepo... thus my question about best practices above.

[grimmySwe]

There is a -r <remote> flag for push/pull that should be used instead of editing the .gitrepo file. Otherwise I find your suggested best practice ok.

[dkebler]

yes I see that. Looks like you must also add the -u flag so that it updates the "remote" line of the .gitrepo file.

[grimmySwe]

That is true, forgot about the -u flag.

[cehoffman]

Adding that I was trying a very simple test of subrepo with 0.3.1. I wanted to start with a specific commit version of a subproject and then later upgrade to the current tip of master.

git subrepo clone <remote> <path> -b sha
git subrepo pull <path> -b master -u

With 0.3.1 this failed with Can't find a common ancestor. The commit I initially checked out was in the history path for master of the remote. I found this issue, installed the issue/216-B branch and tried again.

This time it worked as expected and had the contents of master checked out in the directory and staged for commit.

[thelonewolf]

I am having a similar problem but switching to 216-B doesn't help me.

I cloned a remote repo:

git subrepo clone <remoteUrl> <pathToDir> -b master

This works fine the files are pulled in and everything looks good.

Then I wanted to run some tests to make sure the two primary features I will be using are working, push and pull. So I made a change to a subrepo file (committed the change), and since I'm the only one working on this particular project no changes have been make to remote files. I then tried to push the changes to the remote to keep everything up to date.

git subrepo push <pathToDir> -b master -r <remoteUrl>

I only include the branch and remote url out of frustration since not including them resulted in the same error.

Can't find a common ancestor between refs/subrepo/pathToDir/fetch and subrepo/pathToDir. This might be the case if someone used push --force on the subrepo. You need to find out why and possibly reclone the subrepo.

I know that the push --force is not the case since it would have to have been me.
So then I tried a pull just to make sure:

git subrepo pull <pathToDir> -b master

Again same error message as above.

Now just as a shot in the dark does one of these _refs/subrepo/pathToDir/fetch and subrepo/pathToDir_ point to the location on the remote? Because if one of these is trying to access pathToDir/master on the remote that will fail, it's just master. But it should know that since the clone worked with no issues.

If you need anymore info let me know.

[grimmySwe]

@thelonewolf unittests included in git-subrepo should test this basic scenario so I can't really see anything without some more actual logs. can you add -vd flags to your commands? That will output some more information on what is actually going on.

Does it work if you work locally by creating a small test repo and then work against that?

[thelonewolf]

@grimmySwe I'll try to run those tests later today or tomorrow and reply with the results.

[chrisdtaylor]

Just curious if the fix for this issue will make it into an official release any time soon?

[grimmySwe]

Hi @chrisdtaylor, currently we are waiting for @ingydotnet to get some valuable spare time to review the suggested 0.4.0 release.

Meanwhile it's much appreciated if you test out the release_0.4.0 branch and see if you find any problems with it!

[chrisdtaylor]

@grimmySwe, will do! Thanks for the prompt reply!

[lief-erickson]

In case someone's looking for another data point, using the 0.4.0 release instead of 0.3.1 solved this issue for me.

[david-parsons]

Same here, works with 0.4.0 :)

[damonmaria]

Would love the fix in 0.4.0 to be pushed out through homebrew as it solved this problem for me too :)

[peetervois]

I saw this message too. I use the master branch HEAD version. This case may give some additional hints to you. In my repo I have 3 branches: PrdctA; PrdctB; Lib. Where the Lib branch content is used as subrepo inside PrdctA and PrdctB. The origin repo is another repository and I used the origin as source repository url for subrepo cloning. While cloning the subrepo from the Lib branch, for PrdctA refs/heads/subrepo/PrdctA/Lib all went correctly but for PrdctB the refs/heads/subrepo/PrdctB/Lib (PrdctA and PrdctB have different subdirectory) has no parent commit and is completely different lifeline. I tried to fix this by merging the refs/heads/Lib from the refs/heads/subrepo/PrdctB/Lib branches together locally moving the refs/heads/Lib forward, and resolving merge conflicts. To move also the refs/heads/subrepo/PrdctB/Lib forward, i tried the subrepo pull and saw this error. To solve this issue I had to change locally the history of the second lifeline by adding to it the correct common anchestor that was in some strange reason not been added while cloning. I managed not to push the change in lifeline's parent to origin, but as the branch head was moving forward correctly with _git push --all origin_, then I have not much of worry anymore. If this does not help, then let it be- it is too complex to remember and explain.

[grimmySwe]

Fix for this has reached master.