4 ms·

Recently found out about the usefulness of this command -- was amazed at how much simpler it made integrating changes. It can get tricky with conflicts, but now

Recently found out about the usefulness of this command -- was amazed at how much simpler it made integrating changes. It can get tricky with conflicts, but now the commits in my pull requests aren't getting polluted with commits that are just "Pulling in changes" full of other people's code.

jcrites 11y ago
Yes. I'd highly recommend making `git pull --rebase` the default behavior of your `git pull` operation. I'd thought that the Git folks were going to make this the default behavior at some point. It really ought to be. `git pull --rebase` is a much better conceptual way to integrate changes from your upstream when working together collaboratively. The rationale is this: a newly released change should be, in the ideal case, simply an incremental diff against the head of the branch. It may have been developed by forking off at some point in the past, and incorporating changes over time, but those are implementation details of how the diff has been constructed. Once the diff is ready to go, ready to be committed, it's just an incremental change to the head. By working in a branch and using `git pull --rebase` to incorporate upstream changes, you keep your code in a constant state of being "an incremental addition" to the primary branch. Indeed, it's very similar to what happens with Perforce when one runs `p4 sync ...`, by comparison - your local code is updated to account for the new remote contents. Finally when you submit, your change looks like a single incremental commit, or series of commits. The resulting history is simple and linear. Sometimes people object to this because they claim that source history should be the "true history of what happened", whatever that means. I believe those arguments miss the point of source history. Source code history is always an abstraction over what really happened. Imagine an extreme example: an IDE that generates a single source commit for every keypress you type while editing a file. That's the true history of what really happened. But is it useful to commit that history to a repository? Of course not - that history is kept locally in your IDE as undo buffer. Similarly, it's often not useful to pollute the commit history with implementation details of how you developed the change (sometimes, but not often). When you develop changes locally and push them upstream, you rightfully make a judgment call about what level of detail about the development process should be exposed in the history, and what level of detail should be hidden. For example, you might hide detail by combining many keypresses into one commit, as is conventional, or by squashing multiple related commits into a single commit. You might hide the detail about how your change was developed over time by using rebase to make it appear as if it's an incremental change to the head, even if it was developed over time and involved several integrations from the upstream. Sometimes these history-abstracting changes are not appropriate, such as if you truly need to develop a branch in parallel with the main branch, that many people are collaborating on. In that case, a branch may be appropriate. Most of the time, it's ideal to develop changes directly on the master branch, as an incremental change to it, using `git pull --rebase` to keep local changes up to date, which will result in a simple, linear history.
- throw_away 11y ago
  git config --global pull.rebase true
  - rev_bird 11y ago
    Ooooohhh I'm going to be the cool kid at work on Monday when I unleash this one. Thanks.

jcrites 11y ago

Yes. I'd highly recommend making `git pull --rebase` the default behavior of your `git pull` operation. I'd thought that the Git folks were going to make this the default behavior at some point. It really ought to be. `git pull --rebase` is a much better conceptual way to integrate changes from your upstream when working together collaboratively. The rationale is this: a newly released change should be, in the ideal case, simply an incremental diff against the head of the branch. It may have been developed by forking off at some point in the past, and incorporating changes over time, but those are implementation details of how the diff has been constructed. Once the diff is ready to go, ready to be committed, it's just an incremental change to the head. By working in a branch and using `git pull --rebase` to incorporate upstream changes, you keep your code in a constant state of being "an incremental addition" to the primary branch. Indeed, it's very similar to what happens with Perforce when one runs `p4 sync ...`, by comparison - your local code is updated to account for the new remote contents. Finally when you submit, your change looks like a single incremental commit, or series of commits. The resulting history is simple and linear. Sometimes people object to this because they claim that source history should be the "true history of what happened", whatever that means. I believe those arguments miss the point of source history. Source code history is always an abstraction over what really happened. Imagine an extreme example: an IDE that generates a single source commit for every keypress you type while editing a file. That's the true history of what really happened. But is it useful to commit that history to a repository? Of course not - that history is kept locally in your IDE as undo buffer. Similarly, it's often not useful to pollute the commit history with implementation details of how you developed the change (sometimes, but not often). When you develop changes locally and push them upstream, you rightfully make a judgment call about what level of detail about the development process should be exposed in the history, and what level of detail should be hidden. For example, you might hide detail by combining many keypresses into one commit, as is conventional, or by squashing multiple related commits into a single commit. You might hide the detail about how your change was developed over time by using rebase to make it appear as if it's an incremental change to the head, even if it was developed over time and involved several integrations from the upstream. Sometimes these history-abstracting changes are not appropriate, such as if you truly need to develop a branch in parallel with the main branch, that many people are collaborating on. In that case, a branch may be appropriate. Most of the time, it's ideal to develop changes directly on the master branch, as an incremental change to it, using `git pull --rebase` to keep local changes up to date, which will result in a simple, linear history.

throw_away 11y ago
git config --global pull.rebase true
- rev_bird 11y ago
  Ooooohhh I'm going to be the cool kid at work on Monday when I unleash this one. Thanks.