4 ms·

git user experience is very bad, objectively and not because of the complexity or the learning curve. A good UX allows you to learn patterns which are applicabl

by chx 8y ago

git user experience is very bad, objectively and not because of the complexity or the learning curve. A good UX allows you to learn patterns which are applicable across the application. git, on the other hand, offers you an absolutely bewildering mismash of commands and switches to express whether the operation involves a remote, the index or the working tree. This could've been and should've been consistent but no such thing. Beyond the consistency argument, Jef Raskin: Humane Interface argues for universal undo which git almost has via the reflog except it should've built a safety net for git reset --hard which is possible https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 (and no, disk space usage isn't a concern for 99.99% of the codebases, "disk is the new tape" predates git _and_ even without that recognition most codebases are tiny) and then it could git undo happily. Add these two and you have a user friendly git without taking away any power.

mg794613 8y ago
No that would make it unusable to use git in automation. what you are looking for is a training gui around git. until your learn enough to not shoot your foot. no need to dumb down a tool because someone doesn't get it.
- speedplane 8y ago
  > no need to dumb down a tool because someone doesn't get it. If your goal is to make a tool useful to the widest audience possible, then yes, that the goal is precisely to dumb it down so as many people as possible "get it".
- chx 8y ago
  I am unsure which of the two would be a bane of git automation but if it is git undo, the fix is really simple: make it opt out. I have git config and I am not afraid to use it.
speedplane 8y ago
I understand the difference, and understand why you use one over the other, but the fact that git has separate "squash", "merge", and "rebase" functions is a UX disaster.
- jnurmine 8y ago
  They are different commands because they are different things conceptually. Rebase is when you transplant another branch on top of another. Merge joins two branches together. Squash combines two or more commits into a single one They are by no means the same thing.
  - speedplane 8y ago
    I never said they were the same, I said that having three commands to contribute code is very confusing. A better design would not need "merge", "squash", and "rebase". For example, you wouldn't need to "merge" or "squash" if the system made it easy to visually group changes together.
jnurmine 8y ago
With git reset --hard protection do you mean accidentally resetting a branch which has uncommitted changes? If you do that a lot, why not commit your changes more often to your topic branch? You can always squash it later to make it look nice. Or use stash or something.
- chx 8y ago
  git reset --hard throws away work. Nuclear bomb operations should never be a simple switch away.
  - jnurmine 8y ago
    Of course it does. So does rm -rf. The dd command can ruin your entire disk with a typo.
    - chx 8y ago
      Their primary goal, however, is not tracking changes. Of course a tool made for deleting or lower level copying is destroying data, that's their primary use. git, however, is almost always undoable.
      - jnurmine 8y ago
        If you have not committed the changes, then Git is simply not aware that you want to keep those changes in the first place. It is like editing a file, and not saving it. Is the editor at fault? Should it autosave the file? Under what name? Under what directory? Or should the editor just do what you tell it to? For this particular case, git stash might help. In general (danger: personal opinion), it is good practise to be mindful of dangerous commands and take a deep breath before issuing them, whatever they are. That is what I do after having learnt it the hard way, as I have also messed up stuff with the hard Git reset, dd, rm, chmod, chown, cp, mv, tar, you name it... So, if you ask me, Git does not have an "objectively bad UI" as some say, it just does what it is told to. (Insert joke about computers being like an Old Testament God.)

by chx 8y ago

mg794613 8y ago

No that would make it unusable to use git in automation. what you are looking for is a training gui around git. until your learn enough to not shoot your foot. no need to dumb down a tool because someone doesn't get it.

speedplane 8y ago
> no need to dumb down a tool because someone doesn't get it. If your goal is to make a tool useful to the widest audience possible, then yes, that the goal is precisely to dumb it down so as many people as possible "get it".
chx 8y ago
I am unsure which of the two would be a bane of git automation but if it is git undo, the fix is really simple: make it opt out. I have git config and I am not afraid to use it.

speedplane 8y ago

I understand the difference, and understand why you use one over the other, but the fact that git has separate "squash", "merge", and "rebase" functions is a UX disaster.

jnurmine 8y ago
They are different commands because they are different things conceptually. Rebase is when you transplant another branch on top of another. Merge joins two branches together. Squash combines two or more commits into a single one They are by no means the same thing.
- speedplane 8y ago
  I never said they were the same, I said that having three commands to contribute code is very confusing. A better design would not need "merge", "squash", and "rebase". For example, you wouldn't need to "merge" or "squash" if the system made it easy to visually group changes together.

jnurmine 8y ago

With git reset --hard protection do you mean accidentally resetting a branch which has uncommitted changes? If you do that a lot, why not commit your changes more often to your topic branch? You can always squash it later to make it look nice. Or use stash or something.

chx 8y ago
git reset --hard throws away work. Nuclear bomb operations should never be a simple switch away.
- jnurmine 8y ago
  Of course it does. So does rm -rf. The dd command can ruin your entire disk with a typo.
  - chx 8y ago
    Their primary goal, however, is not tracking changes. Of course a tool made for deleting or lower level copying is destroying data, that's their primary use. git, however, is almost always undoable.
    - jnurmine 8y ago
      If you have not committed the changes, then Git is simply not aware that you want to keep those changes in the first place. It is like editing a file, and not saving it. Is the editor at fault? Should it autosave the file? Under what name? Under what directory? Or should the editor just do what you tell it to? For this particular case, git stash might help. In general (danger: personal opinion), it is good practise to be mindful of dangerous commands and take a deep breath before issuing them, whatever they are. That is what I do after having learnt it the hard way, as I have also messed up stuff with the hard Git reset, dd, rm, chmod, chown, cp, mv, tar, you name it... So, if you ask me, Git does not have an "objectively bad UI" as some say, it just does what it is told to. (Insert joke about computers being like an Old Testament God.)