4 ms·
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 us
by 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 agoContext 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.