Why doesn't Git subtree use rebase?

Question

I've added another repo to my project using git subtree add, and now when I go to update my main project from the subtree project with git subtree pull --prefix=subtree-dir subtree-origin subtree-branch --squash, I end up with two new commits in my main history, the former of which says "Squashed 'subtree-dir/' changes from 618c8ff..822004d", and the latter is a merge commit referencing the former.

This feels gross.

I understand that the squash commit is necessary (or else all of the intervening commits from the subtree project), but is there any way to avoid the second merge commit? I would love to discover a pattern that behaves much like git pull --rebase.

In case you haven't heard it today, you're fantastic.

Answer 1

First off, you're right... Git subtree creates, at best, a squashed commit with no ancestors (the contents are from a different remote/repository) and a regular merge commit.

Git subtree doesn't offer a --rebase option. It's not in the source code. Git subtree always uses git merge to integrate changes. Specifically, it's using the subtree merge strategy (which inspired the subcommand name, I'm sure) to make the subdirectory "magic" and unrelated histories work out properly.

(More on "unrelated histories" here: https://stackoverflow.com/a/37938036/3619)

I don't think rebase understands the subtree merge strategy, so it's simply an inappropriate choice for integrating changes.