Hacker News Reader

Comment by u801e | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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

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

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.

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.

Except for the times I just want to have what's in upstream by resetting to that commit instead of merging or rebasing.

git fetch origin&& git reset --hard origin/$UPSTREAM

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

Reply on news.ycombinator.com