git-subrepo
git-subrepo copied to clipboard
ingydotnet
Fix error "fatal: Not a valid object name: ''."
Problem
In case there are no (relevant) commits (e.g. directly after git subrepo push) which cause subrepo:branch() (i.e. on git subrepo pull <subrepo>) to fail with an git error message
git-subrepo: Command failed: 'git branch subrepo/<subrepo> '. fatal: Not a valid object name: ''.
See issues #348, #350 and #424.
Cause
This is because second parameter to git branch is an empty string as variable prev_commit has not been set. Thus, branch creation fails in that case.
Solution
To create the subrepo branch, nevertheless, it can be created on the cloned/pulled commit from .gitrepo file (per variable subrepo_commit) as there have not been any relevant changes.
Furthermore – to avoid unnecessary large range on the subsequent call of git filter-branch – variable first_gitrepo_commit should be neutralized with subrepo_commit as well, so that variable filter results in an empty revision range.
If this blindly "fixes" the issues you linked I think that could be a problem. Your example of a pull after a push is desirable, but when the ancestry has changed I feel we should acknowledge that there is a potential for your code not being what you expect. I have to dive deeper, but I believe it would not effect the included issues because we would fail before we reach this code due to the SHA not existing. @ingydotnet I would like you to look at this one if you have some time.
Overall thank you, this has been a thorn in my side. I have another favor to ask. We are currently working on the release/0.4.2 branch would you mind applying these patches there instead?
Would you be willing to add some tests for this?
We were able to recreate the problem very well during the corrections to #497 and therefore believe that it was not just blindly fixed the issue linked. However, we have only been working with sub-repo for a few weeks and therefore have no experience in how to write suitable tests.
So – if @ingydotnet sees the need for this – it would be great if a more experienced developer could write some suitable tests.
I think I hit this after a sqash merge of a feature branch where I did git subrepo on the feature branch. Does that sound plausible?
I think I hit this after a sqash merge of a feature branch where I did git subrepo on the feature branch. Does that sound plausible?
Sounds plausible. If it reproducable in your case, perhaps you can check wether our fix is applicable on your situation.
Modify the parent sha in your .gitrepo file to be the previous commit in your repo.
Unfortunately that seems to "squash" all the changes across a bunch of commits into one... We work on branches that rebase off master, then merge, but it seems every time i have to update the SHA to the latest, so all intermediate messages are being removed.
Editing for others: you need to set the SHA to be much further back, to wherever you want it to check for changes (just after last synced SHA I believe).
Probably this PR refers to https://github.com/ingydotnet/git-subrepo/issues/503 and https://github.com/ingydotnet/git-subrepo/issues/532 as well.
What SHA do I use for the parent? Is SHA easier to get from the client or the server? Maybe I should git log on the subrepo folder to find this? I new sha parent hash that matched the server (no pushes since I pulled), committed, and still get the error.
I have been working with this patch, and have found a number of paths that cause issues with regenerating the branch. I am addressing this through UI improvements and better error messaging instead of automatic regeneration for these reasons.