Honestly, a similar tool should rethink the design to be more intuitive, orthogonal and have fewer concepts that cover all use-cases.
With regards to Git I’m a victim of Stockholm syndrome, thus it’s hard for me to see where are all those alleged unintuitive design choices.
This analysis is rendered even more difficult as these criticisms of Git are depicted in vague terms without mentioning a single concrete example.
To make matters worse, these accusations become even less credible given the fact that all other Git competitors seem to copy Git’s user interface almost verbatim. This means Git must be doing something right.
So given this issue, is there any concrete example of where Git is lacking in the UI department?
I had a really pleasant experience using mercurial. Some of the things git may be missing:
excellent tui for selecting chunks like incommit -i. Arrow keys quickly fold and unfold files/chunks/individual lines
commits come in 3 categories:
public commits were seen by other people and are considered immutable
draft commit is your regular WIP local commit and can’t be a parent to a public commit.
secret commit with your printf debugging won’t be uploaded by accident
when you rebase, your previous commits are marked obsolete and hidden from most UI. For an obsolete commit it is easy to find it’s updated version. The graph of obsolete revisions is an orthogonal DAG on top of the regular commit DAG.
I use git almost every hour and I rarely have to deal with git problems (just enough practice to avoid them). I’m also confident about resolving problems if they do arise. Heck, I even configure my entire system and manage my life using text files managed by git. So I don’t claim that it’s all that bad.
But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have. I’m saying this as someone who trained a lot of people in using git from the very beginner level, all the way up to emailing patches - as part of a community and as a corporate trainer. I can write essays about every single problem that can trip a beginner due to git’s inconsistency - but am not going to - because they are acknowledged problems (by git devs) and they actively work on it.
But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have.
And yet you were not capable of providing a single example. You managed to put together personal attacks, but no example.
Sorry. I am not willing to waste my time typing out examples for someone who is too stubborn and lazy to just Google it - It’s a topic that has been discussed a billion times. If you want to paint me as incapable for that, go ahead - your opinion is worth as much as your willingness to just search for an answer yourself.
With regards to Git I’m a victim of Stockholm syndrome, thus it’s hard for me to see where are all those alleged unintuitive design choices.
This analysis is rendered even more difficult as these criticisms of Git are depicted in vague terms without mentioning a single concrete example.
To make matters worse, these accusations become even less credible given the fact that all other Git competitors seem to copy Git’s user interface almost verbatim. This means Git must be doing something right.
So given this issue, is there any concrete example of where Git is lacking in the UI department?
I had a really pleasant experience using mercurial. Some of the things git may be missing:
commit -i
. Arrow keys quickly fold and unfold files/chunks/individual linespublic
commits were seen by other people and are considered immutabledraft
commit is your regular WIP local commit and can’t be a parent to apublic
commit.secret
commit with your printf debugging won’t be uploaded by accidentrebase
, your previous commits are markedobsolete
and hidden from most UI. For an obsolete commit it is easy to find it’s updated version. The graph of obsolete revisions is an orthogonal DAG on top of the regular commit DAG.I use git almost every hour and I rarely have to deal with git problems (just enough practice to avoid them). I’m also confident about resolving problems if they do arise. Heck, I even configure my entire system and manage my life using text files managed by git. So I don’t claim that it’s all that bad.
But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have. I’m saying this as someone who trained a lot of people in using git from the very beginner level, all the way up to emailing patches - as part of a community and as a corporate trainer. I can write essays about every single problem that can trip a beginner due to git’s inconsistency - but am not going to - because they are acknowledged problems (by git devs) and they actively work on it.
And yet you were not capable of providing a single example. You managed to put together personal attacks, but no example.
Sorry. I am not willing to waste my time typing out examples for someone who is too stubborn and lazy to just Google it - It’s a topic that has been discussed a billion times. If you want to paint me as incapable for that, go ahead - your opinion is worth as much as your willingness to just search for an answer yourself.