12 ms·

Git making me want to pull my hair out yet again

32 points by vanilla-almond 4y ago

keikobadthebad 4y ago
Can't be he's using it wrong.
- peteradio 4y ago
  No kidding, what exactly is problem? Probably merge conflicts on binary blobs or some stupid shit. Clunky, it is not. What was this guy using before? SVN!? That shit was go get a coffee or lunch slow.
  - pxmpxm 4y ago
    > Clunky, it is not. I want to roll back an accidental commit of an extra file to the previous, uncommitted state. Or even simpler, undo a commit to restore the exact state just before it happened.
    - alrlroipsp 4y ago
      git reset --soft HEAD~1 git status ..remove files that was to be commited.. git commit -m "previous message"
      - pxmpxm 4y ago
        Uh huh, now imagine you've built something with usage in mind, rather than a hodgepodge of leaky abstractions for what's happening behind the scenes: git undo git undo file
        RHSeeger 4y ago
        This right there is the what gives me pause. Every time I need to do something out of the box, I need to start googling. Rather than there being an easy to remember command to do it, one that has a good name that indicates what it does; or, more specifically, what one uses it to accomplish. It's like naming a field "list" in code; I know it's a list... but name it so I know what is in it or what it's for. And to add to the fun, there's multiple other answers in this thread on how to accomplish the same task.
        iam-TJ 4y ago
        git reset --soft HEAD^ # make changes so index only contains what you want git commit -a -C ORIG_HEAD of if you prefer: git config --global alias.undo reset --soft HEAD^ git config --global alias.redo commit -a -C ORIG_HEAD then: git undo # make changes so index only contains what you want git redo You could use -c (--reedit-message=) instead of -C (--reuse-message=) for further flexibility. ORIG_HEAD is set to point to the most recent HEAD when using reset. See "man git-reset" > EXAMPLES > "Undo a commit and redo".
    - peteradio 4y ago
      git checkout prior_commit_hash "file_path"
      - WillDaSilva 4y ago
        Likely followed by git commit --amend
    - eurasiantiger 4y ago
      > undo a commit git reset --hard HEAD^ Which makes perfect sense once you know that you are not ”undoing a commit” inasmuch as you are resetting the most recent state of an index to the second most previous one. Just make an alias for it if it bothers you, that’s what is generally recommended by unix beards for hard to remember but oft-used commands anyway.
      - pxmpxm 4y ago
        >once you know that you are not Making my point for me - the usage is "undo a commit" or "undo a file accidentally added to a commit", what you mentioned are implementation details that are leaking up to the interface. If I'm doing cp file newFile, I don't need to know anything about ext3, APFS or anything about hard drives to operate on files.
        Brian_K_White 4y ago
        Isn't "undo" too ambiguous to be useful? Or do you imagine it as a subcommand with further parameters to describe what to undo and how? I think a term like undo is a mistake if you think of the git history like accounting. There is, or there should be, no such thing as undo the way an unsophisticated layperson imagines they want. Instead undos are just changes like any other changes. You don't fix entry errors by actually editing history, you make a new entry that both reverses the error and explains why. If that leads to having to think about some problems a bit non-intuitively, I'm pretty tempted to just say tough shit, it's worse to try to simplify something if simpler really only means wrong and incomplete. Perhaps undo was just a bad example of a git failing. There certainly are commands that could be more scrutable without becoming incomplete or wrong. But I only see it as an unavoidable process of development. It's not possible for anything to spring forth fully baked, and so it's pointless and wrong to complain that it didn't happen. So the crappiness of the early versions (of whatever, in general, not git in particular) is not damning and nothing else can ever be any different. Then the next, almost as unavoidable, at least certainly natural and typical, is that the process of imporoving necessarily means changing, and that leads to both redundancy and inconsistency. 4 different ways to do something because there is the old way and the next way and the next way... I see only that git could improve some things in only the way is unavoidable and applies to everything everywhere, and is not a special git failing but simply life, and that most of the perceived complexity of git comes straight from the underlying job we need it to do. It may not be logically possible to have a fundamentally simple tool to do this complex job, only a simple tool that only actually does a simple job, which isn't good enough. The best I even consider to wish for is just improvement over time figuring out more consistent interfaces and improving the predictability so that you can be more confident in understanding "when I say X, what will actially happen?".
    - throw_nbvc1234 4y ago
      git reflog --help Probably not what you want to use day to day but if you want to undo things i find reflogs better then commits for tricky situations.
    - phone_book 4y ago
      I love how this got 4 different answers.
      - pxmpxm 4y ago
        The question was intentionally crafted for that effect :)
      - peteradio 4y ago
        2 answers the same and rolling back all files. 1 answer for rolling back single file. 1 non-solution. The OP has a poorly defined use case for "undo" (which commit? all files or one?) and can easily wrap whichever suits their need in an alias.
  - UncleMeat 4y ago
    Git was designed for a fully distributed open source environment where there is no canonical head and no continuous access to a source repository. It makes sense for the way that linux is developed. It makes less sense for the way that most corporate development is done. Yes, SVN is worse. That doesn't mean that git has flaws in its most common deployment.
tonetheman 4y ago
He is not wrong.
mytailorisrich 4y ago
Git is a big step up from older code versions management tools and there is nothing particularly bad or difficult about its interface so I don't get the hate. I suppose that once you become the standard you become a target as Microsoft knows very well.
lawgimenez 4y ago
I have been using git for almost a decade, I don’t see any issues and I enjoy it quite a lot. Is there something I am not aware of?
- pxmpxm 4y ago
  - eurasiantiger 4y ago
    I would like to know what your specific issues with git have been. Certainly they must to be substantial and well documented to warrant expressing such an arrogant opinion.
- danielEM 4y ago
  I think it's biggest problem is that it is not intuitive at all for people who use it for not a long of time. (and I'm saying it as someone using git for more then 10 years :))
- throwaway_au_1 4y ago
  Another fan here. I am a terminal user so Git is 100% CLI for me. Maybe this has helped me learn it to a level where I feel confident with it. I was the sole Git CLI user in my longest role and I tended to be the 'git fixer'. I agree it has sharp edges (like a lot of things, though) but I'm happy to be adept at something powerful and useful. It's a transferrable tool across pretty much all stacks so it doesn't feel like a pointless investment.
- yucky 4y ago
  Let's say hypothetically you were teaching git to a group of 30 high schoolers. 25 of them struggle to grasp beyond a few commands and 5 of them do ok with it. As king for a day, what would you do to simplify git so that as many of those 25 kids as possible could become proficient with version control? Or would you just push forward with the 5 kids and tell the other 25 to find a different path in life?
anshumankmr 4y ago
I have been using Git since college and for a few years since I began my job, can't say I have had any problem that I couldn't find a solution for oneline. Plus, I use Github Desktop now, so I do not have to worry about the pesky commands as much as I would have earlier.
- alkonaut 4y ago
  > any problem that I couldn't find a solution for oneline. That could still be the pulling my hair situation he mentions. Having too Google or even being up a documentation is a failure for a tool like this. When I argue that git is bad it’s “unintuitive” I mean. I have to RTFM after years of use. I does the job but it’s a shit UX. It’s like getting in your car and having to Google how to put it in reverse, for the 10th time, after driving it for 10years.
  - anshumankmr 4y ago
    Yes, I see. I don't mind doing it, cause anyway I google the solution to a bunch of problems I face at work every other day. My tolerance for Googling solutions would is very high. But it might not be the same for him, I suppose. And it would definitely vary from person to person..
- saghm 4y ago
  > I have been using Git since college and for a few years since I began my job, can't say I have had any problem that I couldn't find a solution for oneline I agree with this, but I don't think that's strong enough evidence to conclude that git's interface isn't clunky. Being able to find solutions online is worse than being able to figure them out on my own, and being able to figure them out on my own is worse than just not having them. Obviously no software will ever be free from issues, and most can have some sort of issue that isn't able to be figured out without searching online, but I'm not convinced that git does a particularly good job about minimizing the potential for these types of issues. Overall, I've learned to use git effectively for my work, and I've often helped teammates when they run into a git issue they don't understand, but this is mostly due to the fact that I've run into issues enough before to know how to avoid some of the pitfalls.
urthor 4y ago
"Git making me want to pull my hair out yet again. One of the most unintuitive, clunky interfaces of any software I've ever used." Emphasis mine. The link has a bad title. The CTO's problem isn't Git. It's the design of the Git CLI commands. Which, to be frank, I think is pretty reasonable. Git as a version control system is great, but it desperately needs an "apt style" revamp.
- RHSeeger 4y ago
  The problem I've seen is that there's two groups of people that are generally involved in a conversation like this 1. The group of people that think git is powerful, but the CLI makes it difficult to do anything that is even slightly outside the box (which, for example, makes fixing a mistake difficult). 2. The group of people that think git is powerful, and the CLI is easy to use, and refuse to acknowledge that it's difficult for some people; rather, they blame the people for being wrong. I've been using git for 10+ years and I fall into the second group. Every time I get into a situation the isn't the normal workflow, I have to google how to fix it. And I need to check and double check what I'm doing because, if I do it wrong, I need to reclone the entire repo to undo my mistake (and heaven forbid I'm trying to correct something on the origin). I get it, my git skills are not good enough... but by this point they _should_ be, just by using the tool. The fact that they aren't says something bad about the tool. And that being said, the people in the second group will still say that git is fine, and it must be a problem with me. Admittedly, I'm not perfect, but neither am I incompetent. It shouldn't require a decade plus (and lots of dedicate study) of use to become proficient with a tool.
  - TrueSlacker0 4y ago
    What about the third group who don't want to touch a cli? Who want to push a button on a gui and call it a day.
    - RHSeeger 4y ago
      I actually meant to include a note at the end... - There's no group I've seen of that say git isn't powerful - The group that doesn't want to use a CLI at all doesn't generally participate in this conversation (about the CLI), because they'd rather see a visual tool build on top of it that. (I know a lot of people in this group; I'm not, but I respect where they're coming from)
tex0 4y ago
He's so right about this. git is terrible. I hope some day we see a successful successor.
Gumbercules 4y ago
I'm not saying Git isn't complex, but this is the same guy everyone was lauding a couple of weeks ago for saying C/C++ should be deprecated in favor of Rust. Git is fine and so are C/C++ thank you.
snicker7 4y ago
“CTO of Azure not using Magit”
- rollcat 4y ago
  Came here to praise Magit. Even if you don't know Emacs, Magit is worth learning (and not entirely "emacsey", has its own interaction paradigms). Even if you don't plan on sticking with Magit for longer, it will illuminate your path towards better understanding of Git itself. The only danger is it will spoil you.
- yaantc 4y ago
  Yes, Magit solves the two main issues I had with git and made me avoid it for a while. It provides: 1) A simple interface, with good discoverability (options and functions shown); 2) Good visualization and operations on the current state, with work tree and index, in a simple and intuitive way. People often complain about the CLI interface, but for me (2) is also important. Having a compact, simple representation of what's changed in the work tree and index, and easy manipulation, is important to reduce the cognitive load. No need to keep track of this in your head, just look at the Magit status window.
leephillips 4y ago
I guess the problem is people diving in to daily use of git without first educating themselves about how it works. In fact git is elegant and wonderfully designed, which makes it easy to use. It’s hard not to descend into a bit of snarkiness and say it's less than astonishing to see this from a Microsoft guy.
tananaev 4y ago
Wonder what he worked with before that was better. Maybe Visual SourceSafe? :)
- mikro2nd 4y ago
  Mercurial
- born2web 4y ago
  There is (was?) an internal (MSFT) system named Source Depot (sd). It may even be the case that he created it...
devmor 4y ago
I've been using git professionally for about 11 years. I've taught entire teams to use git. I don't disagree with him. Git isn't user friendly and its non obvious how to do a lot of things you'd expect to be trivial in your workflow.
alkonaut 4y ago
It is unintuitive and crappy in places (anyone who claims otherwise is out of their mind). No one, I repeat no one, wants to consider VCS operations as graph operations. We endure it because it gets the job done. The fact that “mine” and “theirs” is reversed for merge and rebase doesn’t even make sense after the explanation is made. There are dozens of examples like this. And the worst wart of all in my opinion is that it’s designed around posix, even “mostly” expecting to be run in a posix shell. I guess I can forgive that (seeing as it was created by a Linux person) but I’m not interested in running git-bash or similar on windows, meaning it’s a pretty degraded experience. Making aliases under windows cmd/PS is… interesting. Git served us well but I hope it is soon displaced by something else. We can do better.
- davidguetta 4y ago
  Ive been using git for 5 years now and i feel ive been using like the same 5 6 commands all the time. I dont understand these debates. Why would you need more ? Even when merge and rebase are getting out of hands, just take a good breath and use a bunch of manual cherrypicks.
  - Ekaros 4y ago
    Perfectly fine when you are at clone, pull, push, add and commit level. Even stash isn't bad. But then you make mistake and need to figure out how to fix something even worse if stuff goes to remote...
    - ostenning 4y ago
      It shouldn't be easy to rewrite history but it should be easy to change the email of the author retroactively
  - mrits 4y ago
    You just need a single person on the team to learn the other commands. If you are good at fixing bad merges make sure you don't let anyone know.
BiteCode_dev 4y ago
After a decade of having to craft precisely my commits, manually syncing, choosing between easy merge and clean history, and using tons of additional tools to make git bearable, I'm finally tired enough to give a try to fossil.
helloguillecl 4y ago
The CLI interface is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). This allows for the user to draw an accurate user-model in his understanding of the system. I have been using Git for around 15 years, without a fuss. Maybe because I was lucky enough to have found a good tutorial. Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API. Not even the multiple GUIs built on top of Git, adventure themselves into hiding or dumbing down the abstractions that allow you to do quite complex things with the code and its history.
- vq 4y ago
  I'm closing in on 15 years of git usage as well. Before that for a short period I really wanted to get into darcs, the first DVCS I used. I was constantly confused about what commands to use to rectify the off-the-happy-path situations that you find yourself in every now and then. The UI might have been better than git's in a lot of ways but it was distinctly higher-level. When I learned git and understood the underlying model I had far fewer problems. The commands of early git could have been designed better, but they were more transparent in what they did. The thought haven't struck me before, but maybe one of the great things about git is that even the low-level/plumbing commands (cat-files/ls-tree/show-ref) have well written man pages.
belltaco 4y ago
Why not just say "Mark Russinovich" instead of the current title? Unless there's some agenda behind it. Mark is pretty famous among tech circles.
jmclnx 4y ago
Windows GUI people dislike Git, news at 11:) I have gotten used to git, and it is fine, I do like gnupg signing on commits. The only thing I miss is "$Id$" that CVS/RCS would update with the rev. I could then print out the rev so I could see what version of the object is on one of the many servers at work. I wish git has something similar.
- BiteCode_dev 4y ago
  I'm very much a linux guy, I'm even teaching git. I hate it. I'm glad it exists. It helps me more than not having it. But it forces me to think about the tool instead of the task I'm trying to solve.
jhnnygrn 4y ago
this is nothing more than a shot across the bow. you can't build an argument for why everyone should move away from git, unless you can point back to a tweet from a few years ago that you can say "i've been saying this for years" about. what better way to get an entire industry to move to your product, than to acquire its main "hub" and then replace the underlying tech. customer adoption strategy at its finest. as they have sunset atom ... next they'll sunset vs code and make you use straight up vs ... and they'll sunset typescript ... because ... this is conceptually just c# nowdays.
pjmlp 4y ago
TortoiseGit + IDE tooling, CLI only for edge cases not taken by the IDE, when the repo gets borked, rename it, git clone, copy the latest changes on the freshly cloned repo. No need to care more than that, I never needed a PhD in SCM systems since the RCS days and ain't starting now.
ianbutler 4y ago
We can do better with version control for sure. Git hands down, even for some experienced developers, causes consternation whenever you have to go off the beaten path. Committing, merging, rebasing (in the happy path) and a few others are not so bad. Everything else starts getting more difficult, especially because the mental model of git is not intuitive. I don't personally run into problems, but I've sure seen many, many other people struggle learning and using the git cli.
dqpb 4y ago
Whenever I hear someone making a broad hyperbolic politic rant about a technology which is otherwise used successfully by hundreds of thousands of people, I like to ask - what specifically is the problem you're running into? Usually it reveals a lot more about the person than the technology.
kreetx 4y ago
So many tweets with no report of the problem at hand.
nunez 4y ago
While I can navigate the Git CLI really easily these days, I don't disagree with Mark. Outside of the big four ("git clone", "git rebase", "git commit", "git push"), you're almost certainly engaging in some serious black magic fuckery. Hell, even "git rebase" straddles the fuckery border, especially when you're doing fix-up commits between commits. If Git makes Russinovich want to shoot his computer, then a revamp of the CLI is _definitely_ in order. Won't be surprised if GitHub goes for it by extending their awesome `gh` tool.
1letterunixname 4y ago
I work at a megacorp. We asked to pay Git folks to support monorepo sparse checkouts. They refused. Lo and behold Microsoft enters the ring, hires a Git committer to do it, and now it has it. Instead, we forked Mercurial, and got rid of staging and branching. Straight-line development is the way to go for most monorepos. Feature branches create a big mess. You also need sparse file systems for large mono repos otherwise the storage and network requirements exceed what is reasonable. In addition, it's imperative pushes default to running server-side sanity lints (with break-glass bypass) before accepting commits. This means either disallow pushes to production repos with a CI/CD stage + code review in-between or have some sort of proof-of-work hooks that accept local testing results. GPG has the same problem: powerful but the UX is a hot mess.
TheChaplain 4y ago
I had a couple of colleagues complaining about Git, so I asked what was the problem. "Hard to use", "commands doesn't makes sense" was among the answers. Two hours on a whiteboard explaining how Git works in a little more detail and now the complaints are gone. The gist of my anecdote is; learn your tools properly, not only does it save you headache but also makes you more productive. (It's a bit dated, but Pro Git by Strauss is an good book to get a better understanding of Git)

keikobadthebad 4y ago

Can't be he's using it wrong.

peteradio 4y ago
No kidding, what exactly is problem? Probably merge conflicts on binary blobs or some stupid shit. Clunky, it is not. What was this guy using before? SVN!? That shit was go get a coffee or lunch slow.
- pxmpxm 4y ago
  > Clunky, it is not. I want to roll back an accidental commit of an extra file to the previous, uncommitted state. Or even simpler, undo a commit to restore the exact state just before it happened.
  - alrlroipsp 4y ago
    git reset --soft HEAD~1 git status ..remove files that was to be commited.. git commit -m "previous message"
    - pxmpxm 4y ago
      Uh huh, now imagine you've built something with usage in mind, rather than a hodgepodge of leaky abstractions for what's happening behind the scenes: git undo git undo file
      - RHSeeger 4y ago
        This right there is the what gives me pause. Every time I need to do something out of the box, I need to start googling. Rather than there being an easy to remember command to do it, one that has a good name that indicates what it does; or, more specifically, what one uses it to accomplish. It's like naming a field "list" in code; I know it's a list... but name it so I know what is in it or what it's for. And to add to the fun, there's multiple other answers in this thread on how to accomplish the same task.
      - iam-TJ 4y ago
        git reset --soft HEAD^ # make changes so index only contains what you want git commit -a -C ORIG_HEAD of if you prefer: git config --global alias.undo reset --soft HEAD^ git config --global alias.redo commit -a -C ORIG_HEAD then: git undo # make changes so index only contains what you want git redo You could use -c (--reedit-message=) instead of -C (--reuse-message=) for further flexibility. ORIG_HEAD is set to point to the most recent HEAD when using reset. See "man git-reset" > EXAMPLES > "Undo a commit and redo".
  - peteradio 4y ago
    git checkout prior_commit_hash "file_path"
    - WillDaSilva 4y ago
      Likely followed by git commit --amend
  - eurasiantiger 4y ago
    > undo a commit git reset --hard HEAD^ Which makes perfect sense once you know that you are not ”undoing a commit” inasmuch as you are resetting the most recent state of an index to the second most previous one. Just make an alias for it if it bothers you, that’s what is generally recommended by unix beards for hard to remember but oft-used commands anyway.
    - pxmpxm 4y ago
      >once you know that you are not Making my point for me - the usage is "undo a commit" or "undo a file accidentally added to a commit", what you mentioned are implementation details that are leaking up to the interface. If I'm doing cp file newFile, I don't need to know anything about ext3, APFS or anything about hard drives to operate on files.
      - Brian_K_White 4y ago
        Isn't "undo" too ambiguous to be useful? Or do you imagine it as a subcommand with further parameters to describe what to undo and how? I think a term like undo is a mistake if you think of the git history like accounting. There is, or there should be, no such thing as undo the way an unsophisticated layperson imagines they want. Instead undos are just changes like any other changes. You don't fix entry errors by actually editing history, you make a new entry that both reverses the error and explains why. If that leads to having to think about some problems a bit non-intuitively, I'm pretty tempted to just say tough shit, it's worse to try to simplify something if simpler really only means wrong and incomplete. Perhaps undo was just a bad example of a git failing. There certainly are commands that could be more scrutable without becoming incomplete or wrong. But I only see it as an unavoidable process of development. It's not possible for anything to spring forth fully baked, and so it's pointless and wrong to complain that it didn't happen. So the crappiness of the early versions (of whatever, in general, not git in particular) is not damning and nothing else can ever be any different. Then the next, almost as unavoidable, at least certainly natural and typical, is that the process of imporoving necessarily means changing, and that leads to both redundancy and inconsistency. 4 different ways to do something because there is the old way and the next way and the next way... I see only that git could improve some things in only the way is unavoidable and applies to everything everywhere, and is not a special git failing but simply life, and that most of the perceived complexity of git comes straight from the underlying job we need it to do. It may not be logically possible to have a fundamentally simple tool to do this complex job, only a simple tool that only actually does a simple job, which isn't good enough. The best I even consider to wish for is just improvement over time figuring out more consistent interfaces and improving the predictability so that you can be more confident in understanding "when I say X, what will actially happen?".
  - throw_nbvc1234 4y ago
    git reflog --help Probably not what you want to use day to day but if you want to undo things i find reflogs better then commits for tricky situations.
  - phone_book 4y ago
    I love how this got 4 different answers.
    - pxmpxm 4y ago
      The question was intentionally crafted for that effect :)
    - peteradio 4y ago
      2 answers the same and rolling back all files. 1 answer for rolling back single file. 1 non-solution. The OP has a poorly defined use case for "undo" (which commit? all files or one?) and can easily wrap whichever suits their need in an alias.
- UncleMeat 4y ago
  Git was designed for a fully distributed open source environment where there is no canonical head and no continuous access to a source repository. It makes sense for the way that linux is developed. It makes less sense for the way that most corporate development is done. Yes, SVN is worse. That doesn't mean that git has flaws in its most common deployment.

tonetheman 4y ago

He is not wrong.

mytailorisrich 4y ago

Git is a big step up from older code versions management tools and there is nothing particularly bad or difficult about its interface so I don't get the hate. I suppose that once you become the standard you become a target as Microsoft knows very well.

lawgimenez 4y ago

I have been using git for almost a decade, I don’t see any issues and I enjoy it quite a lot. Is there something I am not aware of?

pxmpxm 4y ago
- eurasiantiger 4y ago
  I would like to know what your specific issues with git have been. Certainly they must to be substantial and well documented to warrant expressing such an arrogant opinion.
danielEM 4y ago
I think it's biggest problem is that it is not intuitive at all for people who use it for not a long of time. (and I'm saying it as someone using git for more then 10 years :))
throwaway_au_1 4y ago
Another fan here. I am a terminal user so Git is 100% CLI for me. Maybe this has helped me learn it to a level where I feel confident with it. I was the sole Git CLI user in my longest role and I tended to be the 'git fixer'. I agree it has sharp edges (like a lot of things, though) but I'm happy to be adept at something powerful and useful. It's a transferrable tool across pretty much all stacks so it doesn't feel like a pointless investment.
yucky 4y ago
Let's say hypothetically you were teaching git to a group of 30 high schoolers. 25 of them struggle to grasp beyond a few commands and 5 of them do ok with it. As king for a day, what would you do to simplify git so that as many of those 25 kids as possible could become proficient with version control? Or would you just push forward with the 5 kids and tell the other 25 to find a different path in life?

anshumankmr 4y ago

I have been using Git since college and for a few years since I began my job, can't say I have had any problem that I couldn't find a solution for oneline. Plus, I use Github Desktop now, so I do not have to worry about the pesky commands as much as I would have earlier.

alkonaut 4y ago
> any problem that I couldn't find a solution for oneline. That could still be the pulling my hair situation he mentions. Having too Google or even being up a documentation is a failure for a tool like this. When I argue that git is bad it’s “unintuitive” I mean. I have to RTFM after years of use. I does the job but it’s a shit UX. It’s like getting in your car and having to Google how to put it in reverse, for the 10th time, after driving it for 10years.
- anshumankmr 4y ago
  Yes, I see. I don't mind doing it, cause anyway I google the solution to a bunch of problems I face at work every other day. My tolerance for Googling solutions would is very high. But it might not be the same for him, I suppose. And it would definitely vary from person to person..
saghm 4y ago
> I have been using Git since college and for a few years since I began my job, can't say I have had any problem that I couldn't find a solution for oneline I agree with this, but I don't think that's strong enough evidence to conclude that git's interface isn't clunky. Being able to find solutions online is worse than being able to figure them out on my own, and being able to figure them out on my own is worse than just not having them. Obviously no software will ever be free from issues, and most can have some sort of issue that isn't able to be figured out without searching online, but I'm not convinced that git does a particularly good job about minimizing the potential for these types of issues. Overall, I've learned to use git effectively for my work, and I've often helped teammates when they run into a git issue they don't understand, but this is mostly due to the fact that I've run into issues enough before to know how to avoid some of the pitfalls.

urthor 4y ago

"Git making me want to pull my hair out yet again. One of the most unintuitive, clunky interfaces of any software I've ever used." Emphasis mine. The link has a bad title. The CTO's problem isn't Git. It's the design of the Git CLI commands. Which, to be frank, I think is pretty reasonable. Git as a version control system is great, but it desperately needs an "apt style" revamp.

RHSeeger 4y ago
The problem I've seen is that there's two groups of people that are generally involved in a conversation like this 1. The group of people that think git is powerful, but the CLI makes it difficult to do anything that is even slightly outside the box (which, for example, makes fixing a mistake difficult). 2. The group of people that think git is powerful, and the CLI is easy to use, and refuse to acknowledge that it's difficult for some people; rather, they blame the people for being wrong. I've been using git for 10+ years and I fall into the second group. Every time I get into a situation the isn't the normal workflow, I have to google how to fix it. And I need to check and double check what I'm doing because, if I do it wrong, I need to reclone the entire repo to undo my mistake (and heaven forbid I'm trying to correct something on the origin). I get it, my git skills are not good enough... but by this point they _should_ be, just by using the tool. The fact that they aren't says something bad about the tool. And that being said, the people in the second group will still say that git is fine, and it must be a problem with me. Admittedly, I'm not perfect, but neither am I incompetent. It shouldn't require a decade plus (and lots of dedicate study) of use to become proficient with a tool.
- TrueSlacker0 4y ago
  What about the third group who don't want to touch a cli? Who want to push a button on a gui and call it a day.
  - RHSeeger 4y ago
    I actually meant to include a note at the end... - There's no group I've seen of that say git isn't powerful - The group that doesn't want to use a CLI at all doesn't generally participate in this conversation (about the CLI), because they'd rather see a visual tool build on top of it that. (I know a lot of people in this group; I'm not, but I respect where they're coming from)

tex0 4y ago

He's so right about this. git is terrible. I hope some day we see a successful successor.

Gumbercules 4y ago

I'm not saying Git isn't complex, but this is the same guy everyone was lauding a couple of weeks ago for saying C/C++ should be deprecated in favor of Rust. Git is fine and so are C/C++ thank you.

snicker7 4y ago

“CTO of Azure not using Magit”

rollcat 4y ago
Came here to praise Magit. Even if you don't know Emacs, Magit is worth learning (and not entirely "emacsey", has its own interaction paradigms). Even if you don't plan on sticking with Magit for longer, it will illuminate your path towards better understanding of Git itself. The only danger is it will spoil you.
yaantc 4y ago
Yes, Magit solves the two main issues I had with git and made me avoid it for a while. It provides: 1) A simple interface, with good discoverability (options and functions shown); 2) Good visualization and operations on the current state, with work tree and index, in a simple and intuitive way. People often complain about the CLI interface, but for me (2) is also important. Having a compact, simple representation of what's changed in the work tree and index, and easy manipulation, is important to reduce the cognitive load. No need to keep track of this in your head, just look at the Magit status window.

leephillips 4y ago

I guess the problem is people diving in to daily use of git without first educating themselves about how it works. In fact git is elegant and wonderfully designed, which makes it easy to use. It’s hard not to descend into a bit of snarkiness and say it's less than astonishing to see this from a Microsoft guy.

tananaev 4y ago

Wonder what he worked with before that was better. Maybe Visual SourceSafe? :)

mikro2nd 4y ago
Mercurial
born2web 4y ago
There is (was?) an internal (MSFT) system named Source Depot (sd). It may even be the case that he created it...

devmor 4y ago

I've been using git professionally for about 11 years. I've taught entire teams to use git. I don't disagree with him. Git isn't user friendly and its non obvious how to do a lot of things you'd expect to be trivial in your workflow.

alkonaut 4y ago

It is unintuitive and crappy in places (anyone who claims otherwise is out of their mind). No one, I repeat no one, wants to consider VCS operations as graph operations. We endure it because it gets the job done. The fact that “mine” and “theirs” is reversed for merge and rebase doesn’t even make sense after the explanation is made. There are dozens of examples like this. And the worst wart of all in my opinion is that it’s designed around posix, even “mostly” expecting to be run in a posix shell. I guess I can forgive that (seeing as it was created by a Linux person) but I’m not interested in running git-bash or similar on windows, meaning it’s a pretty degraded experience. Making aliases under windows cmd/PS is… interesting. Git served us well but I hope it is soon displaced by something else. We can do better.

davidguetta 4y ago
Ive been using git for 5 years now and i feel ive been using like the same 5 6 commands all the time. I dont understand these debates. Why would you need more ? Even when merge and rebase are getting out of hands, just take a good breath and use a bunch of manual cherrypicks.
- Ekaros 4y ago
  Perfectly fine when you are at clone, pull, push, add and commit level. Even stash isn't bad. But then you make mistake and need to figure out how to fix something even worse if stuff goes to remote...
  - ostenning 4y ago
    It shouldn't be easy to rewrite history but it should be easy to change the email of the author retroactively
- mrits 4y ago
  You just need a single person on the team to learn the other commands. If you are good at fixing bad merges make sure you don't let anyone know.

BiteCode_dev 4y ago

After a decade of having to craft precisely my commits, manually syncing, choosing between easy merge and clean history, and using tons of additional tools to make git bearable, I'm finally tired enough to give a try to fossil.

helloguillecl 4y ago

The CLI interface is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). This allows for the user to draw an accurate user-model in his understanding of the system. I have been using Git for around 15 years, without a fuss. Maybe because I was lucky enough to have found a good tutorial. Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API. Not even the multiple GUIs built on top of Git, adventure themselves into hiding or dumbing down the abstractions that allow you to do quite complex things with the code and its history.

vq 4y ago
I'm closing in on 15 years of git usage as well. Before that for a short period I really wanted to get into darcs, the first DVCS I used. I was constantly confused about what commands to use to rectify the off-the-happy-path situations that you find yourself in every now and then. The UI might have been better than git's in a lot of ways but it was distinctly higher-level. When I learned git and understood the underlying model I had far fewer problems. The commands of early git could have been designed better, but they were more transparent in what they did. The thought haven't struck me before, but maybe one of the great things about git is that even the low-level/plumbing commands (cat-files/ls-tree/show-ref) have well written man pages.

belltaco 4y ago

Why not just say "Mark Russinovich" instead of the current title? Unless there's some agenda behind it. Mark is pretty famous among tech circles.

jmclnx 4y ago

Windows GUI people dislike Git, news at 11:) I have gotten used to git, and it is fine, I do like gnupg signing on commits. The only thing I miss is "$Id$" that CVS/RCS would update with the rev. I could then print out the rev so I could see what version of the object is on one of the many servers at work. I wish git has something similar.

BiteCode_dev 4y ago
I'm very much a linux guy, I'm even teaching git. I hate it. I'm glad it exists. It helps me more than not having it. But it forces me to think about the tool instead of the task I'm trying to solve.

jhnnygrn 4y ago

this is nothing more than a shot across the bow. you can't build an argument for why everyone should move away from git, unless you can point back to a tweet from a few years ago that you can say "i've been saying this for years" about. what better way to get an entire industry to move to your product, than to acquire its main "hub" and then replace the underlying tech. customer adoption strategy at its finest. as they have sunset atom ... next they'll sunset vs code and make you use straight up vs ... and they'll sunset typescript ... because ... this is conceptually just c# nowdays.

pjmlp 4y ago

TortoiseGit + IDE tooling, CLI only for edge cases not taken by the IDE, when the repo gets borked, rename it, git clone, copy the latest changes on the freshly cloned repo. No need to care more than that, I never needed a PhD in SCM systems since the RCS days and ain't starting now.

ianbutler 4y ago

We can do better with version control for sure. Git hands down, even for some experienced developers, causes consternation whenever you have to go off the beaten path. Committing, merging, rebasing (in the happy path) and a few others are not so bad. Everything else starts getting more difficult, especially because the mental model of git is not intuitive. I don't personally run into problems, but I've sure seen many, many other people struggle learning and using the git cli.

dqpb 4y ago

Whenever I hear someone making a broad hyperbolic politic rant about a technology which is otherwise used successfully by hundreds of thousands of people, I like to ask - what specifically is the problem you're running into? Usually it reveals a lot more about the person than the technology.

kreetx 4y ago

So many tweets with no report of the problem at hand.

nunez 4y ago

While I can navigate the Git CLI really easily these days, I don't disagree with Mark. Outside of the big four ("git clone", "git rebase", "git commit", "git push"), you're almost certainly engaging in some serious black magic fuckery. Hell, even "git rebase" straddles the fuckery border, especially when you're doing fix-up commits between commits. If Git makes Russinovich want to shoot his computer, then a revamp of the CLI is _definitely_ in order. Won't be surprised if GitHub goes for it by extending their awesome `gh` tool.

1letterunixname 4y ago

I work at a megacorp. We asked to pay Git folks to support monorepo sparse checkouts. They refused. Lo and behold Microsoft enters the ring, hires a Git committer to do it, and now it has it. Instead, we forked Mercurial, and got rid of staging and branching. Straight-line development is the way to go for most monorepos. Feature branches create a big mess. You also need sparse file systems for large mono repos otherwise the storage and network requirements exceed what is reasonable. In addition, it's imperative pushes default to running server-side sanity lints (with break-glass bypass) before accepting commits. This means either disallow pushes to production repos with a CI/CD stage + code review in-between or have some sort of proof-of-work hooks that accept local testing results. GPG has the same problem: powerful but the UX is a hot mess.

TheChaplain 4y ago

I had a couple of colleagues complaining about Git, so I asked what was the problem. "Hard to use", "commands doesn't makes sense" was among the answers. Two hours on a whiteboard explaining how Git works in a little more detail and now the complaints are gone. The gist of my anecdote is; learn your tools properly, not only does it save you headache but also makes you more productive. (It's a bit dated, but Pro Git by Strauss is an good book to get a better understanding of Git)