fatal: Not a valid object name: '' no2

[forry]

Hi,
I'm not a git expert. I'm using subrepo for one of the modules (dormon/geGL) of our framework (Rendering-FIT/GPUEngine). I don't have push rights to this module. I have done one local change to the module and committed it as part of the framework repo. After while I wanted to pull new version getting:

git-subrepo: Command failed: 'git branch subrepo/geGL '.
fatal: Not a valid object name: ''.

I have read through issue #350 but I don't think it applies to me since I haven't changed the remote or the .gitrepo by hand. I have tried clean and doing the suggested commands by hand.

I just need to merge in new changes. Is there another way apart from deleting and recloning the subrepo from scratch. And how to avoid this issue in the future?

Thanks, forry

[admorgan]

Is this something that you would still like help with? I know it has been a long time. I am sorry for the silence.

[forry]

Hi,
it's ok, and yes I would very much like to get help :). At least I will learn something. As I remember it the problem was, that there were a couple of files with mixed tabs and breaks in the subrepo. Git was constantly showing these files as modified but then it said that there are no changes. So I committed them as a local change and probably not via the subrepo command but to the parent repo. Then I was making some experiments and ending with the message above (don't remember exactly, a lot was going on and I wasn't working on that project since). And ofc I don't have a clue of how to make it right apart from deleting the subrepo, commit and pulling it back, which seems very bad for the history and all-around unclean.

So If you have any suggestions, I'll be happy to hear from you.

Thanks, forry

[admorgan]

Do you still have a copy of your workspace? If so zip it and attach it and I will be happy to investigate it. If you can't I understand it will just require more back and forth.

[forry]

Yes, I have. I tested it and packed the inside of my repo. The subrepo is in the geGL subfolder.
GPUE.zip

[admorgan]

I have found the issue, you performed a massive squash merge and git can not find it's way from your head to the past operations. Should really have a better error message here. You can get subrepo to work again with your directory by manually modifying the .gitrepo parent entry to point to the SHA before the squash, but since you also squashed a number of other subrepo pulls and updates, you will not get the desired results for a push, basically your squash caused the original clone to be a modified merge and you will not be able to extract the difference between it and the original without manual intervention. Future operations would work correctly between the two using the subrepo command.

[forry]

Ok, not sure if I understand it all right but, there's what I did:

• changed the hash in .subrepo to 6d35d138.. which is 1 commit before this massive squash
• committed this change by the top (GPUE) repo
• then called git subrepo pull geGL/ which then failed to automatically merge, there was one file that needed a by hand resolution. So according to the instruction I went to the .git/tmp, edited the file, added it and --continued the rebase.
• I went (cd) back to the top and since the subrepo pull was complaining about that there is already the subrepo/geGL branch I called git subrepo commit geGL/ .

$ git subrepo commit geGL/
Subrepo commit 'subrepo/geGL' committed as
subdir 'geGL/' to branch 'master'.

• So next I tryied subrepo pull again and expected "no changes" message but still got the previous message:

$ git subrepo pull geGL
git-subrepo: There is already a worktree with branch subrepo/geGL.
Use the --force flag to override this check or perform a subrepo clean
to remove the worktree.

I tried delete the branch by
git branch -D subrepo/geGL
Cannot delete branch 'subrepo/geGL' checked out at 'D:/GPUEngine/code/srcInlcude_merge/.git/tmp/subrepo/geGL'

Should I delete the .git/tmp by hand?

[admorgan]

I am typing this for clarification and not in the belief that you didn't do the correct steps.

From the out put of subrepo:

1. cd into .git/tmp/subrepo/geGL
2. Resolved the conflict
3. git rebase --continue
4. return the parent project
5. git subrepo commit geGL

After those steps have been completed then you should remove your worktree using subrepo clean. I personally believe that this should be automated, but I will have to talk with @ingydotnet to see if he agrees. If so we can add it to 0.5.0

[forry]

Thank you very much for the clarification. I, for some reason, thought that the subrepo clean will somehow revert the pulling process. After issuing the clean command everything now seems to be in order (further investigation might be needed because there are lots of things that I could have overlooked). Now the subrepo pull correctly states that I'm up to date.

Thank you so much for your time. I have learned! But one thing is bugging me. Does this experience means that creating subrepo in a feature branch that will be squashed and rebased to the other branch will always resolve to this kind of behavior meaning, that the subrepo needs to be created (parented) to some commit that will always be in the timeline of the branch the subrepo lives/will live in? I'm generalizing because in the early days when I learned that git can forget I was able to somehow squash commits even inside of the master (even though it was a bit hacky). Meaning that the subrepo don't know that you are squashing part of history in which it is parented?

And one other question, whenever I'm doing changes to the local subrepo (which I can't or don't want to push to it's origin) is it ok that I commit these changes from the top/host repo? I guess that is the design since subrepo commit is somehow for manual pulling and only branch in the subrepo/ branch, but to be sure.

Thank you very much

[admorgan]

You are correct, subrepo is blind to what happened inside a squash merge. This is true with subtrees and submodules also. The difficulty for subrepo is that the design says that a consumer that is not interested in pulling up on libraries should not need to directly install it. Therefore we can't add hooks that would automatically reparent during activities such as squash merges and rebases.

[admorgan]

Forgot to answer your second question. Yes, you can make modifications to the files in the subrepo in the parent. It will figure out what part applies to which subrepo and create the appropriate patches to push up stream if you desire, if you don't push it upstream then it will just merge your local changes with the upstream.

[forry]

Once again thanks for your time and patience.