1

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.

Community
  • 1
  • 1
Daniel Compton
  • 13,878
  • 4
  • 40
  • 60
  • I don't understand your history examples. What does the `\ \` part mean? "local", "global" and "custom" are branches? how are the conected? (It looks like they would be completely separate.) Please fix your question to make the actual situation more obvious. – michas Feb 26 '14 at 06:12

1 Answers1

1

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.

poke
  • 369,085
  • 72
  • 557
  • 602
  • Would an alternative be merging out from local to global? This would make local the master branch. It wouldn't be semantically great but it seems like it would still be fine. – Daniel Compton Feb 26 '14 at 20:41
  • Sure, you could do that, but you should know that branch names don’t carry any meaning. They are just named pointers to commits in the graph. If the name bothers you, you can easily rename branches using `git branch -m`; you could completely work without a master branch if you like. – poke Feb 26 '14 at 20:45
  • Sorry, that wasn't clear, I mean that it would make local the root branch (contains the parent commit of all future changes). – Daniel Compton Feb 26 '14 at 22:29
  • Yeah sure, if that makes more sense to you, you can surely do that as well. Whatever fits your workflow better :) – poke Feb 26 '14 at 23:02