9 ms·

Git 2.0 changes push default to ‘simple’

200 points by shawndumas 13y ago

thearn4 13y ago
Love git, but am also glad to see that changes are being considered to make its behavior more intuitive. Relevant: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
Fizzadar 13y ago
Noticed this message the other day - about time! IMO this should have always been the default Git push behaviour.
CJefferson 13y ago
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.
saidajigumi 13y ago
It's worth following Junio Hamano's Git Blame blog[1] to keep up with changes in git of this ilk. This particular item is old news in that regard, and a very welcome change at that. [1] http://git-blame.blogspot.com/ http://git-blame.blogspot.com/
joeblau 13y ago
Thanks for the breakdown.
Gigablah 13y ago
We were burnt by this before -- someone did a "git push -f" thinking it would force push only their current branch. It ended up pushing everything including their master which was out of date, thus wiping out a whole bunch of newer commits. Luckily it was also easy to restore due to git's distributed nature.
- dilap 13y ago
  Even w/o the distributed stuff, git reflog has your back. Once something has been comitted, you have to try pretty hard to really lose it.
  - Anderkent 13y ago
    That's only if you have ssh access to the server. I don't think there's a way of seeing the reflog of a remote? I.e. if you're using github and the branch only lives there, can you undo an overwrite?
    - dilap 13y ago
      Oh, interesting, I think you're right. That's a bit unfortunate actually!
    - darklajid 13y ago
      I guess I am missing something. There is no 'server'. You should have the same reflog locally, if you pulled before someone messed the repository up?
      - luchs 13y ago
        The 'server' in this case is a remote repository which has some commits you don't have. If you force push to this repository, these commits will be lost for you - only the person who pushed these or someone with access to the server can restore them.
    - eridius 13y ago
      If you have the output from your `git push -f` you can, because it outputs both the old and new ref for each modified branch.
cenhyperion 13y ago
This is a great change. I had to learn to add the branch after a couple of bad experiences with bad git pushes. git push <repo> always seemed like it should just push the current branch.
dmazin 13y ago
I'd still be somewhat weary of doing a targetless force push. For example one may get used to the command and cause damage from a system with an older git.
- joshuacc 13y ago
  I think you meant "wary," not "weary." :-)
  - Zancarius 13y ago
    Maybe dmazin finds the thought alone tiring!
  - dmazin 13y ago
    These homophones have tripped me up tremendously in my English-speaking years, even though I generally great pay great attention to such matters.
- CUViper 13y ago
  When in doubt, "git push -n" (aka "--dry-run") will let you test what would happen.
- toupeira 13y ago
  Use aliases then: pu = -c push.default=simple push -v --progress pua = -c push.default=matching push -v --progress poof = -c push.default=simple push -v --progress --force
moron4hire 13y ago
This is why I really love the Github for Windows client, and recall Torvalds statement that git is not an SCM, but a system to build an SCM.
- saraid216 13y ago
  I'd be interested in seeing the context in which he said that. Googling for the quote didn't get me anything.
  - andrewaylett 13y ago
    That's not a direct quote, but consider that git subcommands are split into 'plumbing' and 'porcelain' and take a look at this chapter of the git book: http://git-scm.com/book/ch9-1.html http://git-scm.com/book/ch9-1.html
  - NateEag 13y ago
    He said approximately this when Git was about 4 days old: http://lwn.net/Articles/131312/ http://lwn.net/Articles/131312/ I don't think it really applies to Git as we know it today, though.
sergiotapia 13y ago
This change of the default makes sense, and I kind of wonder why it wasn't the default in the first place. Kudos to making Git even better and easier for new people to get started.
mikeocool 13y ago
This is amazing. Every person I have introduced to git is constantly confused by the 'rejected' error message returned when a local branch that is not their current working branch is out of sync with the remote, and they just want to push their current working branch.
davesque 13y ago
Hooray! This is the way it always should have been IMHO.
tjdetwiler 13y ago
I'm always verbose with my push commands: git push origin my-feature
- mindcrime 13y ago
  Same here. It's easier to just always be explicit and avoid any possible weirdness. I think it's a personality trait thing, though... some people are ok with a certain level of "magic" in the form of implicit behavior, and some people like things to be very explicit. Put me in the camp of people who generally prefer explicit over implicit. shrug
- graue 13y ago
  I've gotten in that habit as well, but then, I'm a neat freak when it comes to git, always using `git add -p` and filtering out any unrelated changes into different commits. I'm often dismayed how sloppy other programmers are with git :) Commit messages like "Ugh, I really need to commit more often. Did X, Y, Z, and maybe some other stuff." make me cringe. Those people need this change the most!
  - tjdetwiler 13y ago
    I'm the same way. People look at me like I'm a pedant because I tell them to do another revision of their patch to fix whitespace errors or typos in their commit messages. It also annoys me when people create a new commit to fix CR feedback instead of amending their non-public commit. But I agree the '-p' argument is amazing.
Touche 13y ago
I still recommend never doing a git push without specifying the remote and branch.
- wycats 13y ago
  Why?
  - Touche 13y ago
    You don't have to understand the difference between `simple` and `matching`.
blumentopf 13y ago
"The new default in Git 2.x is ‘simple’. It means that when doing a git push without specifying a branch, only your current branch will be pushed to the one git pull would normally get your code from." Hello? Why wasn't it called "current" instead of "simple"? Why are these unintuitively named options so frequent in git?
- Nimi 13y ago
  A friend of mine said he contacted the people in charge and suggested some ways out of the counter-intuitiveness. He said they just didn't get it - if each feature works as specified, what's the problem?
- giovannibajo1 13y ago
  Unfortunately, "current" was already taken with a different meaning. There are subtle differences between the different modes. "current" means: push the current branch into a remote branch with the same name, no matter what. "upstream" means: push the current branch into the upstream branch, that is the remote branch from which you pull the current branch. "simple" means: push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.
  - canadev 13y ago
    does 'upstream' mean push to the branch that this is tracking from? edit: yes. http://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch http://stackoverflow.com/questions/10002239/difference-betwe... "Tracking means that a local branch has its upstream set to a remote branch." edit two: second question. does 'simple' mean the same as 'upstream' as long as the upstream branch (the one you are tracking from) has the same name as your local branch? I believe so but thought I'd double check. I have been using git for 4 years. I like it a lot more than svn. I never rebase. I still don't understand some of the things, like why they call it upstream, 'the branch you are pulling from', and tracking, when to me they all seem to mean the same thing.
deleted 13y ago
[deleted]
yawaramin 13y ago
I like having `push.default=upstream` because it's like `simple`, just a little more powerful. With `upstream`, the branch you push to doesn't _need_ to have the same name as the branch you push from. With `simple`, it _does._
okigan 13y ago
BTW any ETA on GIT 2.0 or even just a roadmap of important features that are coming?

200 points by shawndumas 13y ago

Love git, but am also glad to see that changes are being considered to make its behavior more intuitive. Relevant: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/

Fizzadar 13y ago

Noticed this message the other day - about time! IMO this should have always been the default Git push behaviour.

CJefferson 13y ago

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.

saidajigumi 13y ago

It's worth following Junio Hamano's Git Blame blog[1] to keep up with changes in git of this ilk. This particular item is old news in that regard, and a very welcome change at that. [1] http://git-blame.blogspot.com/ http://git-blame.blogspot.com/

joeblau 13y ago

Thanks for the breakdown.

Gigablah 13y ago

We were burnt by this before -- someone did a "git push -f" thinking it would force push only their current branch. It ended up pushing everything including their master which was out of date, thus wiping out a whole bunch of newer commits. Luckily it was also easy to restore due to git's distributed nature.

dilap 13y ago
Even w/o the distributed stuff, git reflog has your back. Once something has been comitted, you have to try pretty hard to really lose it.
- Anderkent 13y ago
  That's only if you have ssh access to the server. I don't think there's a way of seeing the reflog of a remote? I.e. if you're using github and the branch only lives there, can you undo an overwrite?
  - dilap 13y ago
    Oh, interesting, I think you're right. That's a bit unfortunate actually!
  - darklajid 13y ago
    I guess I am missing something. There is no 'server'. You should have the same reflog locally, if you pulled before someone messed the repository up?
    - luchs 13y ago
      The 'server' in this case is a remote repository which has some commits you don't have. If you force push to this repository, these commits will be lost for you - only the person who pushed these or someone with access to the server can restore them.
  - eridius 13y ago
    If you have the output from your `git push -f` you can, because it outputs both the old and new ref for each modified branch.

cenhyperion 13y ago

This is a great change. I had to learn to add the branch after a couple of bad experiences with bad git pushes. git push <repo> always seemed like it should just push the current branch.

dmazin 13y ago

I'd still be somewhat weary of doing a targetless force push. For example one may get used to the command and cause damage from a system with an older git.

joshuacc 13y ago
I think you meant "wary," not "weary." :-)
- Zancarius 13y ago
  Maybe dmazin finds the thought alone tiring!
- dmazin 13y ago
  These homophones have tripped me up tremendously in my English-speaking years, even though I generally great pay great attention to such matters.
CUViper 13y ago
When in doubt, "git push -n" (aka "--dry-run") will let you test what would happen.
toupeira 13y ago
Use aliases then: pu = -c push.default=simple push -v --progress pua = -c push.default=matching push -v --progress poof = -c push.default=simple push -v --progress --force

moron4hire 13y ago

This is why I really love the Github for Windows client, and recall Torvalds statement that git is not an SCM, but a system to build an SCM.

saraid216 13y ago
I'd be interested in seeing the context in which he said that. Googling for the quote didn't get me anything.
- andrewaylett 13y ago
  That's not a direct quote, but consider that git subcommands are split into 'plumbing' and 'porcelain' and take a look at this chapter of the git book: http://git-scm.com/book/ch9-1.html http://git-scm.com/book/ch9-1.html
- NateEag 13y ago
  He said approximately this when Git was about 4 days old: http://lwn.net/Articles/131312/ http://lwn.net/Articles/131312/ I don't think it really applies to Git as we know it today, though.

sergiotapia 13y ago

This change of the default makes sense, and I kind of wonder why it wasn't the default in the first place. Kudos to making Git even better and easier for new people to get started.

mikeocool 13y ago

This is amazing. Every person I have introduced to git is constantly confused by the 'rejected' error message returned when a local branch that is not their current working branch is out of sync with the remote, and they just want to push their current working branch.

davesque 13y ago

Hooray! This is the way it always should have been IMHO.

tjdetwiler 13y ago

I'm always verbose with my push commands: git push origin my-feature

mindcrime 13y ago
Same here. It's easier to just always be explicit and avoid any possible weirdness. I think it's a personality trait thing, though... some people are ok with a certain level of "magic" in the form of implicit behavior, and some people like things to be very explicit. Put me in the camp of people who generally prefer explicit over implicit. shrug
graue 13y ago
I've gotten in that habit as well, but then, I'm a neat freak when it comes to git, always using `git add -p` and filtering out any unrelated changes into different commits. I'm often dismayed how sloppy other programmers are with git :) Commit messages like "Ugh, I really need to commit more often. Did X, Y, Z, and maybe some other stuff." make me cringe. Those people need this change the most!
- tjdetwiler 13y ago
  I'm the same way. People look at me like I'm a pedant because I tell them to do another revision of their patch to fix whitespace errors or typos in their commit messages. It also annoys me when people create a new commit to fix CR feedback instead of amending their non-public commit. But I agree the '-p' argument is amazing.

Touche 13y ago

I still recommend never doing a git push without specifying the remote and branch.

wycats 13y ago
Why?
- Touche 13y ago
  You don't have to understand the difference between `simple` and `matching`.

blumentopf 13y ago

"The new default in Git 2.x is ‘simple’. It means that when doing a git push without specifying a branch, only your current branch will be pushed to the one git pull would normally get your code from." Hello? Why wasn't it called "current" instead of "simple"? Why are these unintuitively named options so frequent in git?

Nimi 13y ago
A friend of mine said he contacted the people in charge and suggested some ways out of the counter-intuitiveness. He said they just didn't get it - if each feature works as specified, what's the problem?
giovannibajo1 13y ago
Unfortunately, "current" was already taken with a different meaning. There are subtle differences between the different modes. "current" means: push the current branch into a remote branch with the same name, no matter what. "upstream" means: push the current branch into the upstream branch, that is the remote branch from which you pull the current branch. "simple" means: push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.
- canadev 13y ago
  does 'upstream' mean push to the branch that this is tracking from? edit: yes. http://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch http://stackoverflow.com/questions/10002239/difference-betwe... "Tracking means that a local branch has its upstream set to a remote branch." edit two: second question. does 'simple' mean the same as 'upstream' as long as the upstream branch (the one you are tracking from) has the same name as your local branch? I believe so but thought I'd double check. I have been using git for 4 years. I like it a lot more than svn. I never rebase. I still don't understand some of the things, like why they call it upstream, 'the branch you are pulling from', and tracking, when to me they all seem to mean the same thing.

deleted 13y ago

[deleted]

yawaramin 13y ago

I like having `push.default=upstream` because it's like `simple`, just a little more powerful. With `upstream`, the branch you push to doesn't _need_ to have the same name as the branch you push from. With `simple`, it _does._

okigan 13y ago

BTW any ETA on GIT 2.0 or even just a roadmap of important features that are coming?