Graft points or grafts enable two otherwise different lines of development to be joined together. It works by letting users record fake ancestry information for commits. This way you can make git pretend the set of parents a commit has is different from what was recorded when the commit was created.
As of Git 1.6.5, the more flexible
git replace has been added, which allows you to replace any object with any other object, and tracks the associations via refs which can be pushed and pulled between repos.
Reasons for Using Grafts
Grafts can be useful when moving development to git, since it allows you to make cloning of the old history imported from another SCM optional. This keeps the initial clone for users who just wants to follow the latest version down while developers can have the full development history available.
When Linus started using git for maintaining his kernel tree there didn't exist any tools to convert the old kernel history. Later, when the old kernel history was imported into git from the bkcvs gateway, grafts was created as a method for making it possible to tie the two different repositories together.
Git grafts are useful if you need to do subversion merges in a git branch maintained using git svn. Until very recent subversion releases subversion had no merge tracking which made repeated merges between 2 branches problematic in that you would have to remerge things which had already been merged before. Git grafting can alleviate these issues.
How to Use Grafts
On the technical side, graft points are configured via
.git/info/grafts file. It has one record per line
describing a commit and its fake parents by listing their
40-byte hexadecimal object names separated by a space and
<commit sha1> <parent sha1> [<parent sha1>]*
- An example script, for downloading the historic linux kernel pack file and inserting grafts point.
- A more readable history grafting script used by the ELinks project.