0

How to add a virtual commit parent without changing commit id of child ?

Given a git repository (stored in an GitLab-Instance and for some reason on an other server in gitolite - both Servers inhouse) with that structure for public access on GitHub:

o-o-o-o-o-o-o-o-m-o-o-o-o-o-o-o-o-o-o-o-o-  origin Master
         /   \   \F-o-o-o-o-o-o-o           origin feature 
o-o-o-o-o-o-o-O                             origin oldthing

There are some documentations about git rebase, git replace, git replace --graft, git commit --amend and GraftPoints: But I am not realy sure about how to use them so that the first commit in feature (F) gets a second parent (i.e.) the last commit in oldthing (O). In best case no commit id should change, but it is acceptable if the commit Id for the first commit in `feature' will change.

Any Ideas?

Mort
  • 3,379
  • 1
  • 25
  • 40
ifrh
  • 29
  • 5

2 Answers2

1

@Chris is 100% accurate in how he describes how git hashes are constructed. (Though the tangent on collisions simply confuses the issue.)

You can use git replace to make the first commit of feature appear to have a second parent of the last commit of oldthing. But that would have to be done on the client-side, per-clone, not on the server side.

You can also do some sort of rebase to rebase feature onto a merge of m and O. It would be something like this (untested)

git checkout O
git merge m
rm -Rf *
git checkout -- F
git add .
git commit -C F
git rebase --onto HEAD m feature # This command probably isn't quite right. Some experimenting required.
Mort
  • 3,379
  • 1
  • 25
  • 40
0

I am not realy sure about how to use them so that the first commit in feature get a second parent (i.e.) the last commit in oldthing. In best case no commit id should change, but it is acceptable if the commit Id for the first commit in `feature' will change.

Commit hashes are generated from a number of inputs including the parent commit hash(es). Adding another parent to the first commit in feature will change its hash, which will cause the hashes of all descendant commits to change.

This is a fundamental part of how Git works. What you want to do is impossible¹.

¹Hash collisions are possible but extremely unlikely. In practice there is currently no way to generate an arbitrary hash collision.

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257