We track a vendor's upstream version releases of a software product in git repositories we have set up. We make changes to this product in cloned git repositories. When a new version is released we git merge the changes into our custom repository and fix any merge conflicts between their changes and our changes.
The vendor provides releases in our local language and a worldwide language. We have only been tracking the local language but now after 10 merged releases we have realised that we need to be tracking the worldwide language so we can bring in changes from other vendors integrating with this software.
The commit history looks like this. Each \ is a merge between the two repositories.
local A - B - C - D
\ \
custom E - F - G
We need it to look something like
global X - Y - Z
\
local A - B - C - D
\ \
custom E - F - G
Is git reparent the answer for this or something else? I've looked at how to re-parent in Git and Setting git parent pointer to a different parent but I still wasn't clear on if this was the right thing to do.
You can’t really do that. Changing the parent of a commit will result in a completely new commit object with its own unique hash (identifier). That means that all commits that indirectly have this as a parent also need to change. And this commit would be the first commit in the whole repository, you would end up recreating all commits in your repository.
This is a simple way to break the work for everyone involved and is generally discouraged, in the same way as rebasing published commits is.
If you want to integrate the original history, you could import the commits X-Z on a separate, independent branch, and then in a commit after D merge them into your local branch. That way, you could result in something like this:
global X - Y - Z -------
\
local A - B - C - D - H
\ \ \
custom E - F - G ----- I
Now of course this won’t fix the previous commits, but it also won’t invalidate them. And you would still have the original history as X-Z, and the relation to your new code in H and later.