Для чего нужны .git / info / grafts?

От Git Вики:

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.

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-svn:

git grafts очень полезны для импорта дерева Git в репозиторий Subversion.

Например. Для начала я создал локальный репозиторий Git. Поработав над ним несколько дней, создав много коммитов, мне пришлось опубликовать его в центральном репозитории Subversion, и я не хотел терять историю.

Я нашел следующую статью с практическими рекомендациями: http://eikke.com/importing-a-git-tree-into-a-subversion-repository/

Подход трансплантатов упомянул на Крис Йонсен для объединения двух репозиториев больше не является допустимым полностью (только с трансплантатами) .
В Git 2.18 (второй квартал 2018 г.) функциональность «$GIT_DIR/info/grafts» была заменена механизмом «refs/replace/» (в течение некоторого времени) .
Внутренний код поддерживал его во многих местах, что было очищено. чтобы сбросить опору механизма «прививки».

См. совершить a3694d9, совершить f42fa47, совершить 8d0d81a, совершить e2d65c1, совершить f9f99b3, совершить 0115e03, совершить fb40429, совершить 041c98e, совершить e24e871 (28 апреля 2018 г.) и совершить d398f2e, RR_15_16_R, RR_15_16_R, RR_15_16_R, RR_15_16_R, апрель 2018 г. ^{(Merged by Junio C Hamano -- dscho -- in commit 352cf6c, 23 May 2018)}

Так что вместо

echo "$commit-id $graft-id" >> .git/info/grafts

Теперь вы делаете:

git replace --graft $commit-id $graft-id
git filter-branch $graft-id..HEAD

Deprecate support for .git/info/grafts

The grafts feature was a convenient way to "stitch together" ancient history to the fresh start of linux.git.

Its implementation is, however, not up to Git's standards, as there are too many ways where it can lead to surprising and unwelcome behavior.

For example, when pushing from a repository with active grafts, it is possible to miss commits that have been "grafted out", resulting in a broken state on the other side.

Also, the grafts feature is limited to "rewriting" commits' list of parents, it cannot replace anything else.

The much younger feature implemented as git replace set out to remedy those limitations and dangerous bugs.

Seeing as git replace is pretty mature by now (since 4228e8b (replace: add --graft option, 2014-07-19, Git 2.1.0) it can perform the graft file's duties), it is time to deprecate support for the graft file, and to retire it eventually.

Теперь (снова Git 2.18, Q2 2018) у вас есть:

replace: add --graft option

The usage string for this option is:

git replace [-f] --graft <commit> [<parent>...]

First we create a new commit that is the same as <commit> except that its parents are [<parents>...]

Then we create a replace ref that replace with the commit we just created.

With this new option, it should be straightforward to convert grafts to replace refs.

А до Git 2.20 (4 квартал 2018 г.) недавно представленные вспомогательные данные графа фиксации несовместимы с такими механизмами, как replace & grafts, которые «нарушают» неизменяемую природу отношения ссылки на объект. Отключите оптимизацию, основанную на ее использовании (и обновив существующий график фиксации), когда эти несовместимые функции используются в репозитории.

См. совершить 829a321, совершить 5cef295, совершить 20fd6d5, совершить d653824, совершить b775896, совершить 950c62b (20 августа 2018 г.) от Деррик Столи (gitster).
См. совершить 212e0f7, совершить 4a6067c (20 августа 2018 г.) от Стефан Беллер (derrickstolee).
^{(Merged by Junio C Hamano -- stefanbeller -- in commit 6d8f8eb, 16 Oct 2018)}

В Git 2.24 (4 квартал 2019 г.) «gitster» (аналог «upload-pack»), которому необходимо отключить граф фиксации при ответе на неглубокий запрос клонирования / выборки, больше не вызывает паники.

См. совершить 6abada1, совершить fbab552 (12 сентября 2019 г.) от Джефф Кинг (git fetch).
^{(Merged by Junio C Hamano -- peff -- in commit 098e8c6, 07 Oct 2019)}

## upload-pack: disable commit graph more gently for shallow traversal

When the client has asked for certain shallow options like "deepen-since", we do a custom rev-list walk that pretends to be shallow.
Before doing so, we have to disable the commit-graph, since it is not compatible with the shallow view of the repository. That's handled by 829a321 (commit-graph: close_commit_graph before shallow walk, 2018-08-20, Git v2.19.2).
That commit literally closes and frees our repo->objects->commit_graph struct.

That creates an interesting problem for commits that have already been parsed using the commit graph.
Their commit->object.parsed flag is set, their commit->graph_pos is set, but their commit->maybe_tree may still be NULL.
When somebody later calls repo_get_commit_tree(), we see that we haven't loaded the tree oid yet and try to get it from the commit graph.
But since it has been freed, we segfault!

So the root of the issue is a data dependency between the commit's lazy-load of the tree oid and the fact that the commit graph can go away mid-process.