Hacker News Reader

Comment by quietbritishjim | Hacker News Reader

> I say "just rebase your branch" and I can see the panic grow in their eyes.

The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.) work very well. (So does TortoiseHg but obviously not for Git!)

View on HN

Magit[1] is also excellent. And like all good git tools it exposes a log of what it did. Unfortunately it doesn't work so great with megarepos, but I understand that's being worked on. One area where this tooling is vastly superior to the command line is adding hunks instead of files to a commit, making it much easier to have a sensible history while allowing programming in a more natural style.

[1] https://magit.vc/

+100 for Magit. My favorite feature is rebasing directly on logs.

My experience also supports this. I think resolving complicated merge conflicts is the best argument for using an IDE with Git. My experience of having to maintain a fork of a code base where there was frequently a lot of conflicts showed that I would reach for IntelliJ to resolve complicated conflicts even if it wasn’t Java files. The 3 window visualization they use is just great for seeing conflicts in large files that span hundreds of lines of code.

I use the terminal commands for everything else though.

> The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line.

This is an argument for a good GUI diff/merge tool, which is not necessarily the same thing as an argument for a GUI Git client; I think the two uses are being conflated a lot throughout this comment thread. I have Kaleidoscope set as my default mergetool and difftool, but I'm still working with the git CLI nearly all the time. (I use Gitup on the occasions I want to stage changes to individual sets of lines in the same file as multiple commits, and exceedingly rarely if I'm trying to do something frightening with a local as-yet-unshared feature branch. There are times being able to undo with Cmd-Z is really helpful.)

You're right that there are two different parts to a these, but I think they both benefit from graphical tools.

I'm talking about a VCS tool telling me that the rebase had got to commit n of m and a conflict has been encountered, and which files have conflicts resolved (either automatically or I've manually resolved then so far in this tool), and which other files have conflicts outstanding. Then I can invoke the three way merge tool from there (which is indeed hugely better than a command line tool). Something like this (except this is for Hg):

https://i.stack.imgur.com/kaFNz.png

I use Meld in case there are conflicts of these types. The CLI can be configured for that, and mine is set up that way.

But truly, I never just use plain pull, but pull --rebase, and I have not experienced such a conflict in years.

The commit history also stays a bit more linear. (Other developers use normal pull).

I learned git with the CLI. Occasionally I will use it.

But I see no reason to not use Jetbrains beautiful beautiful git integration for almost everything. It really is just ... perfect.

But if people want to feel superior by typing commands in a terminal, go ahead.

SourceTree doesn’t give up. It tells you that you have conflicts to resolve. Once you do, “continue rebase” does what it says, either until the rebase completes or until it hits another conflict.

Does it show a GUI, analogous to [1], or tell me to sort it out myself on the command line? I'd it's the latter then that's very much giving up. On the other hand, it's possible I'm mixing it up with some other GUI I tried.

If a rebase encounters conflicts, it tells you as much, puts every piece of the commit that it could auto-merge into the index, and adds conflict markers to what it couldn’t in the working tree. Then it’s up to you to merge them in an IDE or Optionally (I think) choose yours / theirs for each hunk. Once everything is resolved and moved to the index, “continue rebase” goes on to the next commit.

I think it’s had a rebase GUI since I first started using it in 2013. It may not have had one back then for interactive rebase, or else it didn’t work for me, but it does now.

[1] was meant to be this, which is the TortoiseHg merge conflicts window:

https://i.stack.imgur.com/kaFNz.png

It’s not as nice as that one. I described it in my other comment. The workflow is okay, but that visual context of to/from branches in your screenshot is something I wish SourceTree had.

I would say that depends on your background.

This is just me but I’m quite happy viewing the graph via CLI and doing interactive rebases to fix issues.

I have no problems with other people preferring a GUI but all I’ve tried have been confusing for me.

Sublime Merge’s three-way merge is so good. It’s totally spoiled me.

Is sublime doing the merge instead of git? Or are you referring to use sublime as the merge tool to resolve conflicts?

Sublime Merge is a GUI git/mergetool, from the makers of Sublime Text.

Just for resolving conflicts.

I actually agree, using a nice GUI to handle your merges is a godsend. If you know how to use it properly, and still know how to do more advanced operations as well.

Vim has some plugins that make it a lot easier/quicker.

A combination of git diff, git checkout --ours/theirs . && git add and git mergetool works well in my experience

Reply on news.ycombinator.com