5 ms·

You can at least configure rebase to be the default: git config --global pull.rebase true I understand why this isn't the "safe" default option.. but at t

You can at least configure rebase to be the default: git config --global pull.rebase true I understand why this isn't the "safe" default option.. but at the same time, it's the sane default option for anyone working with others. Maybe it would make more sense for the default to be a prompt: "Your local and upstream both have changes: do you want to rebase (replay) your work on top or generate a noisy merge commit?" Luckily in many of the common usages (git flow, github flow, scaled trunk-based development) where developers are doing actual work on independent branches and merging via pull requests, this doesn't happen often.

graywh 4y ago
Not a fan of that, either. It just seems like the kind of command that new users should avoid because they won't anticipate any consequences and experienced users do avoid because they can anticipate any consequences.
- PaulDavisThe1st 4y ago
  Context dependent. With the "right" git workflow in use on a project/group/company/whatever, "rebase on pull" is what you want, always, no questions. With a different workflow, it may be what you absolutely do not want. So for some new users, its the right thing to do so they don't forget, for other new users its something they should avoid. Only the git workflow can determine that.
- gregmac 4y ago
  > experienced users do avoid I think experienced users use the common git workflows, which usually avoids this situation. But, FWIW, this is a litmus test for me of one's true git prowess. Merge commits like "Merged origin/master into master" tell me the user doesn't know how to use git (as in: doesn't know how to rebase). If you know how to rebase, I don't know why you wouldn't have this set by default, because undoing it if it accidentally happens is more work -- and requires rebasing anyway.
Nullabillity 4y ago
For the sake of anyone else on the project, please don't ruin your history like this.
- gregmac 4y ago
  This doesn't affect anyone else! Other than they don't see noisy, meaningless merge commits. It only takes effect when you are both behind AND ahead of the remote (as in: you have local unpushed commits, and there are remote commits you don't have). It pulls the remote commits first, then rebases your commits using those as a base. You are left with a repository where you are ahead of remote, and can just push your commits normally. Only your local history is affected (insofar as your hashes will change).
  - Nullabillity 4y ago
    No, you're now pushing up a history that is a lie. Those commits represent states that never existed, and which you never tested. They certainly don't represent your headspace at the time. Those merge commits are the truth. The histories diverged, and had to be reconciled at some point. If I'm trying to understand the history then I want to see that, not your idealized version where you try to pretend that the divergence never happened. It can be hard to accept sometimes, but you're putting in a lot of effort for an end result that just makes life worse for everyone involved.

graywh 4y ago

Not a fan of that, either. It just seems like the kind of command that new users should avoid because they won't anticipate any consequences and experienced users do avoid because they can anticipate any consequences.

PaulDavisThe1st 4y ago
Context dependent. With the "right" git workflow in use on a project/group/company/whatever, "rebase on pull" is what you want, always, no questions. With a different workflow, it may be what you absolutely do not want. So for some new users, its the right thing to do so they don't forget, for other new users its something they should avoid. Only the git workflow can determine that.
gregmac 4y ago
> experienced users do avoid I think experienced users use the common git workflows, which usually avoids this situation. But, FWIW, this is a litmus test for me of one's true git prowess. Merge commits like "Merged origin/master into master" tell me the user doesn't know how to use git (as in: doesn't know how to rebase). If you know how to rebase, I don't know why you wouldn't have this set by default, because undoing it if it accidentally happens is more work -- and requires rebasing anyway.

Nullabillity 4y ago

For the sake of anyone else on the project, please don't ruin your history like this.

gregmac 4y ago
This doesn't affect anyone else! Other than they don't see noisy, meaningless merge commits. It only takes effect when you are both behind AND ahead of the remote (as in: you have local unpushed commits, and there are remote commits you don't have). It pulls the remote commits first, then rebases your commits using those as a base. You are left with a repository where you are ahead of remote, and can just push your commits normally. Only your local history is affected (insofar as your hashes will change).
- Nullabillity 4y ago
  No, you're now pushing up a history that is a lie. Those commits represent states that never existed, and which you never tested. They certainly don't represent your headspace at the time. Those merge commits are the truth. The histories diverged, and had to be reconciled at some point. If I'm trying to understand the history then I want to see that, not your idealized version where you try to pretend that the divergence never happened. It can be hard to accept sometimes, but you're putting in a lot of effort for an end result that just makes life worse for everyone involved.