4 ms·

I'm really pleased by this change. In my early days of git usage the asymmetry of git pull and git push confused me on several occasions, and I'm glad to see th

I'm really pleased by this change. In my early days of git usage the asymmetry of git pull and git push confused me on several occasions, and I'm glad to see that git is willing to make breaking changes towards a cleaner interface.

ISL 13y ago
As someone in still in early days of git usage (< 1 yr), I've found it quite confusing that pull doesn't pull every matching branch. I'm now sufficiently familiar with git to understand why, but it's sure been frustrating.
- lisper 13y ago
  Could you please explain it? Because I don't get it. Git's (current) behavior seems exactly backwards to me. It seems to me that what you want is for push to default to the current branch, but pull to default to all branches. i.e. I want push to mean "push what I'm currently working on" and pull to mean "sync my repo's state to be as close as possible to the remote repo's state".
  - CUViper 13y ago
    I think what you want in a pull is really just "git fetch", which will update all remote branches. In case you haven't realized this separation, try "git branch -av" to see that your local branch names are distinct from all the "remotes/*" branches. Also, if you have more than one remote repository location, not just origin, then "git remote update" will fetch them all. Pull is basically the combination of fetch and merge into your local branch. Since there's always a chance for merging to fail and require fixup, it would be dangerous for pull to try all your local branches at once.
    - lisper 13y ago
      Ah, that makes sense, thanks. I guess I'm having a hard time getting out of the SVN mindset. I keep forgetting that there may not be any such thing as the remote repo, I can have different branches tracking different remote repos.
    - graue 13y ago
      Offtopic: I didn't know about `git branch -v`. Not something I needed enough to go looking for it, but nifty and good to know! Always learning more Git tricks :)
    - snowwrestler 13y ago
      I always use "fetch" instead of "pull" for this reason--I want to update all my remote branches first, and then consider merging with local branches. It seems that a lot of new git users default to "pull" and I'm not sure why. There must be some really popular tutorial out there that starts with pull.
      - vidarh 13y ago
        "git pull" is the closest equivalent to what people are used to from many other source control systems where there is no concept of a local copy of remote branches.
  - jedbrown 13y ago
    You can use the remote tracking branches if you don't want to make local commits and want them to be automatically updated by fetch. I.e., git checkout origin/interesting-branch Git will warn you that you're in "detached HEAD" state. When you are making local changes or want to return to where you were, you don't want "git fetch" to have side-effects. Note that you can update local branches without switching to them: git push . origin/branch-name:branch-name will fast-forward you local 'branch-name' to match 'origin/branch-name'. It's basically the equivalent of git checkout branch-name git merge --ff-only origin/branch-name # or git pull origin branch-name git checkout the-last-branch-I-was-on Each remote has its own namespace for a good reason.
city41 13y ago
I like this change as well. My early days of git conditioned me to always add the remote and branch when pushing (ie git push origin master) as I did not like the implicit magic behind a bare "git push".
- sillysaurus2 13y ago
  I never bothered to learn the difference. Anyone feel like explaining? git push origin master always seems to work.
  - djm_ 13y ago
    `git push origin master` will only push your master branch to origin. `git push` will push every branch that is tracking a branch on origin; so if you had commits on develop for example, they would also go up provided it was tracking the develop branch on origin. Git v2 changes what `git push` does by default: only the current working branch will get pushed to origin.
    - Anderkent 13y ago
      >`git push` will push every branch that is tracking a branch on origin; or rather, every branch that has the same name as a branch on currently tracked remote. I.e. if you're on branch X that tracks remote A, and both you and the remote have branches called Y and Z, even if Y and Z are marked to track B they will be pushed.

ISL 13y ago

As someone in still in early days of git usage (< 1 yr), I've found it quite confusing that pull doesn't pull every matching branch. I'm now sufficiently familiar with git to understand why, but it's sure been frustrating.

lisper 13y ago
Could you please explain it? Because I don't get it. Git's (current) behavior seems exactly backwards to me. It seems to me that what you want is for push to default to the current branch, but pull to default to all branches. i.e. I want push to mean "push what I'm currently working on" and pull to mean "sync my repo's state to be as close as possible to the remote repo's state".
- CUViper 13y ago
  I think what you want in a pull is really just "git fetch", which will update all remote branches. In case you haven't realized this separation, try "git branch -av" to see that your local branch names are distinct from all the "remotes/*" branches. Also, if you have more than one remote repository location, not just origin, then "git remote update" will fetch them all. Pull is basically the combination of fetch and merge into your local branch. Since there's always a chance for merging to fail and require fixup, it would be dangerous for pull to try all your local branches at once.
  - lisper 13y ago
    Ah, that makes sense, thanks. I guess I'm having a hard time getting out of the SVN mindset. I keep forgetting that there may not be any such thing as the remote repo, I can have different branches tracking different remote repos.
  - graue 13y ago
    Offtopic: I didn't know about `git branch -v`. Not something I needed enough to go looking for it, but nifty and good to know! Always learning more Git tricks :)
  - snowwrestler 13y ago
    I always use "fetch" instead of "pull" for this reason--I want to update all my remote branches first, and then consider merging with local branches. It seems that a lot of new git users default to "pull" and I'm not sure why. There must be some really popular tutorial out there that starts with pull.
    - vidarh 13y ago
      "git pull" is the closest equivalent to what people are used to from many other source control systems where there is no concept of a local copy of remote branches.
- jedbrown 13y ago
  You can use the remote tracking branches if you don't want to make local commits and want them to be automatically updated by fetch. I.e., git checkout origin/interesting-branch Git will warn you that you're in "detached HEAD" state. When you are making local changes or want to return to where you were, you don't want "git fetch" to have side-effects. Note that you can update local branches without switching to them: git push . origin/branch-name:branch-name will fast-forward you local 'branch-name' to match 'origin/branch-name'. It's basically the equivalent of git checkout branch-name git merge --ff-only origin/branch-name # or git pull origin branch-name git checkout the-last-branch-I-was-on Each remote has its own namespace for a good reason.

city41 13y ago

I like this change as well. My early days of git conditioned me to always add the remote and branch when pushing (ie git push origin master) as I did not like the implicit magic behind a bare "git push".

sillysaurus2 13y ago
I never bothered to learn the difference. Anyone feel like explaining? git push origin master always seems to work.
- djm_ 13y ago
  `git push origin master` will only push your master branch to origin. `git push` will push every branch that is tracking a branch on origin; so if you had commits on develop for example, they would also go up provided it was tracking the develop branch on origin. Git v2 changes what `git push` does by default: only the current working branch will get pushed to origin.
  - Anderkent 13y ago
    >`git push` will push every branch that is tracking a branch on origin; or rather, every branch that has the same name as a branch on currently tracked remote. I.e. if you're on branch X that tracks remote A, and both you and the remote have branches called Y and Z, even if Y and Z are marked to track B they will be pushed.