Hacker News Reader

Comment by munificent | Hacker News Reader

> incompetent at using git

This unfairly places the blame for Git's utterly shitty UX on the part of the users. When you have thousands of users who struggle to use a tool correctly, it's the tool's fault, not theirs.

I've been using Git for years, work professionally full time on an open source project that lives on GitHub, maintain several open source projects with a number of committers and generally live and breath Git and GitHub all day.

I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it.

View on HN

> I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it.

When I had no understanding of what was going on, I didn't like it either. Now that I use it frequently, I understand it better, so I don't hate it anymore.

I like running `git rebase <main-branch>`, where <main-branch> is typically master, in my-new-thing branch because it lets me deal with any conflicts from upstream one by one.

I also like running `git rebase -i` in my-new-thing when I have a bunch of commits with redundant messages that I want squashed into a single commit before I push the changes. Basically anything that requires messing around with a range of commits is a good use case for `git rebase -i`.

Why do you hate it so much? There's really not much going on that you should have to hate. To me it's like a bunch of small, compartmentalized merges.

Genuinely curious, why the love for the `git rebase -i`? I find it much easier and more intuitive to squash a set of linear commits on a branch using `git reset --soft HEAD~n` where n is the number of commits to go back and "undo". Then make one more commit and you're off to the races. Note: this is not useful if force push is disabled and you've already pushed some of the commits to the remote (feature) branch.

In addition to bpicolo's point below, things quickly break down if your commits have file removal or renames. I've gotten bitten more than once and now always resort to git rebase [-i] to avoid this.

rebase -i doesn't force you to squash all the commits, and also lets you clean up commit messages

Congratulations on learning it, but that hardly means that it’s particularly user-friendly or intuitive.

I also like rebasing from time to time, but I do feel like I’m tiptoeing on a tightrope above the alligator pit when I do so.

It is incredible to me to see how many people in this industry will sit here and defend an agonizingly terrible tool. Total Stockholm Syndrome.

The problem is that the tool is both great and terrible. It's basically like a Formula-1 car: ultimate performance, but with huge potential for disaster in the hands of someone who doesn't know what they're doing. It doesn't help that the tool has been growing organically over time, leading to a really confusing UI. Also, it's extremely versatile, but that's both a blessing and a curse, as people can develop totally different and incompatible workflows.

Maybe people need to create some command-line front-ends to git which force users into particular workflows and subsets of the commands, and which clean up the UI, much like how almost no one uses TeX, but instead they use front-ends like LaTeX.

Git is a great data structure with a pretty bad tool to manipulate it. That said, what MBlume said is that one should learn to use the tools one uses (and if you're using Github, you're using git), which is not a defense of git in itself.

Reply on news.ycombinator.com