search

ingydotnet / git-subrepo

MIT License
3.18k stars 263 forks source link

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

Closed rightontrack42 closed 4 days ago

rightontrack42 commented 1 year ago

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.

admorgan commented 1 year ago

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.

rightontrack42 commented 1 year ago

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.

admorgan commented 1 year ago

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.

rightontrack42 commented 1 year ago

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

What can I do next?

admorgan commented 1 year ago

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.

rightontrack42 commented 1 year ago

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

admorgan commented 10 months ago

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.