
Git project seeks discussion on "push" change - taylorbuley
http://lwn.net/Articles/487131/
======
CJefferson
I certainly wish that 'git push' was symmetric with 'git pull'. Several times
I have had people ask me why 'git push' is complaining about unmerged
branches, when 'git pull' says there is nothing to do.

It gives me hope for the future of git that unlike many projects, they are
willing to make these kinds of breaking changes to improve usability.

~~~
manojlds
Given that Git is not so great on the usability front, they will have to be
ready to make lots of breaking changes.

~~~
slowpoke
_> Given that Git is not so great on the usability front_

But git is _great_ on the usability front - if you have understood to
responsibly wield its great power.

I'm certainly not an expert git user (I would describe myself as
intermediate), but I think that not a small amount of the gotchas and pitfalls
in git are either directly or indirectly caused by said great power. You can
do a lot of very dumb things with git, but as Kernighan and Pike put it in
_The UNIX Programming Environment_ : "UNIX does not prevent users from doing
stupid things, as that would also prevent them from doing clever things". The
same goes for git.

Please don't misunderstand me, though. I'm all in for changes that improve
usability, but _only_ if these changes do not impact git's power in a negative
way, or make it harder to draw on that power. Otherwise I will be
fundamentally opposed to such changes. Dumbing things down for everyone to
cater to a lower common denominator is one of the worst things you can do to
software in general.

~~~
fleitz
"But git is great on the usability front - if you have understood to
responsibly wield its great power."

What that sentence actually means is that the usability sucks and that if you
spend enough time reading man pages you might actually get the software to do
what you wanted it to do. Which in short means the usability sucks, if you
want to say the usability was sacrificed in order to provide great power then
say so, UNIX being powerful does not improve it's usability.

Personally, I don't think either UNIX or GIT made the trade off between
usability and power, usability was simply ignored.

"Dumbing things down for everyone to cater to a lower common denominator is
one of the worst things you can do to software in general." Actually it's one
of the best things to do in software, you'll want to look at companies like
Apple, Google, Facebook, Microsoft who all dumb things down so that the
average person can do things like 'find what they're looking for' with out
having to understand the math behind PageRank. Imagine the UI for aircraft was
so horrible that to get from NY to LA you needed an aerospace degree.

PS. Mac has all the power of UNIX but with out a retarded interface meaning no
tradeoff was actually necessary.

~~~
leif
Macs do not have the same power as a traditional unix. They are a lot nicer to
work on once you get them set up properly though.

~~~
Aqueous
Macs are a traditional UNIX with a 'non-traditional' windowing system on top.

~~~
leif
Wrong. They are a stripped, gutted, non-traditional UNIX with a really nice
windowing system on top.

~~~
Aqueous
Just so I know: in what way is it gutted? Mac OS X fully meets the Single UNIX
specification and thus is one of the few 'registered' Unices.

~~~
djacobs
The mach kernel is often described as 'anemic'. (Incidentally, a couple of
friends who work on the kernel don't have good things to say about its
codebase.)

~~~
lobster_johnson
Mach is not OS X's kernel, XNU (<http://en.wikipedia.org/wiki/Xnu>) is. It
contains a modified version of Mach 3.0, but it's not the same kernel. But
regardless, the kernel is not particularly important when discussing the
operating system's unixness.

~~~
djacobs
I don't think that was the question.

------
endlessvoid94
I always, always, always specify the remote and branch name whenever I push.
It's saved me many headaches; colleagues often seem annoyed that I do this,
but for some reason making it a habit has been invaluable.

I do, however, support "getting the defaults right".

~~~
aaronblohowiak
>colleagues often seem annoyed that I do this

What a peculiar thing to be annoyed by. I take it you are pairing?

~~~
endlessvoid94
I think it seems overly pedantic or something. I could also be imagining
things.

~~~
nknight
You're not. It seems to drive some people nuts that I obsessively type "vim"
instead of "vi" even though most of the time the default differences won't be
an issue.

It's to be expected, people are threatened by anything different, no reason
command line habits should be any different.

~~~
DrStalker
I do the same thing... the time spent typing the extra characters is trivial,
my annoyance when my editor doesn't behave exactly as I expect because I was
on a differently configured server is huge by comparison.

------
julian37
As pointed out by somebody in the comments, you can get this new behavior
today by running

    
    
      git config --global push.default upstream
    

See also <http://stackoverflow.com/a/948397>

EDIT: actually, the proposed change is to "upstream" and not "current", edited
the command to reflect this.

~~~
pieter
You don't have to look in the comments, it says so right in the article:

    
    
         The proposal is to change the default to 'upstream'

------
tomschlick
I'm in favor of this proposal. Having "git push" just push the current branch
and something like "git push --all" would push all current local branches to
their respective remotes branches.

~~~
speg
+1 I usually change my settings to do this anyway.

------
hammerdr
I've trained several people to used Git across a number of projects and
technologies.

This is, by far, the biggest head scratcher of git. People can get incredibly
caught up in the fact that this is the default behavior. +1

~~~
djacobs
In my opinion, the bigger head-scratcher with regards to git is why it's so
hard to delete the local caches of remote tracking branches. Or why the
submodule system is so inferior to the rest of git.

------
spullara
Hopefully this is just the beginning of the Git project attacking usability
problems with the command line client.

~~~
michaelfeathers
Yes. Otherwise `porcelain' and `plumbing' mean nothing at all.

------
mikeocool
This seems like a great change.

The 'Rejected' error message that shows up when you push from one branch and
another branch hasn't been merged with the remote recently successfully
confuses every single person I've ever introduced to git.

------
spicyj
+1 from me. Even though I use git a lot and would consider familiar with the
commands, I rarely do a plain "git push" because I'm never sure exactly which
branches it will push to where.

------
srl
+1 from me. I don't actually benefit from the new behavour much more than the
current behaviour (my personal usage pattern results in me wanting to always
push all branches), but it logically makes much more sense.

As noted elsewhere, it's good to see the folks at git are willing to make
breaking changes for the greater good.

------
a1k0n
So, is there anyone actually against this change?

~~~
bostonvaulter2
Not on this hacker news page.

~~~
cookiecaper
Nor on LWN apparently. This has got to be the least controversial setting
change in a good long time. It seems everyone just worked around this crappy
default by establishing usage habits like always defining branch and remote.

I know I've set my git push to current a couple of times but most of the time
I just end up deleting the branch if something that wasn't intended for public
consumption gets pushed up.

------
viraptor
Used this for a long time already. Even if I know what the action will do in
general, it's quite hard to find out what will happen when you run it at this
exact moment. -f is also a dangerous option then.

I really don't want to try to remember if I wanted to hold back some change
every time I push something. Current branch looks like a much more reasonable
default.

------
tpsreport
What a sensible change. Kudos to the git team. Most other teams would be wary
of a non-backwards compatible change on such a critical path for a widely used
tool.

------
burgerbrain
Although git-push's behaviour never bothered me, I feel I must support this
since it would set a good precedent.

------
nikcub
when I first started using git this is what I thought the behavior was. it
took a little while to work out what it was actually doing.

------
charlieok
I always run "git remote update" rather than "git pull". That fetches any
updates from all remotes, without any changes to the working tree. It's great
if the first thing you want to know is, "are there any new updates?"

If the answer is no, that's that.

If the answer is yes, you can immediately follow up with something like "git
rebase origin master". Or not. Separate decision.

So, git's push/pull metaphor never felt like a great fit to me, since it lacks
this level of control.

~~~
sateesh
Instead of 'git pull' I use a combination of 'git fetch' and 'git merge'. 'git
fetch origin' followed by 'git merge origin/<branch_name>' (if there are any
interesting changes) keeps my current branch up to date with the changes I
need. Keeping the 'merge' a separate step helps me to decide when I want to be
in sync. the remote modifications.

------
mmisu
Looks good, this will make push/pull more easy to grasp.

------
Fluxx
I've was bitten by this many times until I changed my global push setting to
upstream, and I consider myself an advanced git user. One time I did a vanilla
git push -f, wanting to add my amended commit to the remote branch. I
accidentally force pushed our master, staging and production branches to
whatever my local versions of them were, sometimes weeks out of date.

------
austintaylor
+1 I have this set in my global config. push.default=matching can have
unintended consequences when doing push -f.

------
peterfschaadt
Enabling this behavior by default makes a lot of sense. It's likely that most
Git beginners are unaware of the upstream argument and its behavior. Looking
forward to further Git usability improvements.

------
oscardelben
I actually aliased git push to push to the current branch.

~~~
mh-

      git config push.default current
    

might be a little cleaner :)

~~~
oscardelben
Thanks

------
xxiao
+

------
wolframarnold
+1

------
manojlds
git push origin master

How difficult is that?

~~~
brlewis
An answer to the "How difficult is that?" question can only come from counting
how many newbies do/don't stumble over the issue this change seeks to address.

If you weren't looking for an answer, and were just asking a rhetorical
question, you'll have to tell us which side you're arguing for. The ease with
which you can avoid relying on the default argues not only for the proposed
change being unnecessary, but also for the proposed change being harmless.

~~~
manojlds
I was sarcastic and was arguing for the change...so many people new to Git
miss that and must generally be told about it.

