4 ms·
A good UI exposes the underlying structure where necessary, while offering shortcuts for commonly used tasks or groups of tasks, and most importantly of all, it
by grey-area 10y ago
A good UI exposes the underlying structure where necessary, while offering shortcuts for commonly used tasks or groups of tasks, and most importantly of all, it is consistent. The internal design is elegant and simple, but the UI has grown organically and does not show the same level of care. I'm not convinced the problems with git lie with some fundamental difficulty with its internal model, they are more basic and it simply hasn't had as much care put into the UI as it should. I use the command line, and off the top of my head, problems with the UI are:
Inconsistent options between subcommands, e.g tag and stash
Complex options for everyday commands, e.g. git reset HEAD --file, git rebase -i HEAD~3, git checkout -b mybranch
The mix of options and subcommands, with no clear rationale and unclear naming (things like reset)
Separation of the stages of adding files with committing, I think the default should be combined, with options to separate the stages if required.
The man page assuming understanding of fundamentals for simple commands like git push or rebase
Finally, as an example of how unintuitive the UI is around something as simple as reset/undo - here is one of the top stack overflow questions for git with 12195 votes, which just wants to know how to undo a commit:
http://stackoverflow.com/questions/927358/how-to-undo-last-commits-in-git#927386 http://stackoverflow.com/questions/927358/how-to-undo-last-c...
to which the answers are commands like:
git reset HEAD~
git reset --hard HEAD~1
instead of something like this in the default case:
git undo
- jfroma 10y agoNot the mention inconsistency in commands, examples of how to remove something: git remote rm foobar But for branches git branch -d my_branch But for remote branches is : git push origin :my_branch
- DougBTX 10y agoThe last one can also be: git push origin --delete my_branch so, rm vs -d vs --delete
- palunon 10y agoOr git push origin -d my_branch, so rm vs -d
- grogenaut 10y agogit push origin HEAD:mainline git rebase origin/mainline git checkout -b origin/mainline origin/mainline # kappa, caused me hours of pain Some day we'll hopefully get a re-write of the command line, and replace some of this stuff that is obviously just cruft... and cruft that you could see coming a long time ago (been using it since rails core switched to git). I remember a conversation int the mailing list where people were talking about re-aligning this stuff but they were also worried about adoption and consistency so they left it. Maybe with git version 2.0 they said. This was like 2009.
- lawpoop 10y agoshell command aliases for now :P
- eriknstr 10y agoI agree with most of what you said but I strongly disagree with the following: >Separation of the stages of adding files with committing, I think the default should be combined, with options to separate the stages if required. My workflow is I make changes which may include many files. Once I'm done with the changes, I like to list the files that have changed, look over the changes to ensure that I don't have any unrelated changes, and if I do then I use "git add -p" for the files that I only want to add part of the changes for, and so at the point where I do that, I need to be able to add files in multiple steps because I only use "git add -p" for the files that need it, and for the remaining files I do regular "git add" since there is no point in having to go through the "git add -p" process with those. Once I have all my changes staged so far, I sometimes remember that there was yet another file that needed to change, so I change that file and stage it for commit. When I'm ready to commit, I review the whole diff that is staged for commit and then I commit it. To me, separate stages of adding files with committing is the only sane default.
- grey-area 10y agoThis does depend how you work and what you're working on. Since the default is your workflow, it'd be nice to have a command which dealt with the workflow of only changing files you wish to be in the next commit (which I imagine is also very common).
- jeremy_wiebe 10y agoWouldn't a simple shell alias for `git commit -am` solve this?
- grey-area 10y agoThat's what I do but we were discussing the git UI, which has many examples like this.