9 ms·

Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I

Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I find this with many programming concepts.

masklinn 8y ago
Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.
- rusk 8y ago
  Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.
  - gjm11 8y ago
    > I wonder if that's the joke. Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
  - masklinn 8y ago
    > you're stuck with it because it's great. We're stuck with it because of network effects. Git is absolutely not great.
    - JohnFen 8y ago
      I think git is great. But that might only be because all the other version control systems I've used are worse...
- Grangar 8y ago
  Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.
  - masklinn 8y ago
    > Don't use the UI. Use the CLI. I'm specifically talking about the CLI. > It sucked at first It still sucks. It'll always suck. The project is unlikely to fix any of the suck.
    - rswail 8y ago
      git aliases make it suck less :D
noname120 8y ago
Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.
- bicolao 8y ago
  This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. [1] https://github.com/git/git/blob/pu/Documentation/git-restore.txt https://github.com/git/git/blob/pu/Documentation/git-restore...
  - mleonard 8y ago
    Hi. Interesting to know thanks! Would you mind giving the current commands to achieve the three things you just listed? That way I learn the future restore command along with the current approach and you description. T
    - bicolao 8y ago
      "git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files). "git restore --worktree" is the same as "git checkout -- file". "git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files. Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)
      - mleonard 8y ago
        Thanks really very helpful! When you hoping to have git restore in the official git release?
crispyambulance 8y ago
Git is neither beautiful nor elegant. It survives because it does the job and a critical mass of people has miraculously brought it to prominence. What I will NEVER be able to understand is WHY the commands are so fucked-up, inconsistent and counter-intuitive. It doesn't have to be that way. If git feels comfortable, it's only because you've crashed and burned it so many times or suffered though countless google searches to eventually remember the commands that are appropriate for your workflow.
- sirsuki 8y ago
  The reason "the commands are so [messed]-up, inconsistent and counter-intuitive" is most likely that you expect the commands to represent your mental model of the system when in fact they represent the mental model of the system designers. I once felt it was weird till I dove in and looked at the underlying data model. Then It struck me and all the awkwardness evaporated and the commands actually make sense to me now.
  - mixmastamyk 8y ago
    > till I dove in and looked at the underlying data model. Everyone says that and I've done the same. Quickly forgotten and left with the same inscrutable commands and looking up explanations on stack overflow.
  - rstuart4133 8y ago
    > when in fact they represent the mental model of the system designers. It sure doesn't feel like that. Instead it feels rather like a lump of code I'm dealing with now. The needed to add feature X, so they did a brief look for the easiest place to bolt it on. In the code I'm dealing with now that meant y2k stuff was placed in with the tracing code, I presume because the trace headers were used everywhere y2k was needed so they didn't have to add new modules. In Git case "git reset" has so many features only tangentially related it looks to me the person adding the feature must have followed the same "I need X, I don't want to add or even think about how the CLI is structured so I'll just sneak it in with CLI command Z which looks vaguely similar". And thus we end up with the a similar mess to the code I'm dealing with. In Hg's case someone evidently put a lot of thought into the overall mental model the CLI would create, and came up with something rather neat. Sadly it doesn't always reflect how it operates underneath, so it can confuse people when things go wrong. When the abstraction created by the CLI breaks, you end up having to do what all people do abstractions leak and learn two things: both the abstraction and how it really works underneath. But Hg's CLI is so well designed casual users will never have to deal with it. In git's case the CLI bears little relationship to anything. Because nothing is where you expect nor does quite what you think it should things go wrong really quickly. That forces users to learn and think in terms of the underlying data structure which creates a lot of pain up front, but in the end you are always better off understanding things in terms of how they work underneath. The interesting thing is git is _so_ bad the official git doco has a really good section devoted to describing what is happening underneath, which makes learning it fairly straight forward. Hg doco doesn't do that. While there are some descriptions of how it works underneath it's interwoven in with the description of the CLI, so you can't just read one smallish section and get the big picture. Worse, you can never be sure whether they are describing the model presented by CLI, or what actually happens to be bits and bytes. This makes the jump to real understanding how Hg works harder than git. It's weird how things turn out. I guess which is better depends on the situation. In any case, please don't dignify git's CLI by claiming it conforms to someone's mental model. To paraphrase Linus, if it does, that someone must have been a demented ferret.
dotancohen 8y ago
> Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance This, exactly. Git was written by Linus Torvalds. You could literally replace the word "Git" in that sentence with any other software written by Linus Torvalds and it would remain just as valid. The guy writes software that has a learning curve, but does does its job elegantly. He's not writing software for the social-media-no-attention-span crowd.

masklinn 8y ago

Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.

rusk 8y ago
Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.
- gjm11 8y ago
  > I wonder if that's the joke. Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
- masklinn 8y ago
  > you're stuck with it because it's great. We're stuck with it because of network effects. Git is absolutely not great.
  - JohnFen 8y ago
    I think git is great. But that might only be because all the other version control systems I've used are worse...
Grangar 8y ago
Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.
- masklinn 8y ago
  > Don't use the UI. Use the CLI. I'm specifically talking about the CLI. > It sucked at first It still sucks. It'll always suck. The project is unlikely to fix any of the suck.
  - rswail 8y ago
    git aliases make it suck less :D

noname120 8y ago

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.

bicolao 8y ago
This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. [1] https://github.com/git/git/blob/pu/Documentation/git-restore.txt https://github.com/git/git/blob/pu/Documentation/git-restore...
- mleonard 8y ago
  Hi. Interesting to know thanks! Would you mind giving the current commands to achieve the three things you just listed? That way I learn the future restore command along with the current approach and you description. T
  - bicolao 8y ago
    "git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files). "git restore --worktree" is the same as "git checkout -- file". "git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files. Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)
    - mleonard 8y ago
      Thanks really very helpful! When you hoping to have git restore in the official git release?

crispyambulance 8y ago

Git is neither beautiful nor elegant. It survives because it does the job and a critical mass of people has miraculously brought it to prominence. What I will NEVER be able to understand is WHY the commands are so fucked-up, inconsistent and counter-intuitive. It doesn't have to be that way. If git feels comfortable, it's only because you've crashed and burned it so many times or suffered though countless google searches to eventually remember the commands that are appropriate for your workflow.

sirsuki 8y ago
The reason "the commands are so [messed]-up, inconsistent and counter-intuitive" is most likely that you expect the commands to represent your mental model of the system when in fact they represent the mental model of the system designers. I once felt it was weird till I dove in and looked at the underlying data model. Then It struck me and all the awkwardness evaporated and the commands actually make sense to me now.
- mixmastamyk 8y ago
  > till I dove in and looked at the underlying data model. Everyone says that and I've done the same. Quickly forgotten and left with the same inscrutable commands and looking up explanations on stack overflow.
- rstuart4133 8y ago
  > when in fact they represent the mental model of the system designers. It sure doesn't feel like that. Instead it feels rather like a lump of code I'm dealing with now. The needed to add feature X, so they did a brief look for the easiest place to bolt it on. In the code I'm dealing with now that meant y2k stuff was placed in with the tracing code, I presume because the trace headers were used everywhere y2k was needed so they didn't have to add new modules. In Git case "git reset" has so many features only tangentially related it looks to me the person adding the feature must have followed the same "I need X, I don't want to add or even think about how the CLI is structured so I'll just sneak it in with CLI command Z which looks vaguely similar". And thus we end up with the a similar mess to the code I'm dealing with. In Hg's case someone evidently put a lot of thought into the overall mental model the CLI would create, and came up with something rather neat. Sadly it doesn't always reflect how it operates underneath, so it can confuse people when things go wrong. When the abstraction created by the CLI breaks, you end up having to do what all people do abstractions leak and learn two things: both the abstraction and how it really works underneath. But Hg's CLI is so well designed casual users will never have to deal with it. In git's case the CLI bears little relationship to anything. Because nothing is where you expect nor does quite what you think it should things go wrong really quickly. That forces users to learn and think in terms of the underlying data structure which creates a lot of pain up front, but in the end you are always better off understanding things in terms of how they work underneath. The interesting thing is git is _so_ bad the official git doco has a really good section devoted to describing what is happening underneath, which makes learning it fairly straight forward. Hg doco doesn't do that. While there are some descriptions of how it works underneath it's interwoven in with the description of the CLI, so you can't just read one smallish section and get the big picture. Worse, you can never be sure whether they are describing the model presented by CLI, or what actually happens to be bits and bytes. This makes the jump to real understanding how Hg works harder than git. It's weird how things turn out. I guess which is better depends on the situation. In any case, please don't dignify git's CLI by claiming it conforms to someone's mental model. To paraphrase Linus, if it does, that someone must have been a demented ferret.

dotancohen 8y ago

> Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance This, exactly. Git was written by Linus Torvalds. You could literally replace the word "Git" in that sentence with any other software written by Linus Torvalds and it would remain just as valid. The guy writes software that has a learning curve, but does does its job elegantly. He's not writing software for the social-media-no-attention-span crowd.