0

Take the case when a big chunk of some parent repository is taken as a mostly starting point for another child repository, deleted from the original, and made a submodule instead. (All of this has already been completed and is in the past now.)

I see that .git/info/grafts would allow one to preserve the history for git-blame and git-annotate, and can possibly be employed ex post facto.

However, what if the files are not exactly the same? E.g. one version was deleted from the old original parent repo, and a slightly modified version was committed to the new submodule child one? Can a reference still be made? Especially if both repositories continue to be updated, and one would rather not have to deal with re-writing any past history (any more than need be).

cnst
  • 25,870
  • 6
  • 90
  • 122

1 Answers1

0

Commits do not hold references to diffs, they hold references to trees, where a tree is basically what your working directory should look like. If you have commit A with tree 1, and commit B with tree 2, then when you ask to show the diff between A and B, git calculates the diff between tree 1 and tree 2.

From this, it should be a bit clearer that it doesn't matter that files aren't 100% identical when grafting. However, if they aren't 100% identical, any differences will (correctly) be shown when you ask to show the commit.

Note that although this is generally unrelated to submodules, submodules use independent gitdirs, so the parent history is not automatically available. You will need to make sure to fetch the required history before grafting will have any chance of working. Also, grafting is a local operation. Others cloning your repository won't have an option of getting the grafts. You may consider git replace instead, which uses regular refs, and which should be fetchable by others who want them.

  • It remains unclear how grafting would determine where the start of the tree (path-wise) is. Is it smart enough to know that a certain dir in the "parent" repo is now the root directory in the new child submodule repo? – cnst Jun 16 '14 at 20:23
  • @cnst Not directly, it isn't. However, git is smart enough to detect file renames, including where the new file is not 100% identical to the old one, and including moves to different directories, so you should get to see this as a deletion of everything outside of the subdirectory, and a bunch of renames of everyting inside the subdirectory to the root. And for those renames, if the files aren't identical, you should get to see the diff automatically as well (unless they're too different to be detected as a rename). –  Jun 16 '14 at 20:26