4 ms·

I do find this mildly amusing – and sad – as git is possibly one of the worst SCMs for non-programmers because its command set is so bottom-up, and therefore do

I do find this mildly amusing – and sad – as git is possibly one of the worst SCMs for non-programmers because its command set is so bottom-up, and therefore doesn't align with a naive mental model of how version control should work, while at the same time it exposes an interface that makes it all to easy to screw things up catastrophically. GUI tools only help with that to some extent, too, and only the right ones.

prepend 6y ago
It’s funny to me because git seems like it would be the worst, but is the widest adopted scm by non-programmers from anything I’ve seen. It has more users, I think, than even the “visual” source control systems that are supposed to be more usable.
- dognotdog 6y ago
  Oh, I've had the joy of working with Perforce, Jazz / Team Concert, etc. /s Git is widest adopted, period (EDIT: because of how it blossomed out of linux dev, essentially). I was able to stick to bzr or fossil for a lot of things until github and gitlab basically became where open source work (and even corporate transitioned to some extent!) needed to happen, and the friction of using anything else is just too great at this point in time. Which is a shame, really, as --fast-import/export is actually not a bad way to transition from one scm to another these days, and I'd personally welcome a little more active competition in the space to evolve beyond the current status quo.
icedistilled 6y ago
I came from a chemE background and it wasn't even any computational heavy branch of it. Now I do data science in a different field. I feel like command line Git is fantastic and simple 95% of the time and much prefer it over GUIs. Is git really that hard? Although I really dislike GUIs in general so maybe that's it.
- lmm 6y ago
  The way the staging area interacts with other commands is completely nonsensical (example: stash and then unstash, and you'll find you've changed which parts of your diff were staged). The commands are horrendously inconsistent and non-orthogonal: git checkout does zillions of different things, git remote needs -v to do anything useful, using "-" to refer to the previous branch works for some commands but not others...
barumi 6y ago
> (...) as git is possibly one of the worst SCMs for non-programmers because its command set is so bottom-up, In your personal opinion, what's so "bottom up" about checking out code from a repository and committing changes to a branch? > (...) while at the same time it exposes an interface that makes it all to easy to screw things up catastrophically. What? Care to point out a single example of what you perceive as being one of those "catastrophical" failures? In all my professional life, which includes a bunch of years as a data analysis, I never experienced a single failure with git. Not a single one. In fact, the only failure I ever experienced with git came from a stupid error I once made by tracking a git repository which found its way into a Dropbox shared folder. Care to shed some light on what you perceive as being your pain points?
marcus_holmes 6y ago
it's like Churchill's democracy - clearly the worst, except for all the others.
- GuB-42 6y ago
  You should give Mercurial a try. Fundamentally it is a same as git: you can push, pull, you have commits, branches, merges, etc... and branching is easy. It is mostly a difference in philosophy. While git will leave you with lots of powerful and flexible tools, Mercurial will be much more limited out of the box, advanced features are extensions you have to enable. The Mercurial history is also considered sacred, and everything is done do discourage you from modifying it, commands like squash and rebase are hidden behind extensions, branches are also permanently attached to commits (the equivalent of git branches exist and are called bookmarks). There is also no staging area. Instead of "remote" branches, there is a simpler "phase" system that tell you which commits are local and which one have been pushed. All that makes Mercurial easier to use, especially for non-developers. And in fact, most people who tried both preferred it over git, with the exception of git experts, who prefer git for its speed and flexibility.
  - marcus_holmes 6y ago
    Git is such a standard these days that I don't think I can switch without it being difficult, even if I wanted to. tbh I'm mostly happy with git. It does what I need it to do. Yes, it could be easier and more transparent, but everything is a trade-off.
natalyarostova 6y ago
It is what it is. If you want to be productive as a modern tech team just deal with it and use it and learn it.

prepend 6y ago

It’s funny to me because git seems like it would be the worst, but is the widest adopted scm by non-programmers from anything I’ve seen. It has more users, I think, than even the “visual” source control systems that are supposed to be more usable.

dognotdog 6y ago
Oh, I've had the joy of working with Perforce, Jazz / Team Concert, etc. /s Git is widest adopted, period (EDIT: because of how it blossomed out of linux dev, essentially). I was able to stick to bzr or fossil for a lot of things until github and gitlab basically became where open source work (and even corporate transitioned to some extent!) needed to happen, and the friction of using anything else is just too great at this point in time. Which is a shame, really, as --fast-import/export is actually not a bad way to transition from one scm to another these days, and I'd personally welcome a little more active competition in the space to evolve beyond the current status quo.

icedistilled 6y ago

I came from a chemE background and it wasn't even any computational heavy branch of it. Now I do data science in a different field. I feel like command line Git is fantastic and simple 95% of the time and much prefer it over GUIs. Is git really that hard? Although I really dislike GUIs in general so maybe that's it.

lmm 6y ago
The way the staging area interacts with other commands is completely nonsensical (example: stash and then unstash, and you'll find you've changed which parts of your diff were staged). The commands are horrendously inconsistent and non-orthogonal: git checkout does zillions of different things, git remote needs -v to do anything useful, using "-" to refer to the previous branch works for some commands but not others...

barumi 6y ago

> (...) as git is possibly one of the worst SCMs for non-programmers because its command set is so bottom-up, In your personal opinion, what's so "bottom up" about checking out code from a repository and committing changes to a branch? > (...) while at the same time it exposes an interface that makes it all to easy to screw things up catastrophically. What? Care to point out a single example of what you perceive as being one of those "catastrophical" failures? In all my professional life, which includes a bunch of years as a data analysis, I never experienced a single failure with git. Not a single one. In fact, the only failure I ever experienced with git came from a stupid error I once made by tracking a git repository which found its way into a Dropbox shared folder. Care to shed some light on what you perceive as being your pain points?

marcus_holmes 6y ago

it's like Churchill's democracy - clearly the worst, except for all the others.

GuB-42 6y ago
You should give Mercurial a try. Fundamentally it is a same as git: you can push, pull, you have commits, branches, merges, etc... and branching is easy. It is mostly a difference in philosophy. While git will leave you with lots of powerful and flexible tools, Mercurial will be much more limited out of the box, advanced features are extensions you have to enable. The Mercurial history is also considered sacred, and everything is done do discourage you from modifying it, commands like squash and rebase are hidden behind extensions, branches are also permanently attached to commits (the equivalent of git branches exist and are called bookmarks). There is also no staging area. Instead of "remote" branches, there is a simpler "phase" system that tell you which commits are local and which one have been pushed. All that makes Mercurial easier to use, especially for non-developers. And in fact, most people who tried both preferred it over git, with the exception of git experts, who prefer git for its speed and flexibility.
- marcus_holmes 6y ago
  Git is such a standard these days that I don't think I can switch without it being difficult, even if I wanted to. tbh I'm mostly happy with git. It does what I need it to do. Yes, it could be easier and more transparent, but everything is a trade-off.

natalyarostova 6y ago

It is what it is. If you want to be productive as a modern tech team just deal with it and use it and learn it.