return to table of content

GitUI

abdullahkhalids
15 replies
20h1m

Has anyone made a click-and-drag UI for git? Where you can do operations on branches by just dragging them around.

memco
4 replies
13h55m

My favorite got GUI is Fork: https://git-fork.com/ It supports drag and drop for several operations including merge, rebase, and stage/unstage (and probably more).

ap-andersson
3 replies
10h38m

Also love Fork and my whole team uses it at work aswell. We work on Windows and wanted a better GUI app since we use git from a GUI 90% of the time. We used to use Sourcetree years back and it never worked well. Tried a few alternatives but in my mind Fork was the clear winner. The UI is clear, snappy and works as you expect it would. I wish they had a higher price for companies (to make sure they can survive, since they use lifetime licensing...) and possibility to buy licenses that can be assigned and reassigned. I had to fight the company to buy the license since you always buy it for an individual, which does not fit how companies usually buy software or subscriptions.

stsrki
1 replies
8h32m

I also use Fork and find it the fastest and easiest git GUI. And I tried so many GUIs in the past. One thing that works well in Fork is submodules, which are almost non-existent in other GUIs. And the UI is really fast to respond.

On a side note, regarding the licensing. As a software vendor selling to enterprises, I always struggle with finding this kind of information. Would you be willing to briefly explain how large enterprises usually buy software or subscriptions? It would help me/us so much.

robertlagrant
0 replies
7h26m

Not the OP, but check out any software pricing page[0] for the sorts of things enterprises are after. E.g. larger-discount pricing; annual/monthly invoice billing; team management; SSO; etc.

[0] e.g. https://www.git-tower.com/pricing/mac

namtab00
0 replies
5h46m

did you evaluate GitExtensions?

BerislavLopac
2 replies
15h45m

I'm not sure what's kind of of operations could be done by "dragging branches around", but in GitKraken

drak0n1c
1 replies
14h55m

GitKraken has a dropdown menu that appears whenever you drag and drop if it involves two elements (ie merge, rebase, create GitHub PR), as well as right click if you're operating on one element (ie creating branch/tag here, reset soft/hard). Double left-click to checkout a branch. There are big buttons at the top for fetch/pull/push, and when staging a commit there's a clean and focused view for choosing which hunks to stage. Basically all needed operations can be initiated with minimal mouse actions, and anything destructive has a confirmation.

BerislavLopac
0 replies
8h20m

Thank you, that's exactly what I wanted to write, but my phone hiccuped in the middle of writing that comment and I wasn't sure if it was posted at all. :rolleyes:

ric2b
0 replies
16h50m

GitKraken

nurgasemetey
0 replies
14h17m

Sublime Merge

kentosi
0 replies
16h34m

Even after 10 years, SourceTree is still my goto when I need UI click-and-drag.

eddd-ddde
0 replies
13h33m

Not exactly git, but meta's version of mercurial (I think it's called sapling) has this, you can rebase really easily your commits.

danielhep
0 replies
18h27m

Git Tower for Mac works great for this

charrondev
0 replies
17h38m

I use GitHub desktop for basic operations and the CLI for anything complicated. It’s a pretty minimal git client but it does have some drag and drag (for cherry picking commits.

Yasuraka
0 replies
18h36m

I did stumble upon an extension where it's one of the advertised features, but haven't tested it

https://marketplace.visualstudio.com/items?itemName=trunkflo...

BaculumMeumEst
13 replies
21h19m

i would be interested to see what proportion of rust projects put “written in rust” in the project description vs other languages

zemo
2 replies
21h5m

honestly I bet a big portion of why that works is that they're statically linked binaries, but "ships as one statically linked binary" doesn't have quite the same marketing power. One of the first things I do when I check out an open source project is check if it's written in or requires node.js, and if it does, I ignore the project. I've worked with enough node.js stuff over the years to know that I simply do not want to deal with its ecosystem. I feel the same way about Ruby but I can't remember the last time I saw a new Ruby project. If I have to deal with managing an interpreter, I don't want to use your project. Python only gets a pass because I still use it professionally so I am personally up to date on its quirks, but I can understand why someone would say the same thing about Python projects.

ubercow13
0 replies
20h54m

I also use Python professionally and still have by far the worst luck with getting anything Python on github to work out of any language.

Written in Go/Rust is definitely a feature for something like this.

freedomben
0 replies
20h50m

Rust != ships as one statically linked binary though. For project in Go, that's a pretty safe assumption (although not always true), but for Rust stuff I've probably had 1/4 of things not be statically linked. For many Rust-based projects I find myself having to build it myself, which fortunately isn't very difficult.

codetrotter
2 replies
21h12m

Probably similar to the the percentage for projects written in Go.

motza
1 replies
20h42m

Not as many as Go

diggan
0 replies
6h21m

Not as many as Go anymore. There was definitely a period in time where every new Go project had the suffix ".. written in Go", just like there before that was a period in time when projects took care to add "... written in Ruby".

I guess it could be seen as a point of maturity at this point, when projects stop adding those suffixes.

sbarre
1 replies
21h7m

Honestly, for me it's a selling point.

Generally speaking Rust programs are fast, memory-efficient and of high quality.

I'm certainly not saying this is always the case, or that it's impossible in other languages, but I am definitely going to take a closer look if something new and interesting prominently says it was built with Rust.

mteam88
0 replies
20h20m

I agree, I generally tend to prefer rust tools, like Alacrity.

Takennickname
1 replies
21h12m

This one is fine.

The funny ones are the ones that put "Written in Rust" in the features section.

rrr_oh_man
0 replies
20h33m

Reminds of those terrible startup pitch competitor comparison tables

Daeraxa
1 replies
21h11m

Blazingly fast

awson
0 replies
3h48m

And using `libgit2`, written in C, for heavy-lifting.

vrmiguel
0 replies
16h0m

I'd also like to see what's the proportion of comments just like yours on every project written in Rust out there, should be nearing 100% now

nomilk
10 replies
20h14m

Out of curiosity, what specific tasks are easier using a GUI? (I've never used one; keen to learn if I'm missing out)

insin
3 replies
19h42m

As a former darcs user who was won over by and still uses git-gui to this day, reviewing and staging/reverting changes hunk-by-hunk/line-by-line, and subsequently referring back to what I've left unstaged.

nomilk
2 replies
19h39m

How does this differ from git commit --patch?

rtpg
0 replies
13h34m

At least with magit, I can look at the entire diff, then highlight specific lines, and stage those fairly easily. `git commit --patch` gives youhunks, but if you need to break those hunks up it's a couple extra steps.

GUI stuff is not necessarily about enabling new workflows so much as making workflows _very fast_ and less error prone. In theory at least.

halostatue
0 replies
14h53m

Fairly extensively.

`git add --patch` (the way I usually do it) is good enough when you’re adding parts and know what to do in the future. Recently, though, I’ve been using lazygit's ability to create a partial patch from a commit and effectively split the commit into two or more parts. This lets me take a larger set of commits and turn it into something that is easier to review (it’s sort of a hyper interactive rebase where you can add or remove lines, files, or trees into each patch).

I wouldn't even think of doing this without lazygit (and if gitui is ever at par with lazygit for this, I might switch).

zamalek
2 replies
20h9m

I use it exclusively for paroosing/double-checking my changes and staging (especially individual hunks).

philsnow
1 replies
19h57m

paroosing

you might mean "perusing" (one of the many vocabulary words, like "quaff", "wield", and "comestible", that I learned from Nethack when I was younger) ?

zamalek
0 replies
19h22m

Probably, dyslexia can be like that.

rtpg
0 replies
13h35m

With Magit I've found that you can just be faster. Nicer autocomplete functionality, quick access to flags when doing operations, being able to point your cursor at a commit and say "cherry pick _this_ please".

Less futzing around with copying around IDs and the such. I still need to know how to do most everything with git itself, but because I know that, I can rely on magit to just make it quicker for me to "do the thing".

KronisLV
0 replies
18h49m

Out of curiosity, what specific tasks are easier using a GUI?

Personally, I really like being able to stage/unstage blocks of code or even individual lines in a GUI, if I've done some refactoring and added new logic at the same time, but want those in separate commits.

Aside from that, I really like working in a GUI, looking at the commit graphs, easily switching between any number of branches and merges being a right click away.

I actually ended up paying for GitKraken because it also makes managing multiple accounts (personal vs work) as easy as choosing what I want from a drop-down, as well as includes workspace functionality to group multiple repos together.

Before than, using SourceTree or Git Cola was also decent. Just feels like one of those things that are convenient with a GUI, except I enjoy standalone tools for that more than most IDE integrations.

Karliss
0 replies
10h6m

You can't just blindly run git commands without being aware of current state. Some beginners or people with less technical roles try to use git by blindly running 3 commands they memorized, but that easily results in a mess or situation where it's necessary to call a more experienced colleague to fix their local copy.

For me one of the biggest benefits of using a git GUI is always visible current state: what you have checked out, what are the recent commit, what's the state of other branches, do i have any unmodified files. All of it in front of my eyes, not requiring any additional input (beside alt tab for switching to the graphical git client). Not that you couldn't get the same information from git CLI, but the question is how often would you do that, and would you check all of it each time.

But I often perform many of the actual changes in terminal using the default git CLI client.

In this sense I consider shell integration based version control clients bad, as they require using context menu to open the information windows and it's a step that can be skipped since most of the other actions will likely be in the same context menu. Thus you endup with similar situation as CLI clients - information is available but you have to actively request it.

Next step to consider is TUI vs GUI. I find that that often due to constraints of fixed character grid and limited graphical elements TUI can be less dense. Every box and separator line means a wasted row/column. Two boxes side by side - that's two wasted rows. Everything being monospace font - additional wasted space. Single font size for everything - makes it impossible to use smaller size font for short less important text. You can set a very small text size in terminal, but it hurts overall readability of the TUI and all other work you do in terminal, and it doesn't change the fact that TUI was designed with limited available space in mind thus you only get slightly longer text but no additional information. On the other hand TUI will more likely have a very efficient keyboard only navigation and single key actions. GitUI and many Norton commander inspired TUI file managers like FAR and MC are good examples of this.

pama
8 replies
21h2m

"Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable." I have only witnessed that in magit (or pyright) when I have super deep directory trees (say a wide dataset collection) not yet in .gitignore and then git status takes forever in cmdline or in magit. But I don't think that there is a difference between a GUI or TUI or cmdline use of git in that case. Do other interfaces to git fail in more spectacular ways than git itself?

lolinder
5 replies
18h23m

It's surprising to me if so. IntelliJ's git UI is more than fast enough, and it's written in Java and embedded in the IDE. An external git UI shouldn't have any issues.

mschuster91
3 replies
17h35m

IntelliJ is only performant due to its indices of pretty much everything. That is its true magic.

In contrast, the Git CLI and most if not all other UIs have zero sorts of caching and have to start from scratch for everything.

lolinder
2 replies
15h56m

That seems like a problem that could and should be solved.

machomaster
1 replies
14h43m

It's not a bug, but a feature. No cache is by design.

mschuster91
0 replies
1h27m

There's nothing stopping Git from storing its state in an sqlite db.

lolive
0 replies
11h41m

IntelliJ has, imho, the most comprehensive & visual diff management UI. That thing alone discards any competitor [once again, imho].

rtpg
0 replies
13h37m

Magit's failure mode is downstream of it (I believe) pulling in diff information on the status page. When I've had this problem, doing `git status` on the command line has always been more or less instant.

There is something inevitable about needing time to display a lot of information. But I think magit is eager in some places that lead to extremely costly magit workflows when the raw git workflow would be much faster.

eddieh
0 replies
20h49m

Yeah, I never do a big merge in magit. I just use the git CLI for those.

jonwest
8 replies
20h53m

I see that lazygit is listed as inspiration for this project. As a lazygit user myself I'd be curious as to what was lacking from lazygit to warrant an entirely new project, as I've found it to be incredibly useful.

rrr_oh_man
3 replies
20h36m

I cannot judge whether the methodology makes sense, but the numbers seem quite impressive for my manager brain:

Readme.md

  For a RustBerlin meetup presentation I compared lazygit, tig and gitui by
  parsing the entire Linux git repository (which contains over 900k commits):


  |         | Time       | Memory (GB) | Binary (MB) | Freezes   | Crashes   |
  | ------- | ---------- | ----------- | ----------- | --------- | --------- |
  | gitui   | 24 s       | 0.17        | 1.4         | No        | No        |
  | lazygit | 57 s       | 2.6         | 16          | Yes       | Sometimes |
  | tig     | 4 m 20 s   | 1.3         | 0.6         | Sometimes | No        |

fbdab103
2 replies
17h54m

On the other hand, I do not work on a repository nearly the size of Linux. If you evaluate performance on a more modest project, is there a meaningfully human speed difference?

I will always take faster tools, but sometimes things are good enough.

vrmiguel
1 replies
16h4m

I found the memory gains to be more enticing than the performance improvements

no_carrier
0 replies
14h7m

Those memory figures relate to parsing the linux kernel repo, so the parent's question still remains, if it matters to the rest of us?

NERD_ALERT
2 replies
20h51m

I’ve been a daily lazygit user for years and tried this out a few months ago. Seems like a case of rewriting a near perfect tool in Rust just for the sake of doing it. From what I remember this project didn’t have any features that aren’t present in lazygit but was lacking some that are.

srott
0 replies
20h32m

I was missing interactive rebase, as it is missing from libgit2

https://github.com/extrawurst/gitui/issues/32

piersolenski
0 replies
19h29m

I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.

zuhsetaqi
0 replies
10h37m

He says it in the README:

2. Motivation

I do most of my git work in a terminal but I frequently found myself using git GUIs for some use-cases like: index, commit, diff, stash, blame and log.

Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable.
Sleaker
8 replies
16h5m

What's the main benefit of using a GUI with git for people? For me it's usually just the ease of not needing to know a commit hash to perform a rebase against after a merge, but I generally just do these ops from within an IDEs builtin git support and everything else is command line. Do others find a huge benefit from GUIs?

aulin
4 replies
11h33m

In magit I find invaluable being able to stage chunk by chunk. It enables a whole different workflow, where I review my own code staging it step by step.

Also being able to navigate blame history inside the editor is pretty cool.

No idea about other GUIs, if I have to get out the editor to use git I might just use the command line.

Sleaker
2 replies
10h53m

For workflow reviews I tend to just push to GitHub and then use it's review diff when making PRs to catch anything I may have missed (typos usually)

Ah I do use git blame sometimes but it's builtin to the ide so I get it while editing code live. I guess this is the biggest difference I have with not wanting a gitgui, any of those ops I feel like I can get with my ide.

aulin
1 replies
8h42m

Sure, magit is in some sense "getting it with the ide".

Not sure how advanced is blame in other editors, it's not just blame annotation, is being able to navigate the history of a line just jumping from one change to the previous and back. It's incredibly helpful with large code bases to understand how some code evolved and why it's implemented like that.

Another great magit feature is being able to open a file from any git revision. Like you want to copy some line from a file that's being long removed you can just call magit-find-file on a revision that still has it, open it in buffer, copy what you want etc.

Lio
0 replies
8h9m

I agree, navigating blame history is incredibly useful, if only to save you from asking the wrong person about a particular change.

Vim's Fugitive[1] can do this and also in Textmate to. So I would hope that most editor git plugins can.

1. https://github.com/tpope/vim-fugitive

cdcarter
0 replies
47m

`git add -p`

zdimension
1 replies
15h32m

Working often with multi branch projects across repos (forks and upstream), using GitKraken simply makes me more productive. I don't think anymore about how I'm gonna merge or rebase stuff, it makes everything more intuitive. I still use the CLI for advanced stuff that the GUI doesn't handle, but for day to day operation, it's a panacea

eddd-ddde
0 replies
13h27m

Lately I've been using this: https://martinvonz.github.io/jj/v0.10.0/

It's fully compatible with git.

What I used to need a GUI for now I can easily do with jj.

spixy
0 replies
7h58m

- (un)staging only parts of files instead of whole files

- seeing full content of a branch without checkouting

- seeing diffs between local/remote/stash branches instantly just by Ctrl + mouse click

- automatic stash+reapply local changes when pulling or checkouting branch

- easy using multiple ssh keys (due to multiple remotes)

- easy show/hide parts of tree in (a nice rendered) tree

- just one mouse click to show commit in github (and probably other sites)

etc.

most of them could be done with CLI but it would just be suffering for me

yetanother12345
5 replies
20h22m

Possibly OT, or tangential. But then this is HN, so

Various Package Managers

Quite a long list at the right side, but... no Debian?

I'd think that the user base of Debian would be larger than of some of the other distros listed (edit: changed wording here) there, so ...what up? why?

This is not the first time I've witnessed this exact situation during the past half a year or so. Is this some weird conspiracy among Rust devs (joke!), or is it the Rust tooling that makes integrating into the apt ecosystem a challenge, or what?

I mean, if I really insisted on getting that tool installed I see there's a binary, and if there was not, I'd find a way, but I'm genuinely curious. This seems counterintuitive, so there must be a reason? no?

yetanother12345
0 replies
16h54m

Thanks all below, I was not aware. I'm (a little) wiser now.

steveklabnik
0 replies
18h51m

I mean, there's tools that make it easy to make a .deb https://crates.io/crates/cargo-deb

The Rust Project itself had put a lot of work into making sure that Rust and Rust-using programs could get into Debian by working with Debian folks to address issues.

I suspect that you've run into an anecdotal pattern, but I'm not sure that it is more than that.

not_the_fda
0 replies
19h19m

A lot of them are in the red.

I think the reason is that its built using rust, which moves fast and breaks things, very un-Debian.

This tool requires rust 0.65 which is old by rust standards. The latest debian stable has rust 0.63.

mschuster91
0 replies
17h29m

I'd think that the user base of Debian would be larger than of some of the other distros listed (edit: changed wording here) there, so ...what up? why?

Debian packaging is notoriously difficult and has a very steep learning curve if you want to do it "the right way" aka using Debian's arcane collection of debhelper Perl scripts.

On top of that, there was/is/IDK a lengthy period of debate in Debian on how to deal with third party library managers in general (PHP Composer and especially NodeJS started the debate), which scared people off for good.

da39a3ee
0 replies
5h58m

Hi, this is completely normal. Debian has a very lengthy process for accepting packages. Other places you just submit a PR. It's normal for open source projects to only get into Debian after a few years when they can genuinely say they are established/popular/stable.

platz
4 replies
20h35m

the sticky wicket really is a nice way to do interactive rebasing & resolve merge conflicts without complex external app configuration

38
3 replies
20h33m

what the fuck is a sticky wicket

nineteen999
1 replies
20h7m
38
0 replies
14h59m

that doesn't help...

swiftcoder
0 replies
20h8m

A cricket (the sport) metaphor. What it means here is however a mystery

glitchc
3 replies
18h19m

This looks great, I'll give it a whirl.

I'm hoping GitExtensions gets ported to a native Linux application one day. I've tried dozens of UIs and nothing else seems to compare.

nichos
0 replies
13h37m

Gitex is fantastic. I'm still using the 2x mono version on Linux.

namtab00
0 replies
5h43m

It always amazes me how few devs know. GitExtensions.

Only other git UI that's comes close to it is Tortoise, of which I've only used the hg variant a while back.

Spunkie
0 replies
18h13m

Similarly, tortoisegit is the only windows application I miss on a daily basis since switching to Linux.

No other git ui program has ever come close to how naturally I feel using a context menu based system like tortoisegit.

bananapub
2 replies
19h49m

it is fascinating that after all this time, `magit' is still the nicest alternative Git UI. so nice that I fire it up sometimese even when I'm not otherwise using emacs.

sourcegrift
0 replies
18h50m

I'm not even an emacs user (20 year vim user) but learned (and now even teach clients) "Just enough emacs for magit". Magit truly is magic.

da39a3ee
0 replies
5h56m

Ex emacs user, still run emacs for magit. Use it hourly.

wruza
1 replies
7h3m

One of my concerns with ui tools is that they often hide the actual command from the user, so it’s hard to reason about what’s wrong afterwards and how to avoid it in the future. E.g. some tools could add pretty opinionated flags that are incompatible with the rest of workflow done in a regular cli.

Idk if it applies to this one. Just thought that this feedback could be interesting for tools from this category.

namtab00
0 replies
5h47m

That's why (on Windows) I use and love GitExtensions.

It always shows complete commands it issues, and you can fully view the complete log.

hesdeadjim
1 replies
20h47m

Ah bummer, no LFS support.

amelius
0 replies
20h36m

And no sparse repo support.

badsectoracula
1 replies
20h29m

Fast and intuitive keyboard only control

I'm sure the author had nice intentions, but the very first thing i tried when i installed this (it is from openSUSE's repository so it might not be the latest version) was to resize the xterm window as it was too small and then tried to click and drag the edge of the file tree window hoping to make it smaller as i wanted most of the visible area to be the diff (and the files in the tree have small names, meaning most of the file tree window was wasted space). Turned out it was not possible.

The help shown with H didn't have any keys for that either, meaning it may not be possible even with the keyboard, though IMO this is one of the cases where even if it was possible via keyboard, being able to resize with the mouse is vastly easier and faster (keyboard resize is still nice for the cases where a mouse is not available though, like using the program via a broken ssh setup).

Lio
0 replies
8h18m

Yep, supplementing keyboard shortcuts with terminal mouse support is really useful.

In Vim the things I still use a trackpad/mouse for are scrolling and resizing windows. There's definitely no reason you can't have both even over SSH.

Would be a great addition here too.

zmmmmm
0 replies
20h17m

I try all these tools, but somehow always end up with some key feature missing or not working how I want. I guess it must be extremely personal. But somehow I always end up back at tig. With GitUI I couldn't find a good display of branching structure eg: in the Log view. I would love one of these that could do a good rebase-aware display of branching.

zamalek
0 replies
20h14m

This is my daily driver: it's awesome, and so appropriately simple. Do be aware that you will need to use Git proper if you want to sign commits.

pkulak
0 replies
10h55m

Last I tried this it required setting up an SSH agent to actually push anything… and I was just too lazy.

lolive
0 replies
11h44m

How can i test that [or LazyGit, btw] in my GitBash environnent, under Windows?

jethronethro
0 replies
21h34m

"[T]he comfort of a git GUI but right in your terminal"

facorreia
0 replies
20h15m

I use GitUI daily. It’s fast and I find it very useful to double check changes before committing.

divbzero
0 replies
16h14m

GitUI could be also named GiTUI.

dang
0 replies
20h17m

Related:

GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - Sept 2022 (90 comments)

Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - Dec 2020 (1 comment)

barbs
0 replies
10h21m

Is there a comparison with tig anywhere? Spose I should just download it myself and give it a go.

ChrisArchitect
0 replies
20h50m

(2020)

Ancapistani
0 replies
19h51m

This looks very much like the Noevim plugin I began using about a month ago: neogit[0].

The keybindings were a bit rough, and it took me about an hour of use before I was really comfortable with the overall workflow. Once I was, though, I’ve found it to be much faster than my previous workflow (suspending neovim and using git directly in the shell).

0: https://github.com/NeogitOrg/neogit