3 ms·

This is the way it works in Mercurial, where pull doesn't automatically merge or rebase. You might want to look at your colleagues' work without disturbing your

by ptx 6y ago

This is the way it works in Mercurial, where pull doesn't automatically merge or rebase. You might want to look at your colleagues' work without disturbing your uncommitted changes or merging your commits right at that very moment.

seba_dos1 6y ago
Well, if I want to look at my colleagues' work without disturbing my uncommitted changes or merging my commits right at that very moment, I use `git fetch`.
- ptx 6y ago
  Right, as do I. And "git fetch", as u801e was saying further up the thread, is perhaps what most people should actually prefer most of the time. Mercurial only has this pure fetch operation (although it calls it pull) and no combined fetch-and-merge operation. There is no reason fetching and merging have to be connected, so perhaps the most prominent command (as a counterpart to "push") shouldn't be this combined operation.
  - seba_dos1 6y ago
    OTOH, I use `git fetch` very rarely, since it's super rare to have unpushed or uncommited changes on the branch where I want to pull others' work from - so, in practice, I usually use `git pull`. The workflow is usually like this: 1. Work on my branch. 2. Checkout to master (with `git stash` if needed) 3. `git pull` 4. Do whatever I wanted to do with the updated branch (switch back and rebase, or test something, or start a new branch etc.) In a code-reviewed, merge request-oriented workflow there's little point in splitting `git pull` into separate commands.
    - u801e 6y ago
      On occasion, others will force push their feature branch that's associated with a merge/pull request. In that case, running git fetch origin and git reset --hard origin/branch-name to get your local tracking branch in the same state as the remote is the appropriate thing to do.
      - seba_dos1 6y ago
        Indeed, I forgot that I have `git fetch` also disguised under my `git mr` alias :)

3 ms·

This is the way it works in Mercurial, where pull doesn't automatically merge or rebase. You might want to look at your colleagues' work without disturbing your

by ptx 6y ago

seba_dos1 6y ago
Well, if I want to look at my colleagues' work without disturbing my uncommitted changes or merging my commits right at that very moment, I use `git fetch`.
- ptx 6y ago
  Right, as do I. And "git fetch", as u801e was saying further up the thread, is perhaps what most people should actually prefer most of the time. Mercurial only has this pure fetch operation (although it calls it pull) and no combined fetch-and-merge operation. There is no reason fetching and merging have to be connected, so perhaps the most prominent command (as a counterpart to "push") shouldn't be this combined operation.
  - seba_dos1 6y ago
    OTOH, I use `git fetch` very rarely, since it's super rare to have unpushed or uncommited changes on the branch where I want to pull others' work from - so, in practice, I usually use `git pull`. The workflow is usually like this: 1. Work on my branch. 2. Checkout to master (with `git stash` if needed) 3. `git pull` 4. Do whatever I wanted to do with the updated branch (switch back and rebase, or test something, or start a new branch etc.) In a code-reviewed, merge request-oriented workflow there's little point in splitting `git pull` into separate commands.
    - u801e 6y ago
      On occasion, others will force push their feature branch that's associated with a merge/pull request. In that case, running git fetch origin and git reset --hard origin/branch-name to get your local tracking branch in the same state as the remote is the appropriate thing to do.
      - seba_dos1 6y ago
        Indeed, I forgot that I have `git fetch` also disguised under my `git mr` alias :)