
Git 2.0 changes push default to ‘simple’ - shawndumas
http://blog.nicoschuele.com/?p=217
======
blumentopf
"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?

~~~
jlgreco
_(In addition to "current" already being taken...)_

If it were called your "intuitive" name ( _" current"_, meaning _" this is the
current default"_), then it would, extremely unintuitively, require renaming
if it ever stopped being the default. You would be sacrificing future
coherence for the sake of some very mild "intuitive sense" during the present.

Complaining about git's standard porcelain is a popular sport, but so often
the people who play it don't give proposals that make more sense than the
status quo.

~~~
dap
> Complaining about git's standard porcelain is a popular sport, but so often
> the people who play it don't give proposals that make more sense than the
> status quo.

This is a classic case where the git behavior seems not just unintuitive, but
far more complicated than necessary. Why do multiple modes even exist? If I
were starting, I'd consider saying that "git push" with no other arguments is
the same as what "current" (or even "simple") do now, but you could specify
any number of branches or branch wildcards with an argument (including "*").
That is, like ls(1).

I could definitely be missing some important class of use cases, but this
feels so much simpler than even having modes, let alone modes that have
complex semantics, and still lets the default (very common) case work and
supports pushing a manually-specified set of branches, too.

~~~
jlgreco

           push.default
               Defines the action git push should take if no refspec is given on
               the command line, no refspec is configured in the remote, and no
               refspec is implied by any of the options given on the command line.
               Possible values are:
    
               ·    nothing - do not push anything.
    
               ·    matching - push all matching branches. All branches having the
                   same name in both ends are considered to be matching. This is
                   the default.
    
               ·    upstream - push the current branch to its upstream branch.
    
               ·    tracking - deprecated synonym for upstream.
    
               ·    current - push the current branch to a branch of the same
                   name.
    

_(yes, my version of git on this machine is out of date)_

Emphasis on: _" if no refspec is given on the command line, no refspec is
configured in the remote, and no refspec is implied by any of the options
given on the command line"_

These modes define what happens if you give _no_ options to git-push. If these
modes didn't exist, then you would instead be complaining that a plain old
`git push` with no arguments didn't _" do what you clearly meant"_ (where _"
clearly meant"_ changes from user to user... particularly since different
users have different workflows, some centralized, some not.)

If git-push worked as you suggest, then you would just be complaining that you
had to escape your asterisks characters to prevent the shell from expanding
them _(remember that glob expansion is not something that ls provides...)_ ,
instead of using a far simpler _\--all_.

You want a _legitimate_ complaint about git-push? Try: "git-add allows either
_\--all_ or _-A_ , but git-push only allows _\--all_."

------
Gigablah
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.

~~~
ramblerman
Why would you use -f unless you are doing something really peculiar.

If you are behind git warns you and says you need to pull first. By stating -f
you are saying nope, throw that crap away and just take my version.

That's pretty extreme and warrants care. I have a hard time feeling sorry for
people who are burned by this.

~~~
MaxGabriel
It's not unreasonable to force push a branch. Anytime you've rebased but
already pushed you would need to do so. I've worked on an open source project
where every commit was required to pass all the tests, so if you submitted a
PR that had any commit fail CI, you would have to alter history and force
push.

I also just like pushing to a branch on Github, even if I might rebase later.
Circle CI is triggered through Github, so it's nice to have that triggered for
me. Our staging servers (production data, your branch's code) are deployed
from Github branches as well. Plus looking at diffs on Github is really
helpful for me to spot errors—I'm not sure if it's the context switch away
from my text editor, Github's diff UI, or what, but it works for me.

~~~
ori_b
> _Anytime you 've rebased but already pushed you would need to do so._

And that's also unreasonable. Pushed history should be treated as immutable.
If you broke the build, push a revert commit, fix the issue, and resubmit. And
then fix your tooling to recognize rollbacks.

~~~
Hovertruck
I tend to treat the history of the master branch as immutable. Working with a
remote branch that needs to stay up-to-date with master has, in my experience,
required rebasing and force-pushing the branch.

------
CJefferson
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
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
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
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.

~~~
snowwrestler
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
"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.

------
saidajigumi
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/)

------
mikeocool
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.

------
thearn4
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/)

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

~~~
wycats
Why?

~~~
Touche
You don't have to understand the difference between `simple` and `matching`.

------
dmazin
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
I think you meant "wary," not "weary." :-)

~~~
Zancarius
Maybe dmazin finds the thought alone tiring!

------
tjdetwiler
I'm always verbose with my push commands:

    
    
      git push origin my-feature

~~~
graue
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
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.

------
yawaramin
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._

------
cenhyperion
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.

------
sergiotapia
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.

------
moron4hire
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
I'd be interested in seeing the context in which he said that. Googling for
the quote didn't get me anything.

~~~
andrewaylett
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)

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

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

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

------
joeblau
Thanks for the breakdown.

