Git project seeks discussion on "push" change
lwn.net
lwn.net
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.
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.
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.
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.
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.
Also, OSX does contain the basic requirements: install XCode from the app store.
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.
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.
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).
If you call installing a compiler a lot of heavy and opaque lifting...
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.
(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.
Different distros have different amount of compliance with traditional UNIX. Ubuntu is one of those which has ventured the farthest away from it.
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.
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.
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.
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.
This fork is a good one: http://gitx.laullon.com/
Upstream is a more sensible default and I agree with the change.
I do, however, support "getting the defaults right".
What a peculiar thing to be annoyed by. I take it you are pairing?
It's to be expected, people are threatened by anything different, no reason command line habits should be any different.
git config --global push.default upstream
EDIT: actually, the proposed change is to "upstream" and not "current", edited the command to reflect this.
The proposal is to change the default to 'upstream'This proposed default change in git will make things much clearer, in my opinion and I hope they agree to making the change.
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
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.
As noted elsewhere, it's good to see the folks at git are willing to make breaking changes for the greater good.
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.
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.
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.
git config push.default current
How difficult is that?
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.