11 ms·

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

by danjac 4y ago

gpspake 4y ago
It's never too late. I think gitkraken fixed this problem
petepete 4y ago
Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.
- hardware2win 4y ago
  I'd say that ppl got used to it and it is good enough + industry standard, so it is hard to migrate to something else Especially if you'd have to lose github, thats the real force If gh migrated to something else, then a lot of ppl would follow
  - elsjaako 4y ago
    These days when I have to use svn somewhere I use git as a client, because it works better for me. If you prefer you can use mercurial as a git client in the same way. Most of my git use stays local on my PC, uploading it to github or gitlab or whatever is a secondary concern for me.
- kasey_junk 4y ago
  It dominated the world because GitHub was better than BitBucket and had more generous free levels. If only that wasn’t the case we’d all be using a sensible source control system now instead of one where people repeatedly say things like “if you just learn the underlying model…”
  - samwillis 4y ago
    > GitHub was better than BitBucket and had more generous free levels GitHub for many years only had free public repos, not privet, BitBuckets USP was that you could have privet repositories for free. GitHub "won" because of the social aspect around it and the tooling for open source projects - it never had more generous free levels.
    - kasey_junk 4y ago
      BitBucket limited the number of repos you could have while GitHub allowed you to have as many as you wanted so long as they were public. Which had the (intended?) effect of making it more useful socially.
  - carapace 4y ago
    It's not even an anecdote but, uh, I prefered hg to git until the day I tried to use it on a system with the wrong Python installed... (I like Python! But it's a scripting language, not a systems language. Also the "deployment story" is bananas.)
- elsjaako 4y ago
  I for one like how git works. Some of the command names are weird, but I know more sane names are being introduced (e.g. git restore, git switch). Yes, you need to follow a tutorial to use it effectively. Designing for beginning users is often detrementantal to advanced users, and I object to that being called "user friendly". I'm not very vocal about git usually because I'm not an expert I have no big complaints, and I'm not that interested in arguing about it. I think there's a lot of us that are perfectly happy with git; we just make less noise.
- rkangel 4y ago
  I'd argue the opposite - that the model was so good and so much better than anything else that it was adopted despite the UI/UX flaws. Things can be good, have a flaw and still be considered good. That doesn't mean that we pretend the flaw doesn't exist.
  - GuB-42 4y ago
    Mercurial is built on what is almost the same model and has what I think is a better UI/UX. Some people say that git is technically superior but you really need to be an advanced user for it to matter, or work on a really large project. At work, we switched from SVN to Mercurial, and from Mercurial to Git. Most people were happy to switch away from SVN, but few enjoyed the change from Mercurial to Git. Personally, it took me much longer to get used to Git than with Mercurial, even though Mercurial was my first DVCS. I now have a slight preference for git, but I am happy with either (just don't bring back SVN!). Why Git came to dominate and not Mercurial? I am not sure, but I don't think technical reasons explain everything. Its association with Linux probably helped a lot.
    - rkangel 4y ago
      I was also a Mercurial fan who had to reluctantly accept the rise of Git. Git was always a bit quicker, but Mercurial was much more predictable until you really understood the ins and outs of Git. > Why Git came to dominate and not Mercurial? The answer is actually really simple and non-technical: Github. We take these feature rich online code hosting platforms for granted now, but Github was really the leading edge of the wave. It made it easy for people to work together on writing software so it had great takeup and started a Git snowball effect.
    - frutiger 4y ago
      > Why Git came to dominate and not Mercurial? I was an early proponent of Mercurial over git. While they are similar, a few “minor” things made a big difference: Mercurial distinguished between branches and heads, whereas git did not. This added extra complexity. Git embraced checksums as identifiers while Mercurial provided local revision numbers, this obscured the mental model. Git is faster to pronounce than either “Mercurial” (which has a tricky vowel in there) or “hg”.
- toshk 4y ago
  They are bad. Some concepts like rebase etc. I still don't understand. In software we often go for further complexity instead of less. I think because most of us who are the lead developers are often the most intelligent. And we often enjoy these complicated abstract models and they come easy to us. However in satisfying our own intellectual vanity we often don't see how many we leave behind. Which is good for our hourly rates, but less good for creating affordable and simple software. Anyway one of the main practical advantages git had was decentralized repos meaning you were not dependent on an external server which meant git was often much faster if working with in daily tasks compared to centralized versioning systems
  - BossingAround 4y ago
    I'm sorry if this sounds arrogant, but if you don't understand basic Git concepts like rebase, I don't think you're in a position to comment on the architecture of Git
    - toshk 4y ago
      Thats kinda the point :). I've read this many times, but schopenhauer in german is more readable: https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge https://stackoverflow.com/questions/804115/when-do-you-use-g...
- lawn 4y ago
  > It dominated the world despite the UX flaws, which suggests they really aren't that bad. No it doesn't. It suggests the other features are so damn good that it overcame the horrible UX.
- ReptileMan 4y ago
  So was mercurial ... but it much more user friendly.
- pjmlp 4y ago
  It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I bet git produced by a no name Linus, in isolation not required by any major project, would have hardly been taken any major uptake.
  - Jedd 4y ago
    > It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I think parent's point is that that demographic is positively tiny, and there were plenty of other serviceable offerings around at the time. The claim stands - git won despite its UX flaws, which does suggest the alternatives, while serviceable, weren't sufficiently fit for purpose.
    - pjmlp 4y ago
      The alternatives weren't required for collaboration in Linux development.
      - Jedd 4y ago
        Yes, but again, the number of people collaborating on Linux kernel development is truly tiny. I think perhaps you're over-estimating the network effect for VCS's -- having multiple version control binaries on your machine is low cost, and aliases can, up to a point, give you a consistent interface to them all. The highly sophisticated demographic of kernel developers would not have been at the pub insisting that their friends drop svn and use git (exclusively!), anymore than they would have been trying to get any other projects they worked on to adopt bitkeeper previously. The fact that bitkeeper was required for 'collaboration in Linux development' for so long supports this position.
        pjmlp 4y ago
        Bitkeep wasn't free beer and its adoption was widely controversial, until Git was born given their change of heart.
- koonsolo 4y ago
  I've worked with CVS, Subversion, Bazaar, Visual SourceSave, Team Foundation Version Control, Mercurial and Git. The worst systems are the Microsoft ones, but the one with the most complex interface is definitely Git. I would argue it won because of github. I'm using Git because of that, but still prefer Mercurial in every way.
  - memorable 4y ago
    I agree with this. Mercurial is cool, but if you need to convert your Mercurial project to Git to push to GitHub, then it's a fucking pain.
    - wrycoder 4y ago
      There is Sourcehut, which supports Hg.
hardware2win 4y ago
Git and regex
kcl 4y ago
Git's UI/UX is one of the worst engineering sins to be committed in the last two decades, and this website shows why. Literally nothing about git is intuitive and the "underlying model" is entirely ad-hoc. Instead of celebrating how Linus built git in only a few days he should be castigated for knowingly setting up ill-conceived software to go viral.
- flohofwoe 4y ago
  > for knowingly setting up ill-conceived software to go viral I doubt that was the intention. Linux just needed a versioning system tailored to its needs, and that's exactly what Git is. Can't blame its creators that other people used it for scenarios it wasn't built for.
  - kcl 4y ago
    Right, you are the cop-out I am complaining about. Linus is the premier figurehead of the premier open-source project. When a build tool he made for that project goes viral it isn't an accident. If it was anybody else's pet versioning control system would we even be talking about it?
    - salamander014 4y ago
      If it went viral, yes. I agree most of the time I feel like the world is run by evil folks twiddling their fingers in secret. This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software. Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it. It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work. It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude. Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.
ReptileMan 4y ago
We had Mercurial but it died, not with a bang, but with a whisper ...
- Beltalowda 4y ago
  Mercurial is still actively developed, and isn't really "dead", although it did lose a lot of popularity and "mindshare". Projects like Firefox and nginx use it, although others like Vim and Python switched to GitHub. I don't know if Facebook is still using Mercurial internally, but for their public stuff they use GitHub. I think that if GitHub had supported Mercurial like BitBucket or Google Code it would still be a lot more popular, but ah well...
throwaway09223 4y ago
Is it, though? I'm not so sure. Git has enjoyed overwhelming success, which would seem to empirically indicate that it's done something right in terms of design Perhaps the obviously wrong UX/UI isn't wrong? Perhaps UX/UI people aren't good at designing interfaces for experts?
- xigoi 4y ago
  Git has been successful despite the UI, not because of it.
  - throwaway09223 4y ago
    Can you substantiate your opinion? It's open source, so why hasn't an alternate interface taken over?
    - lolinder 4y ago
      Because standardization matters and the first thing to become the standard is extremely difficult to unseat.
      - throwaway09223 4y ago
        But some of types of things have in fact changed, sometimes for seemingly trivial reasons. For example, the master/main branch shift. Everything broke when that change was made, but it happened and it wasn't a big deal. I'm not seeing the difficulty here. It seems that a more reasonable interpretation is that git has the type of interface that is hard to learn, but intuitive once learned.
        xigoi 4y ago
        The master/main shift was fueled by political correctness. If “master” wasn't a synonym of a word associated with slavery, it would've never happened.
  - 4y ago
BossingAround 4y ago
To me, Git is designed in a very nice and understandable way with a terrible terminology. I might be an exception though.
huachimingo 4y ago
Basically all of the UNIX world.
elcapitan 4y ago
Honestly, when I think of software that I suffered using recently, then UX/UI people are usually the reason, not the solution for that suffering.
vaylian 4y ago
Please correct me if I'm wrong, but Linus probably didn't plan for git to be adopted by other people than just kernel developers. Because that was what git was created for originally.
agumonkey 4y ago
What I don't get is that the UX problem is not hard. I still like the underlying commit tree model a lot.. it's just some commands that are not clear enough (reset has 5 meanings and can backfire quickly). Maybe it's just retrocompatibility inertia.
- seadan83 4y ago
  I recommend you create aliases. I've got a 'git-squash' 'git-back' and 'git-update' aliases created, I almost forget they are not part of core git. Combined with scm-breeze that allows files and branches to be referenced with numbers... it's really fast and powerful
duped 4y ago
More a reminder that UX/UI is a lot less important than speed and functionality for professional work.

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

by danjac 4y ago

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

gpspake 4y ago

It's never too late. I think gitkraken fixed this problem

petepete 4y ago

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

hardware2win 4y ago
I'd say that ppl got used to it and it is good enough + industry standard, so it is hard to migrate to something else Especially if you'd have to lose github, thats the real force If gh migrated to something else, then a lot of ppl would follow
- elsjaako 4y ago
  These days when I have to use svn somewhere I use git as a client, because it works better for me. If you prefer you can use mercurial as a git client in the same way. Most of my git use stays local on my PC, uploading it to github or gitlab or whatever is a secondary concern for me.
kasey_junk 4y ago
It dominated the world because GitHub was better than BitBucket and had more generous free levels. If only that wasn’t the case we’d all be using a sensible source control system now instead of one where people repeatedly say things like “if you just learn the underlying model…”
- samwillis 4y ago
  > GitHub was better than BitBucket and had more generous free levels GitHub for many years only had free public repos, not privet, BitBuckets USP was that you could have privet repositories for free. GitHub "won" because of the social aspect around it and the tooling for open source projects - it never had more generous free levels.
  - kasey_junk 4y ago
    BitBucket limited the number of repos you could have while GitHub allowed you to have as many as you wanted so long as they were public. Which had the (intended?) effect of making it more useful socially.
- carapace 4y ago
  It's not even an anecdote but, uh, I prefered hg to git until the day I tried to use it on a system with the wrong Python installed... (I like Python! But it's a scripting language, not a systems language. Also the "deployment story" is bananas.)
elsjaako 4y ago
I for one like how git works. Some of the command names are weird, but I know more sane names are being introduced (e.g. git restore, git switch). Yes, you need to follow a tutorial to use it effectively. Designing for beginning users is often detrementantal to advanced users, and I object to that being called "user friendly". I'm not very vocal about git usually because I'm not an expert I have no big complaints, and I'm not that interested in arguing about it. I think there's a lot of us that are perfectly happy with git; we just make less noise.
rkangel 4y ago
I'd argue the opposite - that the model was so good and so much better than anything else that it was adopted despite the UI/UX flaws. Things can be good, have a flaw and still be considered good. That doesn't mean that we pretend the flaw doesn't exist.
- GuB-42 4y ago
  Mercurial is built on what is almost the same model and has what I think is a better UI/UX. Some people say that git is technically superior but you really need to be an advanced user for it to matter, or work on a really large project. At work, we switched from SVN to Mercurial, and from Mercurial to Git. Most people were happy to switch away from SVN, but few enjoyed the change from Mercurial to Git. Personally, it took me much longer to get used to Git than with Mercurial, even though Mercurial was my first DVCS. I now have a slight preference for git, but I am happy with either (just don't bring back SVN!). Why Git came to dominate and not Mercurial? I am not sure, but I don't think technical reasons explain everything. Its association with Linux probably helped a lot.
  - rkangel 4y ago
    I was also a Mercurial fan who had to reluctantly accept the rise of Git. Git was always a bit quicker, but Mercurial was much more predictable until you really understood the ins and outs of Git. > Why Git came to dominate and not Mercurial? The answer is actually really simple and non-technical: Github. We take these feature rich online code hosting platforms for granted now, but Github was really the leading edge of the wave. It made it easy for people to work together on writing software so it had great takeup and started a Git snowball effect.
  - frutiger 4y ago
    > Why Git came to dominate and not Mercurial? I was an early proponent of Mercurial over git. While they are similar, a few “minor” things made a big difference: Mercurial distinguished between branches and heads, whereas git did not. This added extra complexity. Git embraced checksums as identifiers while Mercurial provided local revision numbers, this obscured the mental model. Git is faster to pronounce than either “Mercurial” (which has a tricky vowel in there) or “hg”.
toshk 4y ago
They are bad. Some concepts like rebase etc. I still don't understand. In software we often go for further complexity instead of less. I think because most of us who are the lead developers are often the most intelligent. And we often enjoy these complicated abstract models and they come easy to us. However in satisfying our own intellectual vanity we often don't see how many we leave behind. Which is good for our hourly rates, but less good for creating affordable and simple software. Anyway one of the main practical advantages git had was decentralized repos meaning you were not dependent on an external server which meant git was often much faster if working with in daily tasks compared to centralized versioning systems
- BossingAround 4y ago
  I'm sorry if this sounds arrogant, but if you don't understand basic Git concepts like rebase, I don't think you're in a position to comment on the architecture of Git
  - toshk 4y ago
    Thats kinda the point :). I've read this many times, but schopenhauer in german is more readable: https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge https://stackoverflow.com/questions/804115/when-do-you-use-g...
lawn 4y ago
> It dominated the world despite the UX flaws, which suggests they really aren't that bad. No it doesn't. It suggests the other features are so damn good that it overcame the horrible UX.
ReptileMan 4y ago
So was mercurial ... but it much more user friendly.
pjmlp 4y ago
It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I bet git produced by a no name Linus, in isolation not required by any major project, would have hardly been taken any major uptake.
- Jedd 4y ago
  > It dominated the world thanks to Linus cult (their hero can do no wrong), and being required for Linux contributions. I think parent's point is that that demographic is positively tiny, and there were plenty of other serviceable offerings around at the time. The claim stands - git won despite its UX flaws, which does suggest the alternatives, while serviceable, weren't sufficiently fit for purpose.
  - pjmlp 4y ago
    The alternatives weren't required for collaboration in Linux development.
    - Jedd 4y ago
      Yes, but again, the number of people collaborating on Linux kernel development is truly tiny. I think perhaps you're over-estimating the network effect for VCS's -- having multiple version control binaries on your machine is low cost, and aliases can, up to a point, give you a consistent interface to them all. The highly sophisticated demographic of kernel developers would not have been at the pub insisting that their friends drop svn and use git (exclusively!), anymore than they would have been trying to get any other projects they worked on to adopt bitkeeper previously. The fact that bitkeeper was required for 'collaboration in Linux development' for so long supports this position.
      - pjmlp 4y ago
        Bitkeep wasn't free beer and its adoption was widely controversial, until Git was born given their change of heart.
koonsolo 4y ago
I've worked with CVS, Subversion, Bazaar, Visual SourceSave, Team Foundation Version Control, Mercurial and Git. The worst systems are the Microsoft ones, but the one with the most complex interface is definitely Git. I would argue it won because of github. I'm using Git because of that, but still prefer Mercurial in every way.
- memorable 4y ago
  I agree with this. Mercurial is cool, but if you need to convert your Mercurial project to Git to push to GitHub, then it's a fucking pain.
  - wrycoder 4y ago
    There is Sourcehut, which supports Hg.

hardware2win 4y ago

Git and regex

kcl 4y ago

Git's UI/UX is one of the worst engineering sins to be committed in the last two decades, and this website shows why. Literally nothing about git is intuitive and the "underlying model" is entirely ad-hoc. Instead of celebrating how Linus built git in only a few days he should be castigated for knowingly setting up ill-conceived software to go viral.

flohofwoe 4y ago
> for knowingly setting up ill-conceived software to go viral I doubt that was the intention. Linux just needed a versioning system tailored to its needs, and that's exactly what Git is. Can't blame its creators that other people used it for scenarios it wasn't built for.
- kcl 4y ago
  Right, you are the cop-out I am complaining about. Linus is the premier figurehead of the premier open-source project. When a build tool he made for that project goes viral it isn't an accident. If it was anybody else's pet versioning control system would we even be talking about it?
  - salamander014 4y ago
    If it went viral, yes. I agree most of the time I feel like the world is run by evil folks twiddling their fingers in secret. This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software. Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it. It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work. It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude. Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.

ReptileMan 4y ago

We had Mercurial but it died, not with a bang, but with a whisper ...

Beltalowda 4y ago
Mercurial is still actively developed, and isn't really "dead", although it did lose a lot of popularity and "mindshare". Projects like Firefox and nginx use it, although others like Vim and Python switched to GitHub. I don't know if Facebook is still using Mercurial internally, but for their public stuff they use GitHub. I think that if GitHub had supported Mercurial like BitBucket or Google Code it would still be a lot more popular, but ah well...

throwaway09223 4y ago

Is it, though? I'm not so sure. Git has enjoyed overwhelming success, which would seem to empirically indicate that it's done something right in terms of design Perhaps the obviously wrong UX/UI isn't wrong? Perhaps UX/UI people aren't good at designing interfaces for experts?

xigoi 4y ago
Git has been successful despite the UI, not because of it.
- throwaway09223 4y ago
  Can you substantiate your opinion? It's open source, so why hasn't an alternate interface taken over?
  - lolinder 4y ago
    Because standardization matters and the first thing to become the standard is extremely difficult to unseat.
    - throwaway09223 4y ago
      But some of types of things have in fact changed, sometimes for seemingly trivial reasons. For example, the master/main branch shift. Everything broke when that change was made, but it happened and it wasn't a big deal. I'm not seeing the difficulty here. It seems that a more reasonable interpretation is that git has the type of interface that is hard to learn, but intuitive once learned.
      - xigoi 4y ago
        The master/main shift was fueled by political correctness. If “master” wasn't a synonym of a word associated with slavery, it would've never happened.
- 4y ago

BossingAround 4y ago

To me, Git is designed in a very nice and understandable way with a terrible terminology. I might be an exception though.

huachimingo 4y ago

Basically all of the UNIX world.

elcapitan 4y ago

Honestly, when I think of software that I suffered using recently, then UX/UI people are usually the reason, not the solution for that suffering.

vaylian 4y ago

Please correct me if I'm wrong, but Linus probably didn't plan for git to be adopted by other people than just kernel developers. Because that was what git was created for originally.

agumonkey 4y ago

What I don't get is that the UX problem is not hard. I still like the underlying commit tree model a lot.. it's just some commands that are not clear enough (reset has 5 meanings and can backfire quickly). Maybe it's just retrocompatibility inertia.

seadan83 4y ago
I recommend you create aliases. I've got a 'git-squash' 'git-back' and 'git-update' aliases created, I almost forget they are not part of core git. Combined with scm-breeze that allows files and branches to be referenced with numbers... it's really fast and powerful

duped 4y ago

More a reminder that UX/UI is a lot less important than speed and functionality for professional work.