5 ms·

If there's any command that's not needed, it's git pull. This command basically combines git fetch and git merge. But merging the remote changes into your loc

by u801e 4y ago

If there's any command that's not needed, it's git pull. This command basically combines git fetch and git merge. But merging the remote changes into your local branch isn't always appropriate. I know that you can change the second action to rebase if you use the --rebase flag, but you have to remember to do that. I personally prefer just running git fetch and then deciding whether I want to merge, rebase, or just reset my local branch to the upstream commit and running the approriate command for that.

SoftTalker 4y ago
Pull, commit, and push are basically the only git commands I know or ever use.
mormegil 4y ago
You don't have to remember that. Just call git config --global pull.rebase true And you are set to use just git pull always.
- u801e 4y ago
  Except for the times I just want to have what's in upstream by resetting to that commit instead of merging or rebasing.
  - tdy_err 4y ago
    git fetch origin&& git reset --hard origin/$UPSTREAM
gregmac 4y ago
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).

by u801e 4y ago

SoftTalker 4y ago

Pull, commit, and push are basically the only git commands I know or ever use.

mormegil 4y ago

You don't have to remember that. Just call git config --global pull.rebase true And you are set to use just git pull always.

u801e 4y ago
Except for the times I just want to have what's in upstream by resetting to that commit instead of merging or rebasing.
- tdy_err 4y ago
  git fetch origin&& git reset --hard origin/$UPSTREAM

gregmac 4y ago

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).