4 ms·

"I really don't get the complaints about git's UI" I think it's because git's data model is so minimal and elegant, and the UI is anything but. For me, it's n

by danh 16y ago

"I really don't get the complaints about git's UI" I think it's because git's data model is so minimal and elegant, and the UI is anything but. For me, it's not so much that the UI is quite bad (which it is), but that it could have been brilliant.

etherealG 16y ago
Perhaps you could elaborate on a UI design that would be brilliant. Even better, code it, if you can improve do. I'll tell you what, if you even succeed in describing such an interface, I'll build it for you.
- defrex 16y ago
  See bazaar.canonical.com.
  - etherealG 16y ago
    a cursory glance at the screenshots there show it similar to git gui / gitx or similar. I'm talking about fundamental interaction with the version control system, not a pretty gui. git has pretty gui too.
    - mbrubeck 16y ago
      It's not just the GUI - bzr has one of the better-designed command line UIs too. It's very similar to Mercurial's, plus some nice things borrowed from other systems but integrated very consistently. (But I do agree that there's more to a VCS than UI design, and after the initial learning curve there's not a huge difference in command-line usage between the popular systems.)
      - __david__ 16y ago
        I disagree. I found bzr to be a mishmash of poorly thought out options and features. A quick example: Compare bzr log's "-r" option to "git rev-list". bzr's "A..B" is stupidly inclusive on both ends making scripting very difficult. If you want a really nice, consistent UI, check out darcs.
- danh 16y ago
  Oh, I didn't say that it would have been brilliant if I had built it. But I'll bite anyway. Or at least provide a couple of thoughts. The index is one of the key components in git, but it doesn't really have a name or label in the UI. Say that it was called "index"; then the current "git diff" would be equivalent to "git diff index", and the current "git diff --cached" to "git diff index..HEAD". Less special cases to remember. IMHO, of course. The same way "git checkout index foo.c" would fetch foo.c from the index (I don't even remember the magic incantation for doing that now). Etc. Also, I still think that using the index should be optional: "git diff" should default to "git diff HEAD", "git commit" should default to the current "git commit -a", etc. "git checkout" tries to do too much. It creates and switches to branches, and copies blobs from the repository to the working tree. The first form is reasonably safe, and bails out without --force if you do something stupid, the second does not. At least for me, the only way to learn the difference is the hard way. The branch-switching should probably be done by "git branch" instead, and the fetching of blobs by "git reset" (which sometimes already does this, but with very confusing options; I never remember the difference between --soft, --mixed, --hard, --mixed and whatever). That's only a couple of changes that could have been made a long time ago. Now it is definitely too late. Even if the git UI could be made smaller and more logical (with a huge amount of work), it's not worth pissing off pretty much every git user out there...
  - wfarr 16y ago
    I disagree on making `git commit -a` the default behavior for commits in git. It discourages making nice, atomic commits.
    - danh 16y ago
      I agree that two-stage commits is a great feature to have. But there are downsides to making it the default. Obviously, it trips beginners up. And it encourages committing stuff that may never have coexisted in the working tree - and thus have never been tested together.
      - wfarr 16y ago
        I can't think of any reason for someone to commit changes that hadn't been tested in the working tree or at least ran through the test suite before doing so.
samstokes 16y ago
It could still be brilliant. Git's porcelain (the high-level commands you use day to day) has evolved a lot over the last few releases - e.g. "git mergetool". Indeed a couple of years ago ISTR the recommended way for most developers to use git was with a third-party porcelain layer, but the built-in porcelain improved enough to be blessed and the third-party layer was deprecated.
j2d2 16y ago
Try SmartGit.

by danh 16y ago

etherealG 16y ago

Perhaps you could elaborate on a UI design that would be brilliant. Even better, code it, if you can improve do. I'll tell you what, if you even succeed in describing such an interface, I'll build it for you.

defrex 16y ago
See bazaar.canonical.com.
- etherealG 16y ago
  a cursory glance at the screenshots there show it similar to git gui / gitx or similar. I'm talking about fundamental interaction with the version control system, not a pretty gui. git has pretty gui too.
  - mbrubeck 16y ago
    It's not just the GUI - bzr has one of the better-designed command line UIs too. It's very similar to Mercurial's, plus some nice things borrowed from other systems but integrated very consistently. (But I do agree that there's more to a VCS than UI design, and after the initial learning curve there's not a huge difference in command-line usage between the popular systems.)
    - __david__ 16y ago
      I disagree. I found bzr to be a mishmash of poorly thought out options and features. A quick example: Compare bzr log's "-r" option to "git rev-list". bzr's "A..B" is stupidly inclusive on both ends making scripting very difficult. If you want a really nice, consistent UI, check out darcs.
danh 16y ago
Oh, I didn't say that it would have been brilliant if I had built it. But I'll bite anyway. Or at least provide a couple of thoughts. The index is one of the key components in git, but it doesn't really have a name or label in the UI. Say that it was called "index"; then the current "git diff" would be equivalent to "git diff index", and the current "git diff --cached" to "git diff index..HEAD". Less special cases to remember. IMHO, of course. The same way "git checkout index foo.c" would fetch foo.c from the index (I don't even remember the magic incantation for doing that now). Etc. Also, I still think that using the index should be optional: "git diff" should default to "git diff HEAD", "git commit" should default to the current "git commit -a", etc. "git checkout" tries to do too much. It creates and switches to branches, and copies blobs from the repository to the working tree. The first form is reasonably safe, and bails out without --force if you do something stupid, the second does not. At least for me, the only way to learn the difference is the hard way. The branch-switching should probably be done by "git branch" instead, and the fetching of blobs by "git reset" (which sometimes already does this, but with very confusing options; I never remember the difference between --soft, --mixed, --hard, --mixed and whatever). That's only a couple of changes that could have been made a long time ago. Now it is definitely too late. Even if the git UI could be made smaller and more logical (with a huge amount of work), it's not worth pissing off pretty much every git user out there...
- wfarr 16y ago
  I disagree on making `git commit -a` the default behavior for commits in git. It discourages making nice, atomic commits.
  - danh 16y ago
    I agree that two-stage commits is a great feature to have. But there are downsides to making it the default. Obviously, it trips beginners up. And it encourages committing stuff that may never have coexisted in the working tree - and thus have never been tested together.
    - wfarr 16y ago
      I can't think of any reason for someone to commit changes that hadn't been tested in the working tree or at least ran through the test suite before doing so.

samstokes 16y ago

It could still be brilliant. Git's porcelain (the high-level commands you use day to day) has evolved a lot over the last few releases - e.g. "git mergetool". Indeed a couple of years ago ISTR the recommended way for most developers to use git was with a third-party porcelain layer, but the built-in porcelain improved enough to be blessed and the third-party layer was deprecated.

j2d2 16y ago

Try SmartGit.