Tracking breaks after rebasing a clone/pull commit parent

[ehsan-adi]

A subrepo pull or subrepo clone commit saves the SHA of the parent commit into the .gitrepo:subrepo.parent config. If this parent is later on changed due to a rebase, subrepo.parent becomes invalid, which breaks tracking. I suspect the main command that breaks is subrepo branch.
Could this be fixed by getting the parent through rev-parse or some other method that works well with rebases? Or is this a limitation of the tool?

[admorgan]

This is a limitation of the tool. parent is used for most git subrepo operations. The root of the problem is that we are stitching two repositories together keeping just enough information to be able to derive what is local and what is remote. The fact that rebase can break this tenuous link is the longest standing enhancement request. Unfortunately, I have not come up with a design that doesn't require git subrepo to be a part of the official git project to work around it. I personally have a git hook that checks to ensure that I didn't break the parent link. I could include that in the repo and add tooling to install that that in your git hooks as a band-aid.

[MaurGi]

This is very frequent operation - could be a deal breaker for us in using git subrepo.

Normal flow:

• From master, we create a feature branch
• We make changes to the feature branch
• Now we git subrepo pull <path> - the parent is now set to the previous commit in the feature branch.
• Now we squash merge the feature branch into master via a PR.

Problem: the previous commit is gone due to the squash, git subrepo can't pull anymore.

Any suggestion how to workaround this?

[MaurGi]

This is a limitation of the tool. parent is used for most git subrepo operations. The root of the problem is that we are stitching two repositories together keeping just enough information to be able to derive what is local and what is remote. The fact that rebase can break this tenuous link is the longest standing enhancement request. Unfortunately, I have not come up with a design that doesn't require git subrepo to be a part of the official git project to work around it. I personally have a git hook that checks to ensure that I didn't break the parent link. I could include that in the repo and add tooling to install that that in your git hooks as a band-aid.

could you share this hook?

[MaurGi]

@admorgan Have you thought about going back to the last commit in the default branch (master/main or whatever) and using that as the base when doing pull rather than using the current commit sha?
The base commit ID is of the current repo, the problem is that we lose the history when we rebase, but most of the rebases are with master and that remains in the history?

[Muzak93]

Normal flow:

• From master, we create a feature branch
• We make changes to the feature branch
• Now we git subrepo pull <path> - the parent is now set to the previous commit in the feature branch.
• Now we squash merge the feature branch into master via a PR.

Problem: the previous commit is gone due to the squash, git subrepo can't pull anymore.

Any suggestion how to workaround this?

Yeah this is a very similar situation here! This especially problematic since I cannot merge into main directly! Is there any idea how this could be fixed?

Could there be a "main_commit" which git subrepo uses instead if we are in a different branch?

Maybe something like this? So one can explicitly set the parent?
git subrepo pull subdir --use-parent=THE SHA of the parent

[MaurGi]

FYI - I ended up going with this - when I need to pull a change, I create a branch from master specifically for the subrepo update, then I pull the changes and I PR exclusively that change, then merge and rebase my feature branch on that.

[Muzak93]

Do you have a link to the pr / branch?

[taktran]

I found a potential fix for this issue here: #617