3 ms·

I have family who are lawyers. They and a great many of their colleagues can barely type without looking at the keyboard. You're suggesting that the kind of p

by na85 10y ago

I have family who are lawyers. They and a great many of their colleagues can barely type without looking at the keyboard. You're suggesting that the kind of person who still double-clicks on hyperlinks can learn git? I'm an aerospace engineer and I can barely use git. Git's UI/UX is a fucking disaster that just happens to suck less than what came before it.

zekevermillion 10y ago
I think you would want to combine an open source toolset with a paid service with trained monkeys to bridge the gap. For instance let's say I send a draft out, and receive a PDF markup back. The trained monkey would make sure that the new version is accurately reflected in the repo. As long as I am working natively, then exporting my response back into whatever lame format is desired will be trivial. It's a bridge to a better world and more elegant system.
- na85 10y ago
  The engineer in me hates how inefficient that is. Also it smacks of a make-work project... paying someone to manually insert markup seems like a huge waste of money. Surely it'd be cheaper in the long run to just spend the money on some UX designers?
  - zekevermillion 10y ago
    I think you need a human to manage the import bc any OCR or conversion error could kill the whole experience. Hopefully rhe machines could get us 90 percent of the way there. You know law firms used to employ armies of typists to prepare manual (pencil) difs of paper docs, so there is a certain cultural willingness to pay for perfect results, particularly on larger transactions.
leohutson 10y ago
Git is not great UX wise, but it's probably not as big of an issue as people like to make out, especially if you are already comfortable in a shell. The reason people find git hard is that concepts of distributed version control are hard. There are plenty of nice git native GUI's and web apps, and mercurial offers a more consistent command line UX, but that doesn't change the fact that people need to understand a crap load of higher-level concepts before they can find their DVCS useful. Such as: file-system folder structures diffs/patches commits/uncommited changes branching merging and conflict resolution. remote vs local repositories To me it's like how people complain about mathematical notation being complicated and inconsistent, but that's just the first superficial "alien" looking stuff that tells you that you don't understand the new concept. Once you understand the underlying concepts, the notation doesn't get much further thought.
- na85 10y ago
  >The reason people find git hard is that concepts of distributed version control are hard. Maybe. For me it was because the documentation is written like a comp sci whitepaper. I've ranted about this elsewhere on HN but the man pages are filled with stuff like "update remote refs" as if a person would have a fucking clue what a ref is and why you'd want to update a remote one. Branching, merging, tagging, all of that sounds great. I've been using git for years, but the problem is that I don't use it every day, and so I still get a little wary when I want to run a merge. I can't tell you right now off the top of my head how to merge if there is a conflict. I always have to google around for "how to undo a commit". Etc. etc. etc. Where the fuck do my files go when I switch to a different branch? Do they actually change in the working directory? Checkout vs fetch? Where exactly in the file system is this alleged "staging area"? I have no idea about any of these, mostly because the documentation is just so poorly written that it takes me too long to find out the answers and I have more important things to do than Greco-Roman wrestling matches with my software tooling, but I'm afraid that if I just try things at random I'll do something I can't undo because none of the options seem particularly intuitive. It's just not a very good piece of software.
  - rimantas 10y ago
    Software is good , your mental model of it is bad. Trying to put the squre peg of git into the round hole of filesystem is bound to produce frustration.
- pjmlp 10y ago
  > The reason people find git hard is that concepts of distributed version control are hard. Have you ever used Mercurial?

by na85 10y ago

zekevermillion 10y ago

I think you would want to combine an open source toolset with a paid service with trained monkeys to bridge the gap. For instance let's say I send a draft out, and receive a PDF markup back. The trained monkey would make sure that the new version is accurately reflected in the repo. As long as I am working natively, then exporting my response back into whatever lame format is desired will be trivial. It's a bridge to a better world and more elegant system.

na85 10y ago
The engineer in me hates how inefficient that is. Also it smacks of a make-work project... paying someone to manually insert markup seems like a huge waste of money. Surely it'd be cheaper in the long run to just spend the money on some UX designers?
- zekevermillion 10y ago
  I think you need a human to manage the import bc any OCR or conversion error could kill the whole experience. Hopefully rhe machines could get us 90 percent of the way there. You know law firms used to employ armies of typists to prepare manual (pencil) difs of paper docs, so there is a certain cultural willingness to pay for perfect results, particularly on larger transactions.

leohutson 10y ago

Git is not great UX wise, but it's probably not as big of an issue as people like to make out, especially if you are already comfortable in a shell. The reason people find git hard is that concepts of distributed version control are hard. There are plenty of nice git native GUI's and web apps, and mercurial offers a more consistent command line UX, but that doesn't change the fact that people need to understand a crap load of higher-level concepts before they can find their DVCS useful. Such as: file-system folder structures diffs/patches commits/uncommited changes branching merging and conflict resolution. remote vs local repositories To me it's like how people complain about mathematical notation being complicated and inconsistent, but that's just the first superficial "alien" looking stuff that tells you that you don't understand the new concept. Once you understand the underlying concepts, the notation doesn't get much further thought.

na85 10y ago
>The reason people find git hard is that concepts of distributed version control are hard. Maybe. For me it was because the documentation is written like a comp sci whitepaper. I've ranted about this elsewhere on HN but the man pages are filled with stuff like "update remote refs" as if a person would have a fucking clue what a ref is and why you'd want to update a remote one. Branching, merging, tagging, all of that sounds great. I've been using git for years, but the problem is that I don't use it every day, and so I still get a little wary when I want to run a merge. I can't tell you right now off the top of my head how to merge if there is a conflict. I always have to google around for "how to undo a commit". Etc. etc. etc. Where the fuck do my files go when I switch to a different branch? Do they actually change in the working directory? Checkout vs fetch? Where exactly in the file system is this alleged "staging area"? I have no idea about any of these, mostly because the documentation is just so poorly written that it takes me too long to find out the answers and I have more important things to do than Greco-Roman wrestling matches with my software tooling, but I'm afraid that if I just try things at random I'll do something I can't undo because none of the options seem particularly intuitive. It's just not a very good piece of software.
- rimantas 10y ago
  Software is good , your mental model of it is bad. Trying to put the squre peg of git into the round hole of filesystem is bound to produce frustration.
pjmlp 10y ago
> The reason people find git hard is that concepts of distributed version control are hard. Have you ever used Mercurial?