Parent not updated in .gitrepo file after certain merges

[karptonite]

I've run into this a few times, and have now made a test repository to reproduce the issue: https://github.com/karptonite/subrepotest1

Here is what happened. subrepotest1 is a repository which contains subrepotest2 as a subrepo.

Normally, when a change is made in subrepotest2, we then use git subrepo pull to pull the changes into subrepotest1. This pulls in the update, and updates both the commit and the parent in the .gitrepo file.

But there is a problem. Say two users are working in suberepotest1. One of them pulls in new changes from subrepotest2 with git subrepo, and pushes them to the remote repository. The second user makes and commits some local changes in subrepotest1, then tries to push. There is a conflict, of course. The second user pulls from the remote with --no-rebase, and pushes again. All seems to be fine.

But then the next time a change is made on subrepotest2, and it is pulled into subrepotest1 via git subrepo, git subrepo fails to update the parent in the .gitrepo file. In fact, as far as I can tell, git subrepo will never update parent again. This doesn't seem to prevent the subrepo pulls from continuing to work, but it DOES cause very bad perfomance, the more commits you are removed from the issue.

You can see this whole process, including the bug, (in this commit here: https://github.com/karptonite/subrepotest1/commit/d023d663182a0826872c20fc64daffcea77676fc) in the repo linked above, but if you need more information, I'm happy to provide it.

[admorgan]

You are my best friend for the day. The problem is the merge combines the README.md and when git asks for history (using internal tricks because deep introspection would be prohibitively expensive), git says "Yep, there is a patch that has content from the folder you are interested in, and it has changes that didn't come from a squash merge". We then fall back to the really expensive merging function instead basically a FF via squash merge. This will take a bit of investigation on how to cheaply ensure we get the right answer.

I do appreciate the test I can add to our test cases after it is fixed.

[karptonite]

FYI, I've "Fixed" this occasionally by making a new commit, updating the "parent" to the previous (well, current) commit. If nothing else, making git subrepo pull -f or git subrepo clone -f rewrite the .gitrepo file even if it is otherwise up to date might help if the .gitrepo file gets into some unexpected state like this.

[admorgan]

That is the current workaround. But I believe we can make this better.