Hacker News Reader

Comment by oauea | Hacker News Reader

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push.

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

View on HN

> 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!)

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

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop.

I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.

How are version control systems meant to be used, if not as a history of the work? If not as a remote backup of work in progress?

I get the whole “we should have a neat history of feature commits” argument, but that’s really only one facet of a good source control system.

The fact that these goals appear to conflict shows me there’s some sort of lack in git. For all its (many, many) problems, uber-complex source control system ClearCase at least allowed you to specify a view, so you could see both types of information depending on your use-case.

They’re not really in conflict at all. The workflow I’ve been using for ~11 years is:

- Make a branch for my work.

- Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was.

- Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup.

- When ready to integrate, interactively rebase into a set of cohesive units which are independently buildable and have detailed commit messages which explain why the work was done, not what the works was.

- Push _this_ as a pull request, Gerrit change set, or email patch, depending on policy.

This approach gives you the best of both worlds: fast, easy backup and easy unwind when doing work, and a clean history for the benefit of future developers on the project.

You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later.

I’m fact I’ve found that far more useful than a well curated history.

Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a sweet spot.

I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit.

You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.

> You can always keep your working branches on a personal remote

This kinda defeats the point again, to my view. I’m not familiar enough with gists to know if they would solve this.

Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.

The only visual git tool I really like is gitextensions for windows.

Fork has its advantages too (and a slicker UI if that matters for you)

Reply on news.ycombinator.com