6 ms·

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.
        leif 15y ago
        Whoever downvoted me, please say why. If I'm wrong, I'm very curious to know why (because I work on a macbook and I'd like my life to be easier).
        lnguyen 15y ago
        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).
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.

>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.
      - leif 15y ago
        Whoever downvoted me, please say why. If I'm wrong, I'm very curious to know why (because I work on a macbook and I'd like my life to be easier).
        lnguyen 15y ago
        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).

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.