0

enter image description here

We have a project repository left.

Then we created a clone repository right from the topmost snapshot of the left (and worked there for some weeks).

How can we merge the two graphs?
(to let the team merge between the two)

NOTE: The stiching point contains the very same changeset, there are no conflicts involved.

Geri Borbás
  • 15,810
  • 18
  • 109
  • 172

1 Answers1

1

NOTE: The stiching point contains the very same changeset, there are no conflicts involved.

So, I think you should use git replace.

Most likely the command:

git replace --graft <commit> [<parent>…​]

If I understand well, you want to link the first blue commit with the last orange which are commits which contains exactly the same content.

The command is a little more complex because the last orange commit is a merge commit so you should use the sha1 of the 2 parents in the command line (the second to last orange and the last green).

So the command should be:

git replace --graft <Sha1_of_first_blue_commit> <Sha1_of_second_to_last_orange_commit> <Sha1_of_last_green_commit>

Once done, verify the history.

If that don't suits you, delete the replaced commit.

If that suits you, then you should use git filter-branch to make it permanent (with git filter-branch -- --all) by rewriting all the history after the commit replaced.

From doc:

NOTE: This command honors .git/info/grafts file and refs in the refs/replace/ namespace. If you have any grafts or replacement refs defined, running this command will make them permanent.

It will modify the history of blue and subsequent commits and so, to push it you will be obliged to do a git push --force-with-lease for all the refs that has been updated.

PS: There is also the possibility to push the replaced object (a solution here ) but that's not the recommended solution.

Philippe
  • 28,207
  • 6
  • 54
  • 78
  • It is awesome, thanks for the extra with the merge commit thing! I'll try it later today (then come back to accept). – Geri Borbás Nov 07 '18 at 09:36
  • Thanks! Will this rewrite commit hashes (like rebase does)? Should others team member checkout the entire repository again? Or should I even push it to a blank remote and checkout from that? – Geri Borbás Nov 07 '18 at 09:36
  • Seems I can't push the changes. – Geri Borbás Nov 07 '18 at 10:05
  • If I pull / clone, I still see it unstitched. – Geri Borbás Nov 07 '18 at 10:06
  • I pushed to a brand new repo still on the remote it seems unstitched. Could you help me out with this? – Geri Borbás Nov 07 '18 at 10:09
  • Did you made the 'filter-branch'? – Philippe Nov 07 '18 at 10:55
  • I made it after the first push (could this be the issue?), but I saw it rewriting stuff, then pushed again. – Geri Borbás Nov 07 '18 at 10:56
  • Huge thanks! So pushing with `--force-with-lease` will update remotes as well? Will this update all branches, or should I push them individually? – Geri Borbás Nov 07 '18 at 11:19
  • 1
    I think that since git v2, only one branch is pushed at a time so you will be obliged to do it for each one... – Philippe Nov 07 '18 at 12:10
  • Thanks, the blue graph have only 5-6 branches so far, so it won't be a big deal anyway. – Geri Borbás Nov 07 '18 at 13:37
  • Dude, thanks again, you saved the day! Rewriting everything made it pretty slow to `push` / `clone`, but we can now merge the two graphs nicely. For future reference, could have we used `git replace` even with different changeset in the tail and tip commits? – Geri Borbás Nov 09 '18 at 17:26
  • 1
    Due to how git works, each commit being a snapshot, but something strange would have happened. The changes/diff introduced by the commit replaced would have been different containing also all the changes that make tail and tip different (sorry, difficult to explain) – Philippe Nov 09 '18 at 21:40
  • So it would weld together the two changeset (the original commit content, and the tail/tip difference)? Perhaps one could make another commit to the top of the tip, that patches it up to the tail. I mean before stitching the graph together. So the original commit could be preserved this way. Thanks again for the insights, I'll read up some Documentation again, it must have more relevance now. – Geri Borbás Nov 09 '18 at 22:16
  • 1
    The way git store commits allow you to stitch every commits together but the diff calculated and shown to the developer will have more or less sense. So select the commits carefully and the parent(s) commit that you should choose must be as similar as possible. You could even select an identical commit, so that the stitch will introduce no changes (diff empty). – Philippe Nov 10 '18 at 09:19