10 ms·

Git project seeks discussion on "push" change

326 points by taylorbuley 15y ago

tomschlick 15y ago
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 15y ago
  +1 I usually change my settings to do this anyway.
  - deleted 15y ago
    [deleted]
CJefferson 15y ago
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 15y ago
  Given that Git is not so great on the usability front, they will have to be ready to make lots of breaking changes.
  - slowpoke 15y ago
    >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 15y ago
      "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 15y ago
        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.
        aiscott 15y ago
        Could you please expand on what you mean by "Macs do not have the same power as a traditional unix"?
        leif 15y ago
        Installing a large number of useful unix programs is difficult or impossible. This is getting worse (see the recent changes that came with Xcode 4.3). Fink/MacPorts/Homebrew are horrible kludges when compared to what can be done with a full-featured UNIX. What it comes down to is that the most basic thing I can do with the default install of any reasonable UNIX system (./configure, make, make install) is not possible on a Mac without a lot of heavy and opaque lifting.
  - rogerbinns 15y ago
    Unfortunately the defaults are suited to large numbers of collaborators. For example tags are not pushed by default. With a small number of collaborators that is highly annoying - of course you all want to see and use the same tags, and not remember magic flags. With a thousand collaborators you don't want the master repositories littered with tags from all and sundry unless they really meant it - ie you must remember magic flags. I really wish the guis were better. They can look at number of collaborators, project size, merges, branches etc and behave appropriately eg noticing that tags aren't pushed. I did try a bunch (Linux desktop) and they are uniformly ugly and somewhat hostile. The least worst one I found was gitg. My experience on other projects (using Hg) has been that perpetual intermediates that use command line tools only make the most DVCS mistakes while TortoiseHg resulted in the fewest mistakes. Git's command line definitely isn't aimed at perpetual intermediates hence the "usability" complaints.
    - secoif 15y ago
      Try gitx, this has served me well for the past 6 months. Used to use solely command line for years, but I can't go past the visibility and ease of use that gitx provides. I use the history view and add/commit workflow in gitx. Anything more fancy like interactive rebases and merges I drop back to command line. Works a treat. This fork is a good one: http://gitx.laullon.com/ http://gitx.laullon.com/
      - rogerbinns 15y ago
        I did specifically mention that I am using a Linux desktop ...
  - dlsym 15y ago
    Given that when I started to use GIT, coming from an SVN background, and version control all over a sudden started to be fun for me again, I guess git's usability can't be that bad. Upstream is a more sensible default and I agree with the change.
spicyj 15y ago
+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.
mmisu 15y ago
Looks good, this will make push/pull more easy to grasp.
srl 15y ago
+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.
burgerbrain 15y ago
Although git-push's behaviour never bothered me, I feel I must support this since it would set a good precedent.
nikcub 15y ago
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.
spullara 15y ago
Hopefully this is just the beginning of the Git project attacking usability problems with the command line client.
- michaelfeathers 15y ago
  Yes. Otherwise `porcelain' and `plumbing' mean nothing at all.
austintaylor 15y ago
+1 I have this set in my global config. push.default=matching can have unintended consequences when doing push -f.
hammerdr 15y ago
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 15y ago
  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.
wolframarnold 15y ago
+1
julian37 15y ago
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 http://stackoverflow.com/a/948397 EDIT: actually, the proposed change is to "upstream" and not "current", edited the command to reflect this.
- pieter 15y ago
  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'
- jjcm 15y ago
  Right, and likewise if this change is made default you can change it back in your config. I'm in support of this change as most of the arguments against it are, "it's not good for experienced users" - which is true, but the experienced users are more likely to configure git anyway.
- Osiris 15y ago
  That's good to know. I was having this issue myself when having a remote branch with a different name than the local branch. git push was ignoring my tracking configuration which I found bizarre. I learned later that you can specify a separate configuration for git push. This proposed default change in git will make things much clearer, in my opinion and I hope they agree to making the change.
tpsreport 15y ago
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.
viraptor 15y ago
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.
endlessvoid94 15y ago
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".
- davesims 15y ago
  I do this as well, but mainly because the default behavior of 'git push' makes me jittery. I might be more comfortable if this change is made. +1
  - nightpool 15y ago
    You might find it more comfortable if you set your push.default to "nothing", which will stop git from pushing anything if no refspec is given.
- aaronblohowiak 15y ago
  >colleagues often seem annoyed that I do this What a peculiar thing to be annoyed by. I take it you are pairing?
  - endlessvoid94 15y ago
    I think it seems overly pedantic or something. I could also be imagining things.
    - nknight 15y ago
      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.
      - endlessvoid94 15y ago
oscardelben 15y ago
I actually aliased git push to push to the current branch.
- mh- 15y ago
  git config push.default current might be a little cleaner :)
  - oscardelben 15y ago
    Thanks
peterfschaadt 15y ago
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.
a1k0n 15y ago
So, is there anyone actually against this change?
- bostonvaulter2 15y ago
  Not on this hacker news page.
  - cookiecaper 15y ago
    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.
- nknight 15y ago
  There seems to be a small minority on the git mailing list who are split between questioning the workflow of anyone who needs this, and the obligatory and inane "it's documented, it's not a problem!" attitude
- JoshTriplett 15y ago
  Some debate exists over the correct default to switch to ("current" or "upstream"), but nobody seems to argue for today's behavior ("matching").
mikeocool 15y ago
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.
Fluxx 15y ago
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.
manojlds 15y ago
git push origin master How difficult is that?
- brlewis 15y ago
  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 15y ago
    I was sarcastic and was arguing for the change...so many people new to Git miss that and must generally be told about it.
xxiao 15y ago
+
charlieok 15y ago
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 15y ago
  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.

326 points by taylorbuley 15y ago

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 15y ago
+1 I usually change my settings to do this anyway.
- deleted 15y ago
  [deleted]

CJefferson 15y ago

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 15y ago
Given that Git is not so great on the usability front, they will have to be ready to make lots of breaking changes.
- slowpoke 15y ago
  >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 15y ago
    "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 15y ago
      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.
      - aiscott 15y ago
        Could you please expand on what you mean by "Macs do not have the same power as a traditional unix"?
        leif 15y ago
        Installing a large number of useful unix programs is difficult or impossible. This is getting worse (see the recent changes that came with Xcode 4.3). Fink/MacPorts/Homebrew are horrible kludges when compared to what can be done with a full-featured UNIX. What it comes down to is that the most basic thing I can do with the default install of any reasonable UNIX system (./configure, make, make install) is not possible on a Mac without a lot of heavy and opaque lifting.
- rogerbinns 15y ago
  Unfortunately the defaults are suited to large numbers of collaborators. For example tags are not pushed by default. With a small number of collaborators that is highly annoying - of course you all want to see and use the same tags, and not remember magic flags. With a thousand collaborators you don't want the master repositories littered with tags from all and sundry unless they really meant it - ie you must remember magic flags. I really wish the guis were better. They can look at number of collaborators, project size, merges, branches etc and behave appropriately eg noticing that tags aren't pushed. I did try a bunch (Linux desktop) and they are uniformly ugly and somewhat hostile. The least worst one I found was gitg. My experience on other projects (using Hg) has been that perpetual intermediates that use command line tools only make the most DVCS mistakes while TortoiseHg resulted in the fewest mistakes. Git's command line definitely isn't aimed at perpetual intermediates hence the "usability" complaints.
  - secoif 15y ago
    Try gitx, this has served me well for the past 6 months. Used to use solely command line for years, but I can't go past the visibility and ease of use that gitx provides. I use the history view and add/commit workflow in gitx. Anything more fancy like interactive rebases and merges I drop back to command line. Works a treat. This fork is a good one: http://gitx.laullon.com/ http://gitx.laullon.com/
    - rogerbinns 15y ago
      I did specifically mention that I am using a Linux desktop ...
- dlsym 15y ago
  Given that when I started to use GIT, coming from an SVN background, and version control all over a sudden started to be fun for me again, I guess git's usability can't be that bad. Upstream is a more sensible default and I agree with the change.

spicyj 15y ago

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

mmisu 15y ago

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

srl 15y ago

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

burgerbrain 15y ago

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

nikcub 15y ago

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.

spullara 15y ago

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

michaelfeathers 15y ago
Yes. Otherwise `porcelain' and `plumbing' mean nothing at all.

austintaylor 15y ago

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

hammerdr 15y ago

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 15y ago
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.

wolframarnold 15y ago

julian37 15y ago

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 http://stackoverflow.com/a/948397 EDIT: actually, the proposed change is to "upstream" and not "current", edited the command to reflect this.

pieter 15y ago
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'
jjcm 15y ago
Right, and likewise if this change is made default you can change it back in your config. I'm in support of this change as most of the arguments against it are, "it's not good for experienced users" - which is true, but the experienced users are more likely to configure git anyway.
Osiris 15y ago
That's good to know. I was having this issue myself when having a remote branch with a different name than the local branch. git push was ignoring my tracking configuration which I found bizarre. I learned later that you can specify a separate configuration for git push. This proposed default change in git will make things much clearer, in my opinion and I hope they agree to making the change.

tpsreport 15y ago

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.

viraptor 15y ago

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.

endlessvoid94 15y ago

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

davesims 15y ago
I do this as well, but mainly because the default behavior of 'git push' makes me jittery. I might be more comfortable if this change is made. +1
- nightpool 15y ago
  You might find it more comfortable if you set your push.default to "nothing", which will stop git from pushing anything if no refspec is given.
aaronblohowiak 15y ago
>colleagues often seem annoyed that I do this What a peculiar thing to be annoyed by. I take it you are pairing?
- endlessvoid94 15y ago
  I think it seems overly pedantic or something. I could also be imagining things.
  - nknight 15y ago
    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.
    - endlessvoid94 15y ago

oscardelben 15y ago

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

mh- 15y ago
git config push.default current might be a little cleaner :)
- oscardelben 15y ago
  Thanks

peterfschaadt 15y ago

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.

a1k0n 15y ago

So, is there anyone actually against this change?

bostonvaulter2 15y ago
Not on this hacker news page.
- cookiecaper 15y ago
  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.
nknight 15y ago
There seems to be a small minority on the git mailing list who are split between questioning the workflow of anyone who needs this, and the obligatory and inane "it's documented, it's not a problem!" attitude
JoshTriplett 15y ago
Some debate exists over the correct default to switch to ("current" or "upstream"), but nobody seems to argue for today's behavior ("matching").

mikeocool 15y ago

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.

Fluxx 15y ago

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.

manojlds 15y ago

git push origin master How difficult is that?

brlewis 15y ago
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 15y ago
  I was sarcastic and was arguing for the change...so many people new to Git miss that and must generally be told about it.

xxiao 15y ago

charlieok 15y ago

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 15y ago
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.