[notapenny]

It usually works out fine when you do a `git pull --rebase`, but not everyone does this or has it setup so pulling might have some nasty effects. Generally helps to consider a feature branch as a private branch. Don't push to other people's features without asking, don't fuck up other people's work.

[OJFord]

Everyone absolutely should configure that. (Git config pull.rebase true.)

Such an annoying mess it leaves otherwise. And CI is building 'merge branch master', on the master branch, great.

[lambic]

Are there any downsides to doing this? Why isn't it on by default?

[OJFord]

I suppose just the usual 'rebase vs. merge' - i.e. if there are conflicts to resolve they will be dealt with commit-by-commit in the usual way when rebasing, whereas without the option set they will be dealt with all at once 'merge-style'. I happen to think that's a feature, but I know some don't like it.

I think there's less argument in favour of merge than usual with pulls though - since it's much less like a semantic merge to begin with for git-merging to preserve a history of.

I'm certainly not aware of any objective downside/gotcha/'oh but it doesn't work when...', no.

The docs only add that you might further want to set it to `interactive` or `merges` rather than `true`, for the effect of rebasing with those options: https://git-scm.com/docs/git-config#Documentation/git-config...

[formerly_proven]

> Why isn't it on by default?

Because git was written primarily for the Linux kernel and the defaults reflect that. The workflow of the Linux kernel is completely different from what most people outside of it do with git. "git pull" is used for opposite purposes in both worlds.

[heurisko]

I think it's the usually public vs private branch issue.

If you're merging a public branch with another public branch, then if you a rebase, rather than a merge commit, then you mess up the history for anyone has pulled that branch.

For private branches that isn't an issue.

[mkesper]

Combine with git config --global rebase.autostash for your own protection.

[nyanpasu64]

FWIW I set pull.ff to only, since I don't want merge commits or rebases happening without explicitly calling pull --rebase or --merge.

[cpcallen]

> And CI is building 'merge branch master', on the master branch, great.

How does one set this up in GitHub actions?

[OJFord]

By default it shows the commit message doesn't it? At least I'm not aware I've done anything for e.g. https://github.com/OJFord/terraform-provider-wireguard/actio...

The annoyance I'm describing is that when the commit message is 'merge branch master' (and especially if, as the label next to it shows, it is the master branch) this is crap and useless, and hiding the 'real' commits behind it that the committer had locally while behind the remote. If they had `git pull --rebase`d (or `git pull` with the config option set) the commit message would be that of the latest 'real' one.