Hacker News Reader

Comment by Animats | Hacker News Reader

Some time back, some GUI design firm asked on HN for a suggested open source program that needed a GUI developed. They had some developer time free and wanted something that would get them visibility. I suggested they do a GUI for Git. Several such things exists, but they're just buttons hooked up to the command line; they have no useful visual outputs. A good GUI for Git, where you could look at branches and such graphically, would get attention.

Too hard, they said. They wanted something which just needed to be pretty, not something with tough human interface problems.

View on HN

GitUp for the mac is an excellent git UI. It is emphatically not just wrapping the command line (it manipulates the repo directly); you can do stuff like look at the timeline and directly edit it ("oh, delete this commit" or "move this branch tip here" or "merge these two commits" or "rewrite the message for this commit"). It's really nice.

Downsides is it's not well known, the principle dev is only doing bug fixes, and it while it's blindingly fast on small to medium repos, it doesn't scale well for larger repos.

Seconding gitup! One of those apps I didn’t mind abandoning my terminal workflow for. Great keyboard shortcuts. Really great and subtle UX for partial staging too.

I found myself using the "network" section of a work project on GitHub on an almost daily basis. It's basically a prettier git log.

I know about git log (and the millions of options it has), but it's ugly as a sin, difficult to just quickly browse, and is just so busy that it's hard (for me at least) to quickly get information on if employee x merged branch y into z or if v has the latest commits from w, etc...

So I ended up writing a user script to blow up the small window on the GitHub page to a larger size, and get rid of some stuff that we don't care about and made it a dashboard of sorts.

I spent some time one day trying to find something like it, butcame up with pretty much nothing that was easily setup and maintained and that I didn't need to build my own application around.

Read up on https://zwischenzugs.com/2018/03/26/git-log-the-good-parts/, it’s good and practical stuff.

I recently aliased `git history` to `git log --graph --all --simplify-by-decoration`, and have `glog` as `log --graph` (and so seldom use `log`).

If you’re earlier than Git 2.12 or so, you’ll need to add --decorate to get the branch and tag names shown.

This is amazing, thanks!

Why not gitk? It is basically the same thing, but local.

There is also gitg, which also includes primitive commit capabilities and uses the full-fat GNOME widgets, making it pretty.

Because both of them are basically "git log in a gui".

It's the same overly busy UI, the same lack of easily seeable branch names (yes I know this isn't how git works internally, but it's extremely useful), the same vertical layout on our widescreen monitors, and they are still ugly to me (although this is honestly one of the lowest on my list of priorities).

I'm looking for something like [0] but with a better UX (Github's version doesn't let you scroll with the mouse wheel for instance), is fast enough to pull up at a glance to quickly see the state of the whole repo, and won't get disabled if the repo has too many forks (and I'm guessing branches, although I've never seen it happen from then alone) like Github's does.

It's easy to glance at and see where a branch is (what was merged into it, what it was merged into, etc...), who did the work (in the example it shows in a "tooltip" when you hover over the dot), roughly when the work was done, and what that branch includes.

[0] https://imgur.com/tvTp5z8

SourceTree is actually a pretty good GUI for git; it shows the commit tree just like you said.

SourceTree is one of the few products I use where things have got a lot buggier as time moved on.

I've been saying this for a while. SourceTree used to be fantastic a couple years ago. Yet each update since those glory days has brought not just bugs, but a worse overall user experience.

It's because they were purchased by Atlassian.

I mostly only ever used it for branches, cherry picking and conflict resolution, and it was awesome for that.

I don't use it now, and I don't use branches or cherry picking. My personal philosophy is that I am not keen on branches: never have been, never will be. I see repositories as a two pizza team concept. If you need branches, you should split the repo, make more iterative changes, or look at establishing or improving a test suite. It keeps things simple and cognitively low overhead for everyone (as per the sqlite team's comments).

I find branches really easy for ensuring QA.

I work on a branch, raise a merge request to master, let my colleague do a check and point out any issues and then merge it once we're both happy with it. He does the same thing for me to check.

Other than that, no branches.

Whatever works. However, I am not keen on such hoops. Objectively, relative to "just commit to master" that is a pretty high overhead contribution process.

It is not immediate, needs to wait for another human to be around and mentally present, demands some sort of QA standards are created and commonly understood, and creates the need to make and manage a forum for listing and discussing merge requests.

You could get some of the way and retain instant feedback with automated tests, yet remove a lot of the overhead.

Agreed.

I use them a lot and love how it makes some advanced stuff much easier (committing hunks, interactive rebases). They're also cross platform, which is great.

Still, it's incredible how crappier it gets over time. It feels like every year there's some kind of new major refactor or UI framework refresh that just destroys whatever little stability the application had, as if a new lead comes in and decides to start everything from scratch.

As an engineer I kinda understand the reasoning (using a nuclear bomb to get rid of tech debt), but it's pretty baffling from a product lifecycle standpoint.

I wish they had a more stable model and were charging for registration really. I'd gladly pay them $50 or whatever for some modicum of stability.

I work on a huge codebase and SourceTree handles it quite well on macOS. A year ago I'd occasionally see updates that were occasionally broken (solvable with a downgrade) but it's been pretty solid lately.

I find its OK on macOS but on Windows the latest thing is the delay in displaying modified files. Newly modified files sometimes take minutes to turn up.

Minutes? Today I hit F5 to refresh the window, and it still missed a checkin from 10 minutes earlier.

If you're talking about locally modified files, I use the integration with Visual Studio to manage those and it is doing an OK job. The only gripe I have with it is that you can't change an already staged file or those changes won't get checked in. I don't remember it working like that a year ago so something must have changed.

You have to click into the Sourcetree window for changes to show up. It updates instantly for me when I do that.

I use SourceTree daily and it regularly has very noticable lag on most window-related commands: close a window, open a repository, etc. And a lot of spinning beach-ball. Have you seen any of this?

I have experienced this. I think it happened when Atlassian switched over to WPF for the GUI in version 2 a few month backs. The new GUI has introduced a lot of bugs and performance issues that they still seem to be trying to figure out.

The visualization features are amazing though but could use a little bit more design.

Sourcetree is great, until it forget who you are and it can no longer push or pull.

what is wrong with gitk?

Did somebody say there was something wrong with it?

It's a cheap rhetorical tactic. The negative used to incite someone to talk about X instead of just "What about X?"

There are some git renders out there., like Gitkracken (commercial/gui) and tig (console/oss).

I did comparisons between gitkracken and tower. I found, at least on the Mac, gitkracken crashed often vs tower being stable. I was also turned off by the yearly price of $50 vs a one time $70.

Otherwise they had very comparable features including being able to display the histories, merges, etc.

Gitkracken is great. But so is Github Desktop.

I hardly ever have to use cmd git.

TortoiseHg is serving me faithfully since years, no real issues, big improvements in productivity due to being ablento actually look at your code evolving.

On the command line? Hg log --graph

The best I've ever seen is Tower (mac/windows), it makes most of the tedious steps and brain-cycles described in the authors' list very easy to manage.

I like using a mixture of Tower Beta (for the interactive rebase and visual commit staging edits), command line (faster!) and GitUp (for understanding repo history). I’ve been experimenting with using hub and go-jira command line tools for GitHub and JIRA respectively.

Have you looked at IntelliJ's git support?

How is your experience of its performance? The last time I tried it I found it made everything unusably slow; disabling that one plugin made an absurd difference in the responsiveness of the machine.

I haven't had noticeable performance issues with it, but I've not tried it with truly large projects. Otherwise it actually works pretty well.

Perfectly fine on a largish Python project (1000+ source files) on a 2015 MBP.

It tends to be slow if you use a hard disk due to seeking overhead. It does scan the history in background.

Ah, That was likely my issue then.

Have you seen projects like Git Cola or tig? I aliased `gl` (formerly `git log`) to `tig`.

https://git-cola.github.io/

https://github.com/jonas/tig

Tons of such GUIs exist already. Branch visualization is excellent in SmartGit (one of the best apps I've ever used, really) and many other apps have similar visualizations.

I find smartgit really nice. Makes life simple. It's just that one step simpler than sourcetree for me

I’ve tried most Git GUIs but keep coming back to SmartGit. I’m surprised it doesn’t get mentioned more.

Git Extensions seems adequate for visualizing branches.

come on, there are now a million reasonably good git GUIs though. I personally really like sourcetree

No, they all suck. Here is a graph rendering of a simple ClearCase repository:

https://svn.apache.org/repos/asf/subversion/developer-resour...

ClearCase is 20 years old or so, but no git gui comes close.

The reason is git's peculiar object model. It has nodes (commits), edges between nodes (parent references) and references (pointers to commits) but no branches. That means it is not in general possible to tell which branch a particular commit belongs to. Asking a question like that just doesn't make sense i git's world. Therefore visualizing complicated branching scenarios, in ways that makes sense to users, becomes almost impossible. This is why people advocate rebasing https://blog.carbonfive.com/2017/08/28/always-squash-and-reb... The idea is to "lie" to the vcs because otherwise your history becomes a hodge-podge mess of merges. :)

Btw, all other features of ClearCase were just horrible and brain-damaged. But the branch visualizer kicked ass.

> That means it is not in general possible to tell which branch a particular commit belongs to.

That's because commits can belong to multiple branches, which is by design.

> Therefore visualizing complicated branching scenarios, in ways that makes sense to users, becomes almost impossible.

There a reason users need to visualize complicated branch scenarios?

> This is why people advocate rebasing https://blog.carbonfive.com/2017/08/28/always-squash-and-reb.... The idea is to "lie" to the vcs because otherwise your history becomes a hodge-podge mess of merges. :)

Rebasing/cherry-picking isn't lying, it's avoiding the mess of a merge at the expense of being a tad more difficult.

Seems you have a very concrete idea of what you think a VCS is, and git disagrees with you, thus they "all suck".

> > That means it is not in general possible to tell which branch a particular commit belongs to. > >That's because commits can belong to multiple branches, which is by design.

I could be wrong, but I think what they mean is the fact that once you merge/rebase your dev branch back into master, all of those commits you made in dev are now commits in master.

You could conceivably have a source control system that still allows commits to belong to multiple branches, but bakes the branches of a commit into the commit. (And I believe many/most other source control systems do just that.)

The fact that the branches of a commit can change later on always struck me as being completely inconsistent with the commonly held idea about git that outside of master it's ok to forego testing. That really only works if you squash into master (and test that squash commit). If you don't squash, and especially if you fast-forward, then all of those commits are now "in" master, and so you've dumped a bunch of untested stuff in master.

Any which can open Linux without becoming unusable (other than gitk)? Every one I've tried absolutely cannot cope with a large repository.

Damn, that's pretty ruthless how they blew you off like that after you did 90% of the work (coming up with an idea). And one that's already been implemented many times.

Just shows you how lazy some people are!

Reply on news.ycombinator.com