CODEWITHSUNDEEP
gitgit-rebase
Wesley Bland
Wesley Bland

Reputation: 9082

Is it possible to put --preserve-merges in the gitconfig

I'd like to set up at least one of my repositories (I'm fine if the setting is global) to always preserve branches when I rebase. Is there a way to set that in my gitconfig?

Upvotes: 4

Views: 596

Answers (2)

Guildenstern
Guildenstern

Reputation: 3869

The configuration variable rebase.rebaseMerges is slated for inclusion in the next version of Git (2.41.0). It allows you to always use --rebase-merges.

History/Context

  1. 1.5.3: git-rebase(1) learns --preserve-merges, at the same time as it learns --interactive
  2. 2.22: git-rebase(1) learns --rebase-merges and --preserve-merges is deprecated
  3. 2.34: git-rebase(1) unlearns --preserve-merges (read: now you get a fatal error if you try to use it)
  4. 2.41.0-rc0: git-config(1) (I guess?) learns rebase.rebaseMerges

Upvotes: 0

torek
torek

Reputation: 490078

The short answer is "no"; the medium-length answer is "sort of"; and the long answer is "you probably don't want to do that". :-)

The short answer is so easy because there is literally no configuration entry for git rebase to set preserve-merges mode automatically.

The "sort of" answer is because git pull can be configured to run git rebase --preserve-merges automatically. Remember that git pull is, in essence, just the pair of commands git fetch && git something, with the something part configurable: either merge or rebase, and if rebase, what flag(s) to use. But this only affects the rebase commands run by git pull, not the ones you run yourself.

The long answer is more complicated. While preserving merges is probably generally superior, in at least a few ways, to discarding them when rebasing, the fact is that rebase cannot preserve them. The only thing it can do, once some commits have been copied to new commits, is re-perform them. This can have new and/or different merge conflicts, vs the last time the merge was done. You should also pay close attention to the restrictions on merge preservation in the git rebase documentation.

Without getting into a lot of detail, it always seems to me that most commit graph subsets that "should be" rebased, rarely have any internal merges. If such a graph subset has a single final merge, you can simply strip away that merge (with git reset) before rebasing, and re-do that single merge manually at the end. (In fact, git rebase normally drops merge commits entirely, so you don't have to run the git reset itself in some cases. The one where you do have to run it is when the merge is into the branch onto which you intend to rebase. This is where git pull actually does the right thing when it uses git rebase -p, except that it fails to check for, and warn about, internal merges, which are sort of warning signs that rebasing might not be a good idea.)

Upvotes: 4

Related Questions