5 ms·

"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

by 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)
    - planet_1649c 4y ago
      I’m in the third group.
      - TheNewsIsHere 4y ago
        I fall into the first and third groups outlined. I love Git, but if the project I’m working on is in VS Code, I just use that because it’s less friction than breaking into a CLI workflow. I also use VS Code to resolve more complex things because I find the Git CLI to be unintuitive.
- throwaway_au_1 4y ago
  To address only one sentence of your comment and offer a pointer for anyone who needs it: the git reflog can get one out of some uh-oh-reclone-time mistakes and it's pretty easy to use.
  - RHSeeger 4y ago
    I appreciate the comment, but "it's pretty easy to use" is not something I've found to be true when it comes to reflog.
- theamk 4y ago
  Eh, what about group 3? 3 The group of people that think that git is powerful, and that CLI is not the best but still learnable, and that acknowledge that for some inexplicable reasons some people cannot seem to learn git somehow. I think the problem is that the scope simply grew. Back in my svn days, "merge branch" is something only senior engineer does for entire team and not every day; patches are exchanged by emailing entire files or .patch files; rebase is imposible; you "stash" with "cp file file.old"; and history rewrite is something that happens once or twice in your carrer. And with git, you are basically expected to do all of that, every day, even if you a just starting.
- spoils19 4y ago
  To be fair, the CLI is pretty easy to use, and if you get into a situation where you need to redo your entire repo, that's entirely on you. In the 16 years I've been using Git I have never had an issue that wasn't solved by carefully reading the documentation (something that is lost on developers, these days).
RunSet 4y ago
Git is the perfect tool to develop the Linux kernel and a wretched kludge in any other context.
BiteCode_dev 4y ago
Yes, the interface is bad. But the paradigm also is: - it's made for multiple remote first (e.g: manual syncing is assumed by everything) despite the fact most projects have one - it forces you to craft your commit index to commit instead of letting you commit all changes by default, and optionally craft things - rebase exist, and is used a lot - you have to chose between easy merge and a clean history - it's hard to get a lock, a big file, a ticket or a todo list in sync in this repo. It's not made for that at all, and requires additional services or apps. Fossil seems to fix all those.
- charrondev 4y ago
  - you have to chose between easy merge and a clean history I will note that at least with GitHub we’ve been using squash merges for a couples years on a pretty large project and it’s solved this for us. The devs that want a clean history (like me the project lead). Bisecting is very easy, every commit references a Jira ticket ticket. People that want to land multiple patches with multiple messages can make multiple pull requests. If you think the changeset is so distinct that I don’t want it to be one commit in a bisect, each changeset deserves its own review.
mamcx 4y ago
Git is the interface. Nobody go around moving bits in the internals of the files of git.
- jasonboyd 4y ago
  > Git is the interface. What? That doesn't even make any sense. Aside from the CLI I can think of almost half a dozen GUIs off the top of my head. All different interfaces for Git.
KronisLV 4y ago
> Git as a version control system is great, but it desperately needs an "apt style" revamp. I'd say that this is one of the reasons for why many prefer to use either integrations with their IDE, or graphical tools like SourceTree, GitKraken or even something more basic like Git Cola. Git actually has a page listing other GUI software: https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis it's nice to have many options, some might also like the workflow of TortoiseGit, especially if they've previously used TortoiseSVN Personally, I also fall into this camp: and if I need to do something "fancy", then it's quite likely that I've diverged from the usual "happy path" too far and should rethink my approach (and if necessary, then just drop down to CLI after some googling). Of course, there are various camps in regards to all of this, but being able to stage/unstage individual code chunks/blocks and spread out/group changes that have already been done in files over multiple commits feels like a nice quality of life improvement. Plus, the diffs that something like the JetBrains IDEs show you, as well as the ability to look at the history for a particular selection is also nice. Then again, there are also many who don't rebase their branches, or even don't select squashing merge commits in whatever UI they might use (e.g. using GitLab/GitHub for their code review functionality and other features), which some might dislike for any number of reasons. I guess that just shows that there are many different workflows and people flock to whatever they feel comfortable with (or whatever their org/team mandates). As for the actual CLI, in general there are few programs out there that actually feel good and usable to me, one of which is the Docker CLI (for the most part). I actually compared its discoverability/usability to something like tar previously here: https://news.ycombinator.com/item?id=29339018 https://news.ycombinator.com/item?id=29339018 Something like Typer actually let's you create your own interfaces like that, though the new formatting is a bit curious: https://typer.tiangolo.com/ https://typer.tiangolo.com/ That said, I wish we had more TUI software as well, such as https://k9scli.io/ https://k9scli.io/ or even https://github.com/bcicen/ctop https://github.com/bcicen/ctop Edit: actually one bit of functionality from Git that I miss would be telling it to treat certain changes in the working copy as something that shouldn't show up as modified, but also not even show up as something that can be staged/committed. Maybe something like stash, but whilst keeping the modified files in the working copy. For example, a local database instance that I have doesn't work with how the app wants to use it (suppose that I cannot fix this for any number of reasons) and therefore I need to change every instance of: ORDER BY NLSSORT(some_column, 'NLS_SORT = custom_nls_value') to: ORDER BY NLSSORT(some_column, 'NLS_SORT = standard_nls_value') across the codebase, which means that I might have 100+ changed local files. I just need those changes locally so the local database would launch and keep working, but I don't want to have to look at all of these files as "changed" when deciding what to commit. Of course, at that point you might run into some hot water regarding what would happen if the files that contain this value would actually be altered.
martinvonz 4y ago
For people who want Git's data model but a better CLI, check out https://github.com/martinvonz/jj https://github.com/martinvonz/jj. It's a more Mercurial-like CLI but you can use it with existing Git repos. It also includes undo functionality, anonymous branches and other nice features.
karmakaze 4y ago
When I started with git coming from CVS then Subversion, it was hard. As soon as I developed a mental model that pretty closely matched git's everything pretty much clicked. Can't say I've ever got dead-end stuck, though I've made plenty a mess with rebasing, submodules, etc. Now I make temp branches before major operations (or merely save its hash in cmdline comment history) so I don't have to dig through reflog. Another tip, don't use stashes (unless very briefly, e.g. git stash; git pull --rebase; git stash pop), you'll end up with too many of them and forget/lose them. The other thing I use extensively is the Resolve Conflicts UI of JetBrains IDEs on a 43" monitor to pick/choose edit what the resolution should look like.
senectus1 4y ago
yeah agreed. Whats interesting is that my 14 yr old son picked it up faster and better than me. I suspect something about having to unlearn previous behaviors...

by urthor 4y ago

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)
  - planet_1649c 4y ago
    I’m in the third group.
    - TheNewsIsHere 4y ago
      I fall into the first and third groups outlined. I love Git, but if the project I’m working on is in VS Code, I just use that because it’s less friction than breaking into a CLI workflow. I also use VS Code to resolve more complex things because I find the Git CLI to be unintuitive.
throwaway_au_1 4y ago
To address only one sentence of your comment and offer a pointer for anyone who needs it: the git reflog can get one out of some uh-oh-reclone-time mistakes and it's pretty easy to use.
- RHSeeger 4y ago
  I appreciate the comment, but "it's pretty easy to use" is not something I've found to be true when it comes to reflog.
theamk 4y ago
Eh, what about group 3? 3 The group of people that think that git is powerful, and that CLI is not the best but still learnable, and that acknowledge that for some inexplicable reasons some people cannot seem to learn git somehow. I think the problem is that the scope simply grew. Back in my svn days, "merge branch" is something only senior engineer does for entire team and not every day; patches are exchanged by emailing entire files or .patch files; rebase is imposible; you "stash" with "cp file file.old"; and history rewrite is something that happens once or twice in your carrer. And with git, you are basically expected to do all of that, every day, even if you a just starting.
spoils19 4y ago
To be fair, the CLI is pretty easy to use, and if you get into a situation where you need to redo your entire repo, that's entirely on you. In the 16 years I've been using Git I have never had an issue that wasn't solved by carefully reading the documentation (something that is lost on developers, these days).

RunSet 4y ago

Git is the perfect tool to develop the Linux kernel and a wretched kludge in any other context.

BiteCode_dev 4y ago

Yes, the interface is bad. But the paradigm also is: - it's made for multiple remote first (e.g: manual syncing is assumed by everything) despite the fact most projects have one - it forces you to craft your commit index to commit instead of letting you commit all changes by default, and optionally craft things - rebase exist, and is used a lot - you have to chose between easy merge and a clean history - it's hard to get a lock, a big file, a ticket or a todo list in sync in this repo. It's not made for that at all, and requires additional services or apps. Fossil seems to fix all those.

charrondev 4y ago
- you have to chose between easy merge and a clean history I will note that at least with GitHub we’ve been using squash merges for a couples years on a pretty large project and it’s solved this for us. The devs that want a clean history (like me the project lead). Bisecting is very easy, every commit references a Jira ticket ticket. People that want to land multiple patches with multiple messages can make multiple pull requests. If you think the changeset is so distinct that I don’t want it to be one commit in a bisect, each changeset deserves its own review.

mamcx 4y ago

Git is the interface. Nobody go around moving bits in the internals of the files of git.

jasonboyd 4y ago
> Git is the interface. What? That doesn't even make any sense. Aside from the CLI I can think of almost half a dozen GUIs off the top of my head. All different interfaces for Git.

KronisLV 4y ago

> Git as a version control system is great, but it desperately needs an "apt style" revamp. I'd say that this is one of the reasons for why many prefer to use either integrations with their IDE, or graphical tools like SourceTree, GitKraken or even something more basic like Git Cola. Git actually has a page listing other GUI software: https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis it's nice to have many options, some might also like the workflow of TortoiseGit, especially if they've previously used TortoiseSVN Personally, I also fall into this camp: and if I need to do something "fancy", then it's quite likely that I've diverged from the usual "happy path" too far and should rethink my approach (and if necessary, then just drop down to CLI after some googling). Of course, there are various camps in regards to all of this, but being able to stage/unstage individual code chunks/blocks and spread out/group changes that have already been done in files over multiple commits feels like a nice quality of life improvement. Plus, the diffs that something like the JetBrains IDEs show you, as well as the ability to look at the history for a particular selection is also nice. Then again, there are also many who don't rebase their branches, or even don't select squashing merge commits in whatever UI they might use (e.g. using GitLab/GitHub for their code review functionality and other features), which some might dislike for any number of reasons. I guess that just shows that there are many different workflows and people flock to whatever they feel comfortable with (or whatever their org/team mandates). As for the actual CLI, in general there are few programs out there that actually feel good and usable to me, one of which is the Docker CLI (for the most part). I actually compared its discoverability/usability to something like tar previously here: https://news.ycombinator.com/item?id=29339018 https://news.ycombinator.com/item?id=29339018 Something like Typer actually let's you create your own interfaces like that, though the new formatting is a bit curious: https://typer.tiangolo.com/ https://typer.tiangolo.com/ That said, I wish we had more TUI software as well, such as https://k9scli.io/ https://k9scli.io/ or even https://github.com/bcicen/ctop https://github.com/bcicen/ctop Edit: actually one bit of functionality from Git that I miss would be telling it to treat certain changes in the working copy as something that shouldn't show up as modified, but also not even show up as something that can be staged/committed. Maybe something like stash, but whilst keeping the modified files in the working copy. For example, a local database instance that I have doesn't work with how the app wants to use it (suppose that I cannot fix this for any number of reasons) and therefore I need to change every instance of: ORDER BY NLSSORT(some_column, 'NLS_SORT = custom_nls_value') to: ORDER BY NLSSORT(some_column, 'NLS_SORT = standard_nls_value') across the codebase, which means that I might have 100+ changed local files. I just need those changes locally so the local database would launch and keep working, but I don't want to have to look at all of these files as "changed" when deciding what to commit. Of course, at that point you might run into some hot water regarding what would happen if the files that contain this value would actually be altered.

martinvonz 4y ago

For people who want Git's data model but a better CLI, check out https://github.com/martinvonz/jj https://github.com/martinvonz/jj. It's a more Mercurial-like CLI but you can use it with existing Git repos. It also includes undo functionality, anonymous branches and other nice features.

karmakaze 4y ago

When I started with git coming from CVS then Subversion, it was hard. As soon as I developed a mental model that pretty closely matched git's everything pretty much clicked. Can't say I've ever got dead-end stuck, though I've made plenty a mess with rebasing, submodules, etc. Now I make temp branches before major operations (or merely save its hash in cmdline comment history) so I don't have to dig through reflog. Another tip, don't use stashes (unless very briefly, e.g. git stash; git pull --rebase; git stash pop), you'll end up with too many of them and forget/lose them. The other thing I use extensively is the Resolve Conflicts UI of JetBrains IDEs on a 43" monitor to pick/choose edit what the resolution should look like.

senectus1 4y ago

yeah agreed. Whats interesting is that my 14 yr old son picked it up faster and better than me. I suspect something about having to unlearn previous behaviors...