5 ms·

> the user interface is horribly designed I see this type of remark against git quite often on HN and I think it's exaggerated. I agree some of the porcelain

by tomxor 6y ago

> the user interface is horribly designed I see this type of remark against git quite often on HN and I think it's exaggerated. I agree some of the porcelain are misleading and overloaded as convenience functions such as checkout, however a decent chunk of it is inline with the underlying data structure. Nothing is perfect, and git is pretty damn good - horribly designed? no, could do with some breaking porcelain re-writes? sure.

masklinn 6y ago
The git UI is absolutely horribly designed, as demonstrated by the mercurial or darcs UIs which, while completely different, were significantly easier to discover, intuit and remember. > git is pretty damn good UI-wise, it really is not.
- kazinator 6y ago
  The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed. That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. Finalizing the commit means moving HEAD to be the same as COMMIT_HEAD. (At that time, there is a prompt for the log message, if one hasn't been already prepared.) Your "staged" changes are then "git diff HEAD..COMMIT_HEAD", and not "git diff --cached". Speaking of which, why the hell is "cached" a synonym for "in the index"? Oh, because the index holds a full snapshot of everything. But that proliferation of terminology just adds to the confusion. I can't think of any other area of computing in which "cache" and "index" are mixed up.
  - saagarjha 6y ago
    I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.
    - cxr 6y ago
      The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.
      - phorkyas82 6y ago
        I'm generally also one of the git sceptics - Though I loved staging for a while as for the fine grained control. `git add --all` just might not do the right thing - for paranoids like me. Just recently got to know you can skip the staging by appending the paths of the changed files you want to commit after `git commit -m "awesome commit"` - neat.
        kazinator 6y ago
        You can skip the explicit staging using git commit --patch then interactively select the specific changes by diff hunk. It combines with --amend.
    - erik_seaberg 6y ago
      Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
      - kjeetgill 6y ago
        I'm trying to keep out of this fight, but how are you planning on just stashing one hunk without staging?
        erik_seaberg 6y ago
        “git stash push --patch” lets you choose hunks to copy into the new stash and clean out of the workspace. It’s pretty similar to “git add --patch” for choosing hunks to stage.
  - GeorgeTirebiter 6y ago
    Check out: https://gitless.com/ https://gitless.com/
  - icedchai 6y ago
    Git has weird terminology. Though a lot of commercial SCMs are also a bit strange. Example: Perforce which has depots and shelves. At least with git, I can create a branch without waiting 2 weeks for the IT department.
    - FartyMcFarter 6y ago
      Perforce shelves make total sense. "Shelving" something means literally what the command does - setting them aside and saving them.
      - icedchai 6y ago
        It “sort of” makes sense. When a company shelves a movie, they’re probably never finishing it. When I shelve my code, I’m probably coming back to it at some point soon. For example, I worked at a place that would have everyone “shelve” all their code before code review. In that context it didn’t make sense to me.
- wk_end 6y ago
  Single data point, but I used hg for three years at work and never warmed up to it the way I've warmed up to git (and that's the "porcelain" too, I've never done a deep dive into the plumbing).
kazinator 6y ago
> I see this type of remark against git quite often on HN and I think it's exaggerated. Indeed, in more erudite forums with smarter users, more level-headed, less biased opinions of git circulate.

by tomxor 6y ago

masklinn 6y ago

The git UI is absolutely horribly designed, as demonstrated by the mercurial or darcs UIs which, while completely different, were significantly easier to discover, intuit and remember. > git is pretty damn good UI-wise, it really is not.

kazinator 6y ago
The concept of the git staging area is utterly superfluous. All local changes that are propagated to the version control system should go directly into a durable commit object, and not to a pseudo-commit object that isn't a commit, and that can be casually trashed. That commit object could be pointed at by a separate COMMIT_HEAD pointer. If you have a COMMIT_HEAD different from HEAD, then you have a commit brewing. Finalizing the commit means moving HEAD to be the same as COMMIT_HEAD. (At that time, there is a prompt for the log message, if one hasn't been already prepared.) Your "staged" changes are then "git diff HEAD..COMMIT_HEAD", and not "git diff --cached". Speaking of which, why the hell is "cached" a synonym for "in the index"? Oh, because the index holds a full snapshot of everything. But that proliferation of terminology just adds to the confusion. I can't think of any other area of computing in which "cache" and "index" are mixed up.
- saagarjha 6y ago
  I like the staging area, though–at any given time I always have code that I do not want to put in a commit object (perhaps I changed some build flags, or my IDE touched some files I don't care for, or…) However, I do agree 100% that all the terminology is pretty bad.
  - cxr 6y ago
    The sin of Git's staging area is that Git forces it into the default interaction path—requiring you to take it into consideration whether or not you're interested in only committing some of the changes. Git should default to including all changes, and iff you direct it to (i.e. by explicitly specifying `git add`) should you have to take into consideration the notion that some changes are staged and others aren't.
    - phorkyas82 6y ago
      I'm generally also one of the git sceptics - Though I loved staging for a while as for the fine grained control. `git add --all` just might not do the right thing - for paranoids like me. Just recently got to know you can skip the staging by appending the paths of the changed files you want to commit after `git commit -m "awesome commit"` - neat.
      - kazinator 6y ago
        You can skip the explicit staging using git commit --patch then interactively select the specific changes by diff hunk. It combines with --amend.
  - erik_seaberg 6y ago
    Only the workspace can be built and tested, so the workspace is what should be committed. We should be stashing anything we don't want to test and commit yet.
    - kjeetgill 6y ago
      I'm trying to keep out of this fight, but how are you planning on just stashing one hunk without staging?
      - erik_seaberg 6y ago
        “git stash push --patch” lets you choose hunks to copy into the new stash and clean out of the workspace. It’s pretty similar to “git add --patch” for choosing hunks to stage.
- GeorgeTirebiter 6y ago
  Check out: https://gitless.com/ https://gitless.com/
- icedchai 6y ago
  Git has weird terminology. Though a lot of commercial SCMs are also a bit strange. Example: Perforce which has depots and shelves. At least with git, I can create a branch without waiting 2 weeks for the IT department.
  - FartyMcFarter 6y ago
    Perforce shelves make total sense. "Shelving" something means literally what the command does - setting them aside and saving them.
    - icedchai 6y ago
      It “sort of” makes sense. When a company shelves a movie, they’re probably never finishing it. When I shelve my code, I’m probably coming back to it at some point soon. For example, I worked at a place that would have everyone “shelve” all their code before code review. In that context it didn’t make sense to me.
wk_end 6y ago
Single data point, but I used hg for three years at work and never warmed up to it the way I've warmed up to git (and that's the "porcelain" too, I've never done a deep dive into the plumbing).

kazinator 6y ago

> I see this type of remark against git quite often on HN and I think it's exaggerated. Indeed, in more erudite forums with smarter users, more level-headed, less biased opinions of git circulate.