13

Using git-subtree, the number of diffs to calculate when running a git subtree split increases over time, reaching values that can make a split take very long.

One way to fix that is to git rm the path, commit it and then git subtree add it back.

Is there a simpler/cleaner way of resetting a subtree?

raphink
  • 3,625
  • 1
  • 28
  • 39

1 Answers1

1

When doing the split the --rejoin option can be used, which seems to exist exactly to reuse the splits that have already happened.

--rejoin::

This option is only valid for the split command.

After splitting, merge the newly created synthetic history back into your main project. That way, future splits can search only the part of history that has been added since the most recent --rejoin.

From https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

Community
  • 1
  • 1
Maic López Sáenz
  • 10,385
  • 4
  • 44
  • 57
  • That is interesting. I wish this could be done upon pulling/merging rather than splitting, since the split for us is pretty much a read-only operation. – raphink Jan 28 '13 at 09:10
  • But this count reset makes no sense for pulling and merging, since you are bringing in content rather that separating it from your own repository. If you mean to reuse the subtree commits that where previously added with a pull/merge, that already happens always: as long as you keep consistent on using or not `--squash` when bringing new subtree content any previous commits already there will be used and linked automatically. – Maic López Sáenz Jan 28 '13 at 12:58