3 ms·

Git is an incredibly powerful abstraction for decentralized version control, with the absolute worst damn user interface. I am constantly required to be aware o

Git is an incredibly powerful abstraction for decentralized version control, with the absolute worst damn user interface. I am constantly required to be aware of its internal state and implementation details, which it fights so hard to hide.

necovek 3y ago
I am not sure that's really correct: while Git is internally pretty powerful, it's by no means incredibly powerful. Eg. one of the obvious missing features (for a distributed VCS) is nested history (i.e. in Bazaar/bzr, now brz, you'd keep "subcommits" when merging, without them overcrowding the main "bzr log"). Basically, while advertised as being distributed, you are forced to either rebase or squash-and-merge to keep a clean commit history, which is not how humans operate: basically, I want to have a gazillion tiny commits if it's a distributed system (iow, use it how I like it), but not have those show up for a single top-level change. Also, internals do drive what UX you can have: this is evident even in web applications (eg. if you've got a particular backend REST API, you might not be able to achieve some UX workflows without reworking the backend too).
- phailhaus 3y ago
  > I am not sure that's really correct: while Git is internally pretty powerful, it's by no means incredibly powerful. Good thing neither "pretty powerful" nor "incredibly powerful" have formal definitions ;) > Also, internals do drive what UX you can have Yes, but that's not what I'm talking about. Git just has bad UX. There's no reason why creating a branch can't be part of `git branch` rather than `git checkout`, but that was an opinionated decision that every user just has to deal with now. Or, why does `git stash pop` immediately stage changes if there's a conflict, but not otherwise? Yes, there's always a reason behind these choices, but they prioritize some concept of "purity" over UX. The result is a tool that has spawned a thousand "learn git" tutorials because it's so user-hostile.

necovek 3y ago

I am not sure that's really correct: while Git is internally pretty powerful, it's by no means incredibly powerful. Eg. one of the obvious missing features (for a distributed VCS) is nested history (i.e. in Bazaar/bzr, now brz, you'd keep "subcommits" when merging, without them overcrowding the main "bzr log"). Basically, while advertised as being distributed, you are forced to either rebase or squash-and-merge to keep a clean commit history, which is not how humans operate: basically, I want to have a gazillion tiny commits if it's a distributed system (iow, use it how I like it), but not have those show up for a single top-level change. Also, internals do drive what UX you can have: this is evident even in web applications (eg. if you've got a particular backend REST API, you might not be able to achieve some UX workflows without reworking the backend too).

phailhaus 3y ago
> I am not sure that's really correct: while Git is internally pretty powerful, it's by no means incredibly powerful. Good thing neither "pretty powerful" nor "incredibly powerful" have formal definitions ;) > Also, internals do drive what UX you can have Yes, but that's not what I'm talking about. Git just has bad UX. There's no reason why creating a branch can't be part of `git branch` rather than `git checkout`, but that was an opinionated decision that every user just has to deal with now. Or, why does `git stash pop` immediately stage changes if there's a conflict, but not otherwise? Yes, there's always a reason behind these choices, but they prioritize some concept of "purity" over UX. The result is a tool that has spawned a thousand "learn git" tutorials because it's so user-hostile.