3 ms·

Yep. I've been using git for years and still don't really understand the difference between fetch, checkout, and pull. The official docs are dogshit so I just

by nvy 3y ago

Yep. I've been using git for years and still don't really understand the difference between fetch, checkout, and pull. The official docs are dogshit so I just don't have time to figure out the minutiae.

gorgoiler 3y ago
Fetch means “safely fetch new data from one of your remotes without affecting any of your local work”. Pull means “do what fetch does, but with the spicy bonus risk that your precious work will be modified in an unexpected way depending on when and how you checked out the branch you’re on, what version of git you are using, and what config options you have set.”
- globular-toast 3y ago
  Can pull screw up your working directory if you haven't committed something? I thought that was reserved for `reset --hard`. In any case, I always teach people to commit more. As long as you commit, you can't lose anything.
  - seba_dos1 3y ago
    Most confusion I've ever seen from beginners comes from them trying to pull, ending up in a conflict and not realizing, not resolving it but not aborting either and just continuing their work and then getting confused when trying to do anything else.
    - globular-toast 3y ago
      That's true. I think the worst thing about git CLI is it hides the state and forces you to issue another command to query the state, but you could easily forget. A lot of people add the thing to the PS1 to show some state, but it's not default. However, I'm still not sure git will actually fuck things up with a pull. I think that's the users later when they go nuclear and delete the repo.
- lelanthran 3y ago
  > Pull means “do what fetch does, but with the spicy bonus risk that your precious work will be modified in an unexpected way depending on when and how you checked out the branch you’re on, what version of git you are using, and what config options you have set.” That's going to happen anyway when you need to rebase/merge. May as well type one command (pull), deal with the conflicts and continue, rather than type command, type another command, deal with the conflicts and continue. Unless you have some other strategy that does not include rebasing or merging upstream changes, there's no advantage to not pulling. And, TBH, if you workflow is "this branch is worked on while specifically ignoring other changes by other people", then you have bigger problems than version control.
  - masklinn 3y ago
    > Unless you have some other strategy that does not include rebasing or merging upstream changes, there's no advantage to not pulling. Of course there is: after fetching you can see if there are differences between upstream and local, you can inspect those difference, and you can decide how to reconcile the two. “Pull” is a big hammer which unconditionally performs an integration operation, and the default integration is one you almost never want too. There‘a no advantage to pulling IME, in the best car scenario it’s just an alias for “git fetch && git merge”, if that’s what you want you can just do that and create your own alias.
    - lelanthran 3y ago
      > Of course there is: after fetching you can see if there are differences between upstream and local, you can inspect those difference, and you can decide how to reconcile the two. [FWIW, it seems you know more about this than I do, so don't think that I am purposefully trying to be annoying. I'm not, I hope :-)] I agree that you can see the differences, but I'm asking how helpful is this. For me, anyway (not an advanced git user) seeing the differences between master and my feature branch before doing the rebase makes no difference - I'm still going to do the rebase no matter what I see in the feature branch. It is going to be rare for me to be able to see, of the 10 merges to master, if an of them are going to break the code in a way that I cannot continue (in which case I won't rebase). The longer I put off rebasing, the harder it is going to be to do it, so I am highly motivated to rebase on whatever master has, even if it just got broken, because it will be more painful to rebase later.
- tigerlily 3y ago
  There should really be a 'git pull --hard' option.
  - globular-toast 3y ago
    As in `git fetch ...; git reset --hard ...;`? I guess that is what people are trying to achieve a lot of the time... For some reason people are more scared of `reset` than `pull`, though.
skinner927 3y ago
Fetch updates your local repository (which is behind the scenes, separate from your literal local files). Checkout modifies local files to be like whatever you’re checking out. And pull’s only purpose is to screw up your local files. :)
- nvy 3y ago
  >Fetch updates your local repository (which is behind the scenes, separate from your literal local files). Therein lies the chief problem with git: it's a leaky abstraction. Nobody actually should give a flying shit about commit hashes and ^HEAD or whatever it's called. All the newbie tutorials you find waste so much time on that, but what people really care about when they start using git is "what the fuck happened to my files and how do I get them back the way they were". Git docs and tutorials are breathtakingly bad at showing this.
da39a3ee 3y ago
pull is fetch + merge By default. There's an option to make it fetch + rebase. But anyway it's a complicated composite command. I agree with the others. Don't use pull: use the underlying simpler commands directly.

by nvy 3y ago

gorgoiler 3y ago

Fetch means “safely fetch new data from one of your remotes without affecting any of your local work”. Pull means “do what fetch does, but with the spicy bonus risk that your precious work will be modified in an unexpected way depending on when and how you checked out the branch you’re on, what version of git you are using, and what config options you have set.”

globular-toast 3y ago
Can pull screw up your working directory if you haven't committed something? I thought that was reserved for `reset --hard`. In any case, I always teach people to commit more. As long as you commit, you can't lose anything.
- seba_dos1 3y ago
  Most confusion I've ever seen from beginners comes from them trying to pull, ending up in a conflict and not realizing, not resolving it but not aborting either and just continuing their work and then getting confused when trying to do anything else.
  - globular-toast 3y ago
    That's true. I think the worst thing about git CLI is it hides the state and forces you to issue another command to query the state, but you could easily forget. A lot of people add the thing to the PS1 to show some state, but it's not default. However, I'm still not sure git will actually fuck things up with a pull. I think that's the users later when they go nuclear and delete the repo.
lelanthran 3y ago
> Pull means “do what fetch does, but with the spicy bonus risk that your precious work will be modified in an unexpected way depending on when and how you checked out the branch you’re on, what version of git you are using, and what config options you have set.” That's going to happen anyway when you need to rebase/merge. May as well type one command (pull), deal with the conflicts and continue, rather than type command, type another command, deal with the conflicts and continue. Unless you have some other strategy that does not include rebasing or merging upstream changes, there's no advantage to not pulling. And, TBH, if you workflow is "this branch is worked on while specifically ignoring other changes by other people", then you have bigger problems than version control.
- masklinn 3y ago
  > Unless you have some other strategy that does not include rebasing or merging upstream changes, there's no advantage to not pulling. Of course there is: after fetching you can see if there are differences between upstream and local, you can inspect those difference, and you can decide how to reconcile the two. “Pull” is a big hammer which unconditionally performs an integration operation, and the default integration is one you almost never want too. There‘a no advantage to pulling IME, in the best car scenario it’s just an alias for “git fetch && git merge”, if that’s what you want you can just do that and create your own alias.
  - lelanthran 3y ago
    > Of course there is: after fetching you can see if there are differences between upstream and local, you can inspect those difference, and you can decide how to reconcile the two. [FWIW, it seems you know more about this than I do, so don't think that I am purposefully trying to be annoying. I'm not, I hope :-)] I agree that you can see the differences, but I'm asking how helpful is this. For me, anyway (not an advanced git user) seeing the differences between master and my feature branch before doing the rebase makes no difference - I'm still going to do the rebase no matter what I see in the feature branch. It is going to be rare for me to be able to see, of the 10 merges to master, if an of them are going to break the code in a way that I cannot continue (in which case I won't rebase). The longer I put off rebasing, the harder it is going to be to do it, so I am highly motivated to rebase on whatever master has, even if it just got broken, because it will be more painful to rebase later.
tigerlily 3y ago
There should really be a 'git pull --hard' option.
- globular-toast 3y ago
  As in `git fetch ...; git reset --hard ...;`? I guess that is what people are trying to achieve a lot of the time... For some reason people are more scared of `reset` than `pull`, though.

skinner927 3y ago

Fetch updates your local repository (which is behind the scenes, separate from your literal local files). Checkout modifies local files to be like whatever you’re checking out. And pull’s only purpose is to screw up your local files. :)

nvy 3y ago
>Fetch updates your local repository (which is behind the scenes, separate from your literal local files). Therein lies the chief problem with git: it's a leaky abstraction. Nobody actually should give a flying shit about commit hashes and ^HEAD or whatever it's called. All the newbie tutorials you find waste so much time on that, but what people really care about when they start using git is "what the fuck happened to my files and how do I get them back the way they were". Git docs and tutorials are breathtakingly bad at showing this.

da39a3ee 3y ago

pull is fetch + merge By default. There's an option to make it fetch + rebase. But anyway it's a complicated composite command. I agree with the others. Don't use pull: use the underlying simpler commands directly.