3 ms·
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
by jasonkester 3y ago
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.
- Kwpolska 3y agoThere is an "Abort" button. It’s `git merge --abort`.
- korm 3y agoIt'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.
- alexchamberlain 3y agoOh 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.
- rcxdude 3y agoGit'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.
- korm 3y agoExactly, clicking on the commits I want to cherry-pick is way faster for example.
- rcxdude 3y agoYeah, a GUI really helps with version control. And all of them have a honking great 'abort' button for merges and rebases.
- Kwpolska 3y agoWhere 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.
- korm 3y agoMy 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.
- sshine 3y agoHere, 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”.
- brabel 3y agoAnd that's literally a button in most IDEs :D.
- coufu 3y agoThe only way out is through? git merge --abort
- ssivark 3y agoIn 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)