ingydotnet/git-subrepo

.gitrepo got under version control of the subrepo - what is the way out?

rightontrack42 opened this issue · 7 comments

Dear developers of git subrepo

We use git sub-repo as a means to share code between various repositories and branches. In one repository we use multiple sub-repo's, in that same repositore we share the subrepo between 2 branches.

We now have a problem: when we pull we get the error:   

git-subrepo: Command failed: 'git branch subrepo/Common '.
fatal: not a valid object name: ''

We looked into the problematic subrepo repository (Common.git) and found that the .gitrepo file is under version control in the that repository. As far as we understand this should not happen and causes the problem.
Also we see empty commits in the history of that repository, after the .gitrepo file was added

What is the best  procedure to get back in a state where we can synchronize again?

Thanks

PS, we do not understand how the file got under version control - it got there during a subrepo push command.

The .gitrepo flie should be under version control. It is how git-subrepo knows it current state. It should have been added when you did git-subrepo clone, and not having one should have prevented you from doing a push.

Is this a public repo? If so, can I get a link so I can look and possibly improve our testing routines to catch this?

If not, can I get a little more info?

  1. What version of git-subrepo are you using?
    • We have added some changes to catch "not a valid object name:" issues over the last couple of years.
  2. Does the parent SHA in the .gitrepo file exist in the repo containing the .gitrepo file?
    • Rebasing can loose the link to where the subrepo was linked into the rest of the repo.
  3. Does the commit SHA exist on the remote?
    • Rewriting history of the remote repo will cause issues.

If you are in a hurry, and don't have any unsynced local changes the fasted way to get back into sync again is to do a git subrepo pull --force Common. This will get the newest from the remote and fix up the .gitrepo so that it work again.

Thanks for the quick reply,

Sorry, I did not wrote down our problem with the proper terminology: here a clarification: the .gitrepo file is now both in the remote (Common.git) and in the parents. We enjoyed using git-subrepo without problems for a year, the problems started after the .gitrepo file landed in the remote.

As how we understand it, the .gitrepo file needs to be removed from the remote from all commits after it appeared - otherwise there is a chance that a git-subrepo pull will overwrite the .gitrepo file on one of the parents with wrong SHA's.

Question:
Will git subrepo pull --force Common restore the proper state, as we understand, by removing the .gitrepo file on the remote.?

If not, what is the best way to bring the remote and parents in a healthy state?


As to your questions:

This is not a public repo, but I can discuss with my co-workers what information can be shared. What information would you like to see?

(1)What version of git-subrepo are you using?
From the .gitrepo file in the remote I see version 0.4.3 and 0.4.5.
(Each developer maintains the version of git-subrepo on his/her machine. We have no enforcement on the version to use - I guess we should be strict on this)

(2)Does the parent SHA in the .gitrepo file exist in the repo containing the .gitrepo file?
No,
well .. the parent SHA exists only on one of the parents. I guess that now that the .gitrepo file is in the remote the .gitrepo file in the parent gets overwritten. Since we have multiple parents this parent SHA exists only on one parent.

(3)Does the commit SHA exist on the remote?
Yes,
but ... now all parents have the same remote commit SHA. I guess this is problematic, as I understand that the (remote) commit SHA will be used to determine the set of commits to pull from the remote - the 'diff' since the last git sub-repo pull.


Again, thanks a lot - we find git-subrepo very useful and if we can be of any help to improve the tool we will gladly do so.

The .gitrepo file contains the version of git-subrepo that was used for the last operation, so you should be able to tell from looking in the .gitrepo file that was included in the remote repo.

To resolve this situation the .gitrepo file will need to be removed from the remote server and then the pull command should make everything correct.

The .gitrepo file was removed from the remote - it did not solve the issue - the git pull still fails.

when I git subrepo clean and then pull I get:


$ git subrepo pull common

  • Assert that working copy is clean: /c/projects/ParentRepo

  • Check for worktree with branch subrepo/common

  • Deleting old 'subrepo/common' branch.

  • Remove worktree:

  • Create subrepo branch 'subrepo/common'.

    • Check if the 'subrepo/common' branch already exists.
    • Subrepo parent: eb9773354ece497cec33c9d04903490c34141603
    • Create new commits with parents into the subrepo fetch
    • Working on 41d0f4e0d911ca3f2e8b29dc3f85008d11ec5bd9
    • Ignore commit, no .gitrepo file
    • Working on 73487a47109d439f60f094f826288d4f71e2f91a
    • Ignore commit, no .gitrepo file
    • Working on ac5e5b288d7101481469d9e23488ff60b2723270
    • Ignore commit, no .gitrepo file
    • Working on 4fe61820b914772ea284e0fadde4328c22d23a25

    (many more similar entries )

    • Working on f3134a2b93c9ca715bf8bb2f8c109f7f27b66465
    • Ignore commit, no .gitrepo file
    • Working on 8d1bb5b0d7a598fce82c7b96f6641b151798168d
    • Ignore commit, no .gitrepo file
    • Working on ac93332de0195c412115c7e990bafb1f46961766
    • Ignore commit, no .gitrepo file
    • Create branch 'subrepo/common' for this new commit set .
      git-subrepo: Command failed: 'git branch subrepo/common '.
      fatal: not a valid object name: ''

What can I do next?

The no .gitrepo file error is referencing your local copy. It appears that you will need to git subrepo clone -f <URL> <path> to get back to a working state. Without a .gitrepo file the parent repo, the tool doesn't have enough information to operate.

Ok, we'll do that - do we first need to remove the .gitrepo file from the subrepo (Common.git) history ?

Did you get this sorted out. I am not sure why I didn't see that you responded. Yes you first need to remove the .gitrepo from the common.git repo.