Live data from Hacker News

Oh Shit, Git

ohshitgit.com

51–60 of 237 posts

Re: Oh Shit, Git

#51
post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

They are bad. Some concepts like rebase etc. I still don't understand.

In software we often go for further complexity instead of less. I think because most of us who are the lead developers are often the most intelligent. And we often enjoy these complicated abstract models and they come easy to us. However in satisfying our own intellectual vanity we often don't see how many we leave behind. Which is good for our hourly rates, but less good for creating affordable and simple software.

Anyway one of the main practical advantages git had was decentralized repos meaning you were not dependent on an external server which meant git was often much faster if working with in daily tasks compared to centralized versioning systems

Re: Oh Shit, Git

#52
post #16

For someone to get out of a mess they would have to know that they caused a mess in the first place! I'm starting to think trying to get people to use rebase and squash is a losing battle when they frequently just merge without pulling.

I loath rebasing. Squash merge into the main branch after tests are green. Bisect still works.

Re: Oh Shit, Git

#54
post #43

Earlier quoted context omitted.

Conceptualizing a commit graph with branch/tag labels is the easy part. What gets messy is operations regarding remote vs. local (as you mention) and regarding the various local state one may have (working directory, index/staging). Then there’s also the issues that arise with merging, but you have those with every VCS.

I love mercurial’s solution of having phases for commits. Anything you created locally is Draft phase and can be mutated without “force”. Anything which was pulled or pushed is automatically marked as Public and is not easily mutated. Visualizing the commit graph also colors commits based on phase making it really easy to get a grasp of what’s going on. Is there an extension or something for Git to have similar behav…

Instead of using colors, a visualization that can be combined with branch colors would be nice. For example using bold for remote (“public”) commits, or dashed lines for local (“draft”) commits.

Re: Oh Shit, Git

#55
I avoid using git command line for all the reasons above

Personally I use a UI for git which basically solves all of these problems. All the branches and commits are visible. If you want something somewhere, right click on it and you'll get all the available options. Nothing to memorize and everything is available!

My own favourite after testing out a few is SmartGit, but it's paid so not for everyone. There are lots of free git UIs out there as well, but what I like about SmartGit is that it's completely full featured - every obscure git command is available somewhere - so I have never ever need to use git command line when on my local machine, not even for these obscure things like resets, rebase, cherry pick, squashed commits, etc you name it. Also SmartGit is cross platform so I can use it anywhere

Re: Oh Shit, Git

#56
post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

> It dominated the world despite the UX flaws, which suggests they really aren't that bad.

No it doesn't. It suggests the other features are so damn good that it overcame the horrible UX.

Re: Oh Shit, Git

#58
post #45
post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

Git's UI/UX is one of the worst engineering sins to be committed in the last two decades, and this website shows why. Literally nothing about git is intuitive and the "underlying model" is entirely ad-hoc. Instead of celebrating how Linus built git in only a few days he should be castigated for knowingly setting up ill-conceived software to go viral.

> for knowingly setting up ill-conceived software to go viral

I doubt that was the intention. Linux just needed a versioning system tailored to its needs, and that's exactly what Git is. Can't blame its creators that other people used it for scenarios it wasn't built for.

Re: Oh Shit, Git

#59
post #42
post #19

Earlier quoted context omitted.

I got my team on side to use rebase/squash instead of blind merge commits after I showed them how much easier git bisect is to use when you have a linear commit history in your main branch. Now nobody wants to be 'that person' who breaks the bisect feature in case we urgently need it.

"git bisect --first-parent" gives most of the same benefits for teams that don't rebase/squash. At least until someone does a foxtrot merge and then it never works again

What's a foxtrot merge?

Re: Oh Shit, Git

#60
I’ve been using git command line for over a decade. I know the vast majority of options and know how to bail myself out when things go awry. I’m the guy that people come to when they bork a rebase.

I still prefer to use Sublime Merge, I’ve tried almost every git gui out there and that’s the one that “stuck” and I rarely use the CLI. I’ve ever used and it takes so much pain out of coming up with all the crazy command lines and all the switches.

Post reply on HN