4 ms·

Personally, I prefer to never use git pull, and instead use git fetch then manually merge or rebase as appropriate. It's one more command, but I find it helps m

Personally, I prefer to never use git pull, and instead use git fetch then manually merge or rebase as appropriate. It's one more command, but I find it helps me visualize exactly what I want to happen.

rinchik 7y ago
> It's one more command, but I find it helps me visualize exactly what I want to happen are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?)
- lazulicurio 7y ago
  > are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?) Not in the sense that git pull has unpredictable behavior, but I like being able to view the remote history and manually diff against my local branch if there are changes that have been made.
  - jolmg 7y ago
    Though it's still better to do fetch when you want to compare first, pull outputs the ranges of commits that it's pulling for each branch, so you can just copy and paste that into a diff or log command, too. I say this because I used to just ignore the output, but then I found that it's useful, too. So, if git-pull outputs b3b2007..9bad624 master -> origin/master I can do `git diff b3b2007..9bad624` or `git log b3b2007..9bad624` to see what I just pulled.
- juped 7y ago
  Depends on your mental model. I think people expect something similar to CVS update at first, and then git surprises them by doing other things.
  - rinchik 7y ago
    I don't think git can surprise though... git GUIs on the other hand can be a mystery.
sixstringtheory 7y ago
I prefer to always use fast-forwarding when pulling, either with `git pull --ff-only` or setting pull.ff to "only" in configuration. This way, if a merge conflict is encountered, it will refuse the pull and you can then do your preferred manual resolution flow of either merging or rebasing. This way I can get the majority of pulls done quickly, because more often than not, I don't have to resolve conflicts (of course YMMV). I also prefer the slightly more verbose output from `git pull --ff-only` vs plain `git pull`. There's also `git pull --rebase` (mentioned in TFA but not really explained), which sort of combines `git pull --ff-only` followed by a `git rebase` if it failed.
- juped 7y ago
  I do this as an advanced user with a strong mental model of git, but I find the easier recommendation to others is to just not use the command - '--ff-only' just becomes another incomprehensible incantation without understanding.
juped 7y ago
You're correct to do so, since git pull is designed for Linus Torvalds or one of his vice-Linuses to merge a large remote patchset they've already reviewed

rinchik 7y ago

> It's one more command, but I find it helps me visualize exactly what I want to happen are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?)

lazulicurio 7y ago
> are you saying that git pull can produce some unwanted artifacts? (e.g. not do exactly what you want it to do?) Not in the sense that git pull has unpredictable behavior, but I like being able to view the remote history and manually diff against my local branch if there are changes that have been made.
- jolmg 7y ago
  Though it's still better to do fetch when you want to compare first, pull outputs the ranges of commits that it's pulling for each branch, so you can just copy and paste that into a diff or log command, too. I say this because I used to just ignore the output, but then I found that it's useful, too. So, if git-pull outputs b3b2007..9bad624 master -> origin/master I can do `git diff b3b2007..9bad624` or `git log b3b2007..9bad624` to see what I just pulled.
juped 7y ago
Depends on your mental model. I think people expect something similar to CVS update at first, and then git surprises them by doing other things.
- rinchik 7y ago
  I don't think git can surprise though... git GUIs on the other hand can be a mystery.

sixstringtheory 7y ago

I prefer to always use fast-forwarding when pulling, either with `git pull --ff-only` or setting pull.ff to "only" in configuration. This way, if a merge conflict is encountered, it will refuse the pull and you can then do your preferred manual resolution flow of either merging or rebasing. This way I can get the majority of pulls done quickly, because more often than not, I don't have to resolve conflicts (of course YMMV). I also prefer the slightly more verbose output from `git pull --ff-only` vs plain `git pull`. There's also `git pull --rebase` (mentioned in TFA but not really explained), which sort of combines `git pull --ff-only` followed by a `git rebase` if it failed.

juped 7y ago
I do this as an advanced user with a strong mental model of git, but I find the easier recommendation to others is to just not use the command - '--ff-only' just becomes another incomprehensible incantation without understanding.

juped 7y ago

You're correct to do so, since git pull is designed for Linus Torvalds or one of his vice-Linuses to merge a large remote patchset they've already reviewed