Hacker News Reader

Comment by jasonkester | Hacker News Reader

My big issue with Git is the way it handles Merges.

It throws up this dialog saying "there are conflicts", and by the time you see this, it has already monched a bunch of files in your local version and now the only way out is through. You need to drop everything and fix all this stuff right now before you can proceed. Even if it's last thing on Friday night and you'd rather just go home and try again on Monday.

If there was just an "Abort" button that stopped trying to push or commit or whatever and just put things back the way they were before, that would take all the worry out of it.

Because usually it would have been easy to avoid the conflict if only you knew it was coming before Git f'd your whole project.

View on HN

There is an "Abort" button. It’s `git merge --abort`.

It's so frustrating when people joining my team often scoff at the idea of using a git GUI.

They're hired to write software, not fumble with ancillary tools that they've been using incorrectly for over 10 years.

Either use the cli effectively, without messing up simple tasks, or use a gui that will teach you how.

There's surprisingly a lot of resistance even though we provide Gitkraken licenses for free.

To be clear, we have a few people using only the cli, we don't bring this topic up unless it's a problem.

Oh I'm the complete opposite. Why does everyone use a GUI for everything? You get good at dealing with the good plan _OK_, but if something goes wrong or you want to automate something, there's no flexibility.

Git's core abstractions map pretty dang well to a GUI. And the commit graph is inherently pretty visual. I find it a heck of a lot easier to navigate a repository graphically than via the CLI (it can be done, it's just not fast). For most people a GUI works better when they get into a sticky situation with git than the CLI. Automation is different, of course, but it's not generally hard to map actions in the GUI to commands if necessary.

Exactly, clicking on the commits I want to cherry-pick is way faster for example.

Yeah, a GUI really helps with version control. And all of them have a honking great 'abort' button for merges and rebases.

Where in my comment did I scoff at the idea of using a GUI? I personally mix a GUI with the CLI. Good Git GUIs certainly have an "Abort merge" button. But it’s far easier to write out a command that everyone can use than hope someone is using a good GUI.

My comment is in agreement with yours! I'm just expanding on how absurd it is to struggle with merge because GP didn't know about a simple --abort, and how common it is even with senior devs.

And yeah I too find a mix of GUI and CLI works great.

Here, every veteran developer uses git and rarely needs to ask for help (although it might save time), and every novice developer uses GitHub Desktop.

This works great.

One exception: if someone does a local rebase on a feature branch, GitHub Desktop will recommend “pull” from their remote instead of “push —force-with-lease”.

And that's literally a button in most IDEs :D.

In addition to the —abort option (with merge & rebase), there’s also the option of resetting to any state you desire, using either checkout or reset — and reflog for viewing a list of the states you might want to reset to. (Or even better, just use a tool that shows the graph of the repository)

The only way out is through?

git merge --abort

Reply on news.ycombinator.com