9

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.

Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
cameronboehmer
  • 435
  • 2
  • 8
  • 1
    Why is this gross? Those two operations that are recorded, happened: first, the subtree got updated (squashed merge), then your main branch got updated (merge of the subtree). Why do you want to avoid that second merge commit at all costs? After all, it does carry information about what happened. – Sigi Apr 28 '14 at 04:01
  • 2
    Of course, you're right. It feels gross because most of the work in the parent project consists of work in the child, so the history is just a series of squash/merge commits. I'd prefer it behaved like a fast-forward merge with no merge commit, as the merges are not terribly meaningful. – cameronboehmer May 02 '14 at 03:41

1 Answers1

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.

Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188