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.
>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.
"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.
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.)
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.
This is true of Ubuntu as well. You have to run "apt-get install build-essential" in order to get a compiler. This might be easier than on a Mac, but regardless it's disingenuous to say that Mac is not a Unix because it doesn't come with a compiler.
(I use Ubuntu regularly and have never owned an Apple product.)
> That said, really? It doesn't come with gcc anymore? I find this offensive.
Lots of Linux distros don't install one by default, and this has always been the case. For that matter, for a long time, Solaris (unquestionably a UNIX) didn't come with a compiler.
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.
> 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.
If you call installing a compiler a lot of heavy and opaque lifting...
Macs aren't configured from the start as a development system. And if you start from a UNIX or Linux distro that isn't either, you'll encounter into the same issues (or worse) with trying to run "./configure && make && make install"
I contend that those are not traditional unices either. This is a very personal definition, but I think a useful one for most that are interested in the distinction.
> I contend that those are not traditional unices either. This is a very personal definition
Ah, okay. I contend that Dell machines aren't computers because they rarely have green LEDs anymore, and surely all computers have green LEDs!
It is interesting to note that by your definition, Solaris, surely a highly traditional UNIX, was, for a long time, not a UNIX (it didn't ship with development tools).
Based on what you've posted,you'd have a hard time calling anything that. And I'm including AIX, SunOS/Solaris, HP-UX, etc.
What you want is a UNIX or UNIX-like OS that comes pre-installed with GNU-based development tools. This is a choice in configuration, not a definition of what UNIX is or isn't.
Sorry to be pedantic, but if you're using a free operating system, which I assume almost all of us here are, you are almost definitely not using a "UNIX"(tm). A high success rate with ./configure; make; make install; does not mean you have a "full-featured UNIX"; more than likely it means you have Linux, which diverges from traditional big iron Unix OSes in some fairly significant ways.
I never use fink, macports or homebrew to install on my Mac. It's pretty much download source, take a look at the README/INSTALL and go from there.
The main issue is that Mac is probably not the usual target system for these builds (in comparison to a mainstream Linux distro). And as such differences in the version of the compiler, the set of libraries, installed dev tools, etc. may lead to build issues. You might have to download a few more things or know to add or override compiler or link flags.
Even with the latest Ubuntu or Fedora distro, you still run into having to know that you might need to install dev files to get a build from source to work (recent example for me is pcre libs for nginx).
How do you really go about this? Where did you get your compiler? Where did you get autotools? My point is that OSX doesn't contain the basic requirements for bootstrapping by default anymore.
> How do you really go about this? Where did you get your compiler? Where did you get auto tools?
You install the 'XCode Command Line Tools' as provided by Apple, or one of a number of third-party packages.
Similarly, on many unices, you will need to install a compiler (and particularly autotools); they are not always part of a default install, which may be just as well.
I love homebrew, personally. In fact I wish it was available for linux. This is because we have a pretty restricted linux environment at work, and getting the admins to install anything is very difficult and lengthy.
I've gotten by with installing gentoo-prefix in a sub directory, but that is quite wasteful of space. A homebrew setup would be much nicer.
> Actually it's one of the best things to do in software
Depends on your target audience - easy to learn doesn't necessarily mean usable. It's absolutely a good target for dealing with most people, but if your target is expert users it's not necessarily a good idea. Despite noises about linux for the average user, in reality it's a system designed by expert users for expert users - and for those users it is highly usable.
Autocad is a highly usable system to its target audience, but stick a beginner in front of it, and they'll not have a clue to do.
>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.
Yes. You have to - gasp - actually understand what the fuck you are doing to get things working correctly. I don't see the problem. As others have pointed out, git is not meant for the beginner, it's not meant for an average user, it's for people who want an extremely powerful VCS. If you start catering to people who are not from the latter group, you are missing both the point and the purpose of git.
>Personally, I don't think either UNIX or GIT made the trade off between usability and power, usability was simply ignored.
False. What you are talking about isn't usability. It's accessibility. And I actually agree with you that git is very inaccessible for someone who's never worked with a VCS before (that's how I started with git, thrown into cold water). The same goes for UNIX, to a degree. Now, usability and accessibility aren't necessarily orthogonal concepts. They aren't parallel, either, though. When you try to improve the accessibility of a program, you will arrive at a point where you will have to make tradeoffs with the usability of the program. And what I am saying is that when you reach that point, stop. Accessibility isn't worth sacrificing usability over.
>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
Argumentum ad populum. Just because those companies do it doesn't imply that it's good. And in fact, they just prove my point: what they are doing is harming general purpose computing in the long run, and for everyone. Microsoft and Apple are aiming to turn computers into one-to-many consumption devices. Facebook and Google are privacy nightmares and impact the open web negatively with their monopolies.
>Imagine the UI for aircraft was so horrible that to get from NY to LA you needed an aerospace degree.
Your ridiculous hyperbole isn't making your point more valid. No, you shouldn't need to have an aerospace degree to fly from NY to LA. But you should have a grasp of how to get from NY to LA, not demand "I want to get to LA". The same goes for search engines. No, I don't expect people to understand the math behind page rank. But I expect them to be able to use a search machine. If that involves learning to make better search queries, then so be it.
Finally, if you want to use a powerful VCS like git, then I'm afraid you have to learn how git works. And not demand that it made be more accessible for people unwilling to learn how it's used. For people who want a simple (D)VCS with a much better accessibility (and consequently a lot less power), there's always bzr.
>PS. Mac has all the power of UNIX but with out a retarded interface meaning no tradeoff was actually necessary.
False. As others have pointed out, OS X is a horrible, crippled excuse for a UNIX, albeit with a shiny UI on top (whose usability is debatable and in my opinion horrible). I don't even know why developers put up with it. If you aren't specifically developing for OS X/iOS (same goes for Windows), there's literally no reason to not use GNU/Linux or one of the BSDs.
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.
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.
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.
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".
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.
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.
+1. i do the same. Given i end up working on a different variety of unices. it's less of a surprise when i get command not found than dropping to vi and not finding the familiar commands.
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.
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.
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.
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.
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.
+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.
+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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.