17 ms·
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
by 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 agoOTOH, 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 agoOn 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 agoIndeed, I forgot that I have `git fetch` also disguised under my `git mr` alias :)