I have used a git subtree, and while I kinda hate it. I still think it was the right call given the constraints.
This is not a reply because I don’t want to argue with the take that brought it to mind.
If, for some reason, you want to use git subtree, think very carefully about doing so. Reasons follow.
You’re effectively vendoring some other repository into yours now.
You’re introducing non-trivial merge commits into your repository. If you squash or rebase, you have to be very damned careful in a repo with a subtree because you could break it.
The accountability/traceability gained by using subtree over just copying the files is very thin.
Updating a subtree is frustrating. If you’re choosing subtree over submodule for that, I suggest you rework that shared code.
2/5
However infrequently you think that subtree is going to change, it’s going to change more than that.
Remember those non-trivial merge commits? I’m bringing them up again. You cannot rebase over a subtree merge. No, not even to just fix a commit message. Rebase assumes all merges are trivial. Subtree assumes that you haven’t destroyed its precious merge commits with its tracking line.
You have two choices for how you pull in updates to the subtree: pristine or squashed.
3/5
7 (cont). Does the source repo rebase or squash? Then you really shouldn’t squash the updates. But if you don’t squash, the you’re keeping a whole branch with full commit history tracking for the subtree.
8. Everyone who works in the repository now needs to know more about git. They have to pay more attention to it for not a lot of gain.
4/5
I guess that’s all I’ve got for general reasons. There’s also fuckery with JIRA issue tags in commit messages if you track those or use pre-receive hooks that reject commits with mentions of closed issues. Recall that you can’t rebase. You can filter-branch, but that is also painful and dangerous to the extent that it tells you to never use it.
5/5
This also ignores completely the concept of contributing back to the source repository. Generating synthetic trees that cleanly partition changes between subtree and non-subtree and then moving those changes to the subtree’s branch. Then I guess adding the subtree repo as a remote(?) and actually pushing to it. We ignored ALL of that as far too fragile, esoteric, and just damn weird. Changes flowed in one direction and we still mucked it up several times in the last couple years.
Add comment