4 ms·

can you explain the `git pull origin master` thing one more time here?

• stormbrew 5y ago
  like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/` (or really `refs/heads/origin/`) is just a cached pointer to the last known state of that ref on the remote. All other commands operate only on these local references. So when you want to refer to what you know to be the state of things on `origin`, you can use `origin/master`. Otherwise that command has no particular knowledge of how to talk to origin. Incidentally this is a shortcut I use all the time to update my local master from a remote: `git fetch origin master:master` Which is super unclear in its meaning but it means fetch origin's master HEAD and put it in my local master ref. I actually use this more often than git pull nowadays.
  • deleted 5y ago
    [deleted]
  • nicoburns 5y ago
    I tend to default to `git pull --rebase`.
    • pjc50 5y ago
      I have this configured as default everywhere and strongly believe that merge-pulls are always wrong. The first place I used git we were learning together (i.e. nobody knew what a sensible workflow was) and people would push their local merge commits back to master. It was horrible.
      • stormbrew 5y ago
        `git config merge.ff=only` is really helpful for enforcing this. It makes you have to say what you want for any non-trivial update of a ref through pull or merge.
      • lmm 5y ago
        Strongly disagree. Never rewriting local commits is great for the same reasons that never rewriting published commits is great; if you rebase you lose the ability to fearlessly work on multiple branches in parallel that's the great advantage of git. Pushing merges is great. Pushing random (unreviewed) local commits directly to master is bad, but it's no worse when those commits are merges than when they're not. Conversely, rebasing master (which is quite easy to do if you're inexperienced but have been advised to use git pull --rebase) and pushing that creates a self-perpetuating mess that is very hard to fix (because even if you fix what you did, any other user who did a rebase-pull of master in the meantime is going to reintroduce the problem). Using rebase also trains you to force-push which makes messing up published branches much easier.
  • dorian-marchal 5y ago
    Also, one advantage of `git pull origin master:master` is that you don't have to checkout master first.
  • mbeex 5y ago
    > (or really `refs/heads/origin/`) It is worth the time to fully understand refspecs. Once people do, they tend to understand all essential ramifications of branch and repository naming.
  • zmmmmm 5y ago
    so the distinction here is - origin master <=== the actual remote version of the master branch - origin/master <=== a local branch that you cached from the "origin master" remote, may or may not be in sync with the real "origin master"
    • weaksauce 5y ago
      origin and master are completely arbitrary too... `git pull remote_repository_name branch_name` is the generic way to look at it instead of some magic incantation. I like to call origin "upstream" to differentiate them. and then git pull is another way to think of git fetch and git merge as one command roughly.
    • stormbrew 5y ago
      yep, that's right. Or rather, origin and master are just two parameters given to pull/fetch/push to describe a target while origin/master is just the local name for, as you say, the locally cached ref. Comparing against that locally cached ref is also what git uses to tell you how far behind/ahead of the upstream you are in `git status` or whatever. Fetch and push are the only git commands that actually talk to a remote (at the "user level" of the command set anyways, those are also composed of lower level commands).
• usr1106 5y ago
  I don't think using `git pull` is a particular good way of working. A pull is a fetch and merge or a rebase combined. If it's difficult to keep your mental model of some system up to date, I doubt that doing bigger steps at once makes things easier. So 1. run `git fetch` 2. if the textual output does not tell you what has happened, run `gitk -all` 3. Decide what to do. Rebase, merge, whatever. Of course if you know exactly what you are doing, pull can be fine. If you changed the repo yourself on another computer that is the case. Otherwise, how can you know your second step, before having even seen the data you are operating on? Well, it can work, but if it doesn't, don't complain.
  • u801e 5y ago
    > I don't think using `git pull` is a particular good way of working. I agree. For a DVCS like git, separating the network transaction from updating the working copy on disk is the best way to go about it. Going in the other direction, this is the default since git add, git commit and git push are executed separately.
  • xorcist 5y ago
    This is literally the first advice I give when teaching people git. The first months of use, just run the two commands separate. Many mistakes are avoided that way.
  • lmm 5y ago
    I agree, but I end up using `pull` anyway just because the alternative is so tedious. I wish there was a short command that did the same thing as pull without fetch: merge the remote-tracking version of the current branch's default upstream into the current branch. Essentially the whole concept of "upstream" is weird and non-orthogonal. Another one that bothers me is that as far as I can see there's no way to globally turn off setting an upstream on newly created branches (I can pass a flag to the specific "git branch" command, but that's tedious and error-prone).