5 ms·

personally, I really don't get the complaints about git's UI. OK. I understand the confusion about what checkout does, though on the other hand, once you know t

by pilif 16y ago

personally, I really don't get the complaints about git's UI. OK. I understand the confusion about what checkout does, though on the other hand, once you know that, it won't happen to you. But a revision control system failing to not corrupt or crash depending on the data you put into it is, frankly, no revision control system. Just like a database failing to return the same data back that you told it to store and without telling you a problem occurred at store time is no database either (cough mysql cough).

davidw 16y ago
> I really don't get the complaints about git's UI I would group mine into two main categories: * Error messages that are confusing. * Requiring that the user knows a fair number of options to commands. You can get by in svn without knowing many options to pass to commands, but with git, you're going to sink if you don't.
- Xurinos 16y ago
  Error messages that are confusing. Which ones? I have found them helpful, suggesting the right possible commands to use to solve a problem. Requiring that the user knows a fair number of options to commands. Which ones? "git add", "git commit", "git push", "git log", "git revert", "git checkout", "git merge", and "git branch" do not require any options unless you want some shortcuts or useful things that SVN cannot do.
  - jerf 16y ago
    The error messages have been undergoing fairly rapid change lately, as in, over the past year. I'd say that anyone complaining about the error messages should double-check that they have a very recent version. If you're just using your distro's version you may be a ways back. That said, there are still some error messages that are quite good, if you understand git's model, but if you don't are nearly opaque. (Easy to google, though.) Git really is unfriendly to you if you're just trying to hack along without understanding how it works, and I don't see that ever changing. It's a power tool, not a butter knife, and while it can, should, and does have guards in the right place to keep you from really hurting yourself (you basically can't lose data in the repository, thanks to reflog; be careful with checkout, though), it's not ever going to be quite as simple as a casual user would like. If it was, it wouldn't be git anymore.
  - ubercore 16y ago
    An example that trips me up frequently is creating a remote branch, then tracking it in a local branch. This is by far my most common workflow, but as far as I've learned so far, involves a couple of commands with some easy to forget options. Granted, after a few times I just wrote it down, and now mostly remember, but it's not as simple as it potentially could be. I was also a little shocked to find that I couldn't simply start tracking a remote branch after a local branch had already been created -- requires git 1.7. The workaround was simple (create a new tracking branch and merge the changes over), but to me this is an example of the UI being a little unhelpful.
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.
sandGorgon 16y ago
Why is git still a collection of bash scripts ? Does nobody care enough to wrap the core into a library (yes, i do know about the glacial libgit2 project) and put a Python/Ruby/Lua interface over it ? Dulwich exists, but it is not a drop-in replacement. When will I get a true platform independent Git (none of the msysgit stuff) ?
- fr0sty 16y ago
  It is still bash because bash is more universal than Python+Ruby+Lua. The only place bash doesn't exist is on Windows and installing Cygwin is the least of your worries in that case.
  - sandGorgon 16y ago
    we have selenium testcases that need to be run on IE. We need to have a revision control on windows. Please dont be dismissive of windows just because you can, some of us have to make a living.
wisty 16y ago
I don't think there is a problem with the UI. I don't use git, but by the tone of the comments people seem to be unable to use it, and therefore blame the UI. I think the real problem is the documentation, both official and unofficial. The best git intro I could find was gittutorial. It's OK, but a bit unfriendly. Everything else rapidly goes from telling you how to do stuff to teaching you how git works. If somebody came from SVN and told me that hg was unintuitive I'd tell them it's pretty easy, and they just have to get used to a slightly different model. Then I'd tell they to try hginit.com. I'd also point out how they can still work while the network is hosed, and that even if the server dies they still have all the history. Cool, isn't it? git users tell people to learn graph theory.
skybrian 16y ago
Coming from Perforce, I'd say that git's model seems overly rigid. In Perforce, workflow looks like this: - edit files A, B, C, D, E in the default changelist. - put A and B in changelist #1 - put C, D, E in changelist #2 - oops, C is the wrong changelist. Move it to #1. - edit file F (starts out in default changelist) - put F in changelist #1 - send both changelists out for review. - edit file B based on review. Run tests to make sure both CLs work together. - commit one of the CL's So the basic idea is that I have multiple changelists open simultaneously and the contents of the changelists are fluid. I can keep changing my mind about them until commit. Of course, since Perforce CL's are file-based, this all breaks down if I want overlapping uncommitted CL's. Git handles that better, which is why I'm using Git now. But I still miss the ease of use of Perforce when working on multiple CL's. Sure, the commits in Git are only local and you can always edit them until you do a push, but it seems like I have to plan ahead more and commit more often, or I end up having to split or merge CL's using commands I'm not very comfortable with.
- koenigdavidmj 16y ago
  Not sure if you know about Perforce's shelving feature, but it might be useful for you. Here's how it looks: 1. Hack on files 'foo' and 'bar', but instead of saying `p4 change`, say `p4 shelve`. Write down the changelist number for later; this changelist is stored on the server now. 2. `p4 revert foo bar`. You don't lose any changes; they're all on the server. 3. Hack on files 'bar' and 'baz'. Submit or shelve those changes. 4. `p4 unshelve -c (changelist number from step 1)`. (You'll probably need to resolve here.) Your original changes are back! Git certainly breaks down if you're working on one massive branch, but it's designed for lots of branching. Go ahead; we're encouraging you to branch for every new feature, every bug fix, everything. Here's the above workflow in git: 1. `git checkout -b first-change`. Hack on files 'foo' and 'bar' and commit. 2. `git checkout old-branch`, where 'old-branch' is the branch that you were on before step 1, probably 'master'. Now `git checkout -b second-change` and edit files 'bar' and 'baz'. Commit again. 3. Checkout the old branch (master, likely) again. `git merge first-change`. `git merge second-change`. Resolve if required. Test. Push changes to the remote server. Best of all, you don't need to branch before making your changes. You could actually move the `git checkout -b first-change` to after the edits on that branch, and it would still do what you want.

by pilif 16y ago

davidw 16y ago

> I really don't get the complaints about git's UI I would group mine into two main categories: * Error messages that are confusing. * Requiring that the user knows a fair number of options to commands. You can get by in svn without knowing many options to pass to commands, but with git, you're going to sink if you don't.

Xurinos 16y ago
Error messages that are confusing. Which ones? I have found them helpful, suggesting the right possible commands to use to solve a problem. Requiring that the user knows a fair number of options to commands. Which ones? "git add", "git commit", "git push", "git log", "git revert", "git checkout", "git merge", and "git branch" do not require any options unless you want some shortcuts or useful things that SVN cannot do.
- jerf 16y ago
  The error messages have been undergoing fairly rapid change lately, as in, over the past year. I'd say that anyone complaining about the error messages should double-check that they have a very recent version. If you're just using your distro's version you may be a ways back. That said, there are still some error messages that are quite good, if you understand git's model, but if you don't are nearly opaque. (Easy to google, though.) Git really is unfriendly to you if you're just trying to hack along without understanding how it works, and I don't see that ever changing. It's a power tool, not a butter knife, and while it can, should, and does have guards in the right place to keep you from really hurting yourself (you basically can't lose data in the repository, thanks to reflog; be careful with checkout, though), it's not ever going to be quite as simple as a casual user would like. If it was, it wouldn't be git anymore.
- ubercore 16y ago
  An example that trips me up frequently is creating a remote branch, then tracking it in a local branch. This is by far my most common workflow, but as far as I've learned so far, involves a couple of commands with some easy to forget options. Granted, after a few times I just wrote it down, and now mostly remember, but it's not as simple as it potentially could be. I was also a little shocked to find that I couldn't simply start tracking a remote branch after a local branch had already been created -- requires git 1.7. The workaround was simple (create a new tracking branch and merge the changes over), but to me this is an example of the UI being a little unhelpful.

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.

sandGorgon 16y ago

Why is git still a collection of bash scripts ? Does nobody care enough to wrap the core into a library (yes, i do know about the glacial libgit2 project) and put a Python/Ruby/Lua interface over it ? Dulwich exists, but it is not a drop-in replacement. When will I get a true platform independent Git (none of the msysgit stuff) ?

fr0sty 16y ago
It is still bash because bash is more universal than Python+Ruby+Lua. The only place bash doesn't exist is on Windows and installing Cygwin is the least of your worries in that case.
- sandGorgon 16y ago
  we have selenium testcases that need to be run on IE. We need to have a revision control on windows. Please dont be dismissive of windows just because you can, some of us have to make a living.

wisty 16y ago

I don't think there is a problem with the UI. I don't use git, but by the tone of the comments people seem to be unable to use it, and therefore blame the UI. I think the real problem is the documentation, both official and unofficial. The best git intro I could find was gittutorial. It's OK, but a bit unfriendly. Everything else rapidly goes from telling you how to do stuff to teaching you how git works. If somebody came from SVN and told me that hg was unintuitive I'd tell them it's pretty easy, and they just have to get used to a slightly different model. Then I'd tell they to try hginit.com. I'd also point out how they can still work while the network is hosed, and that even if the server dies they still have all the history. Cool, isn't it? git users tell people to learn graph theory.

skybrian 16y ago

Coming from Perforce, I'd say that git's model seems overly rigid. In Perforce, workflow looks like this: - edit files A, B, C, D, E in the default changelist. - put A and B in changelist #1 - put C, D, E in changelist #2 - oops, C is the wrong changelist. Move it to #1. - edit file F (starts out in default changelist) - put F in changelist #1 - send both changelists out for review. - edit file B based on review. Run tests to make sure both CLs work together. - commit one of the CL's So the basic idea is that I have multiple changelists open simultaneously and the contents of the changelists are fluid. I can keep changing my mind about them until commit. Of course, since Perforce CL's are file-based, this all breaks down if I want overlapping uncommitted CL's. Git handles that better, which is why I'm using Git now. But I still miss the ease of use of Perforce when working on multiple CL's. Sure, the commits in Git are only local and you can always edit them until you do a push, but it seems like I have to plan ahead more and commit more often, or I end up having to split or merge CL's using commands I'm not very comfortable with.

koenigdavidmj 16y ago
Not sure if you know about Perforce's shelving feature, but it might be useful for you. Here's how it looks: 1. Hack on files 'foo' and 'bar', but instead of saying `p4 change`, say `p4 shelve`. Write down the changelist number for later; this changelist is stored on the server now. 2. `p4 revert foo bar`. You don't lose any changes; they're all on the server. 3. Hack on files 'bar' and 'baz'. Submit or shelve those changes. 4. `p4 unshelve -c (changelist number from step 1)`. (You'll probably need to resolve here.) Your original changes are back! Git certainly breaks down if you're working on one massive branch, but it's designed for lots of branching. Go ahead; we're encouraging you to branch for every new feature, every bug fix, everything. Here's the above workflow in git: 1. `git checkout -b first-change`. Hack on files 'foo' and 'bar' and commit. 2. `git checkout old-branch`, where 'old-branch' is the branch that you were on before step 1, probably 'master'. Now `git checkout -b second-change` and edit files 'bar' and 'baz'. Commit again. 3. Checkout the old branch (master, likely) again. `git merge first-change`. `git merge second-change`. Resolve if required. Test. Push changes to the remote server. Best of all, you don't need to branch before making your changes. You could actually move the `git checkout -b first-change` to after the edits on that branch, and it would still do what you want.