7 ms·

GitUI

405 points by jethronethro 3y ago

abdullahkhalids 3y ago
Has anyone made a click-and-drag UI for git? Where you can do operations on branches by just dragging them around.
- kentosi 3y ago
  Even after 10 years, SourceTree is still my goto when I need UI click-and-drag.
- Yasuraka 3y ago
  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=trunkflow.trunk-flow https://marketplace.visualstudio.com/items?itemName=trunkflo...
- danielhep 3y ago
  Git Tower for Mac works great for this
- charrondev 3y ago
  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.
- ric2b 3y ago
  GitKraken
- BerislavLopac 3y ago
  I'm not sure what's kind of of operations could be done by "dragging branches around", but in GitKraken
  - drak0n1c 3y ago
    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 3y ago
      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:
- nurgasemetey 3y ago
  Sublime Merge
- memco 3y ago
  My favorite got GUI is Fork: https://git-fork.com/ https://git-fork.com/ It supports drag and drop for several operations including merge, rebase, and stage/unstage (and probably more).
  - ap-andersson 3y ago
    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.
    - namtab00 3y ago
      did you evaluate GitExtensions?
    - stsrki 3y ago
      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 3y ago
        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 https://www.git-tower.com/pricing/mac
- eddd-ddde 3y ago
  Not exactly git, but meta's version of mercurial (I think it's called sapling) has this, you can rebase really easily your commits.
jethronethro 3y ago
"[T]he comfort of a git GUI but right in your terminal"
BaculumMeumEst 3y ago
i would be interested to see what proportion of rust projects put “written in rust” in the project description vs other languages
- Takennickname 3y ago
  This one is fine. The funny ones are the ones that put "Written in Rust" in the features section.
  - rrr_oh_man 3y ago
    Reminds of those terrible startup pitch competitor comparison tables
- codetrotter 3y ago
  Probably similar to the the percentage for projects written in Go.
  - motza 3y ago
    Not as many as Go
    - diggan 3y ago
      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.
- Daeraxa 3y ago
  Blazingly fast
  - awson 3y ago
    And using `libgit2`, written in C, for heavy-lifting.
pama 3y ago
"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?
- eddieh 3y ago
  Yeah, I never do a big merge in magit. I just use the git CLI for those.
- lolinder 3y ago
  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 3y ago
    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 3y ago
      That seems like a problem that could and should be solved.
      - machomaster 3y ago
        It's not a bug, but a feature. No cache is by design.
        mschuster91 3y ago
jonwest 3y ago
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.
- NERD_ALERT 3y ago
  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 3y ago
    I was missing interactive rebase, as it is missing from libgit2 https://github.com/extrawurst/gitui/issues/32 https://github.com/extrawurst/gitui/issues/32
  - piersolenski 3y ago
    I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.
- rrr_oh_man 3y ago
  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 3y ago
    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.
ChrisArchitect 3y ago
(2020)
- deleted 3y ago
  [deleted]
hesdeadjim 3y ago
Ah bummer, no LFS support.
- amelius 3y ago
  And no sparse repo support.
platz 3y ago
the sticky wicket really is a nice way to do interactive rebasing & resolve merge conflicts without complex external app configuration
- 38 3y ago
  what the fuck is a sticky wicket
  - nineteen999 3y ago
    https://en.wikipedia.org/wiki/Sticky_wicket https://en.wikipedia.org/wiki/Sticky_wicket
    - 38 3y ago
      that doesn't help...
      - nineteen999 3y ago
        It's a bad sporting metaphor that doesn't really relate to how the writer used it
  - swiftcoder 3y ago
    A cricket (the sport) metaphor. What it means here is however a mystery
badsectoracula 3y ago
> 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 3y ago
  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.
yetanother12345 3y ago
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?
- not_the_fda 3y ago
  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.
- steveklabnik 3y ago
  I mean, there's tools that make it easy to make a .deb https://crates.io/crates/cargo-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.
- mschuster91 3y ago
  > 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.
- yetanother12345 3y ago
zmmmmm 3y ago
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.
dang 3y ago
Related: GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 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 https://news.ycombinator.com/item?id=25504811 - Dec 2020 (1 comment)
facorreia 3y ago
I use GitUI daily. It’s fast and I find it very useful to double check changes before committing.
nomilk 3y ago
Out of curiosity, what specific tasks are easier using a GUI? (I've never used one; keen to learn if I'm missing out)
- zamalek 3y ago
  I use it exclusively for paroosing/double-checking my changes and staging (especially individual hunks).
  - philsnow 3y ago
    > 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 3y ago
      Probably, dyslexia can be like that.
- insin 3y ago
  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 3y ago
    How does this differ from git commit --patch?
    - halostatue 3y ago
      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 3y ago
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.
Ancapistani 3y ago
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 https://github.com/NeogitOrg/neogit
bananapub 3y ago
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 3y ago
  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 3y ago
  Ex emacs user, still run emacs for magit. Use it hourly.
glitchc 3y ago
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.
- Spunkie 3y ago
  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.
- nichos 3y ago
  Gitex is fantastic. I'm still using the 2x mono version on Linux.
- namtab00 3y ago
  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.
divbzero 3y ago
GitUI could be also named GiTUI.
Sleaker 3y ago
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?
- StimDeck 3y ago
  I am perfectly comfortable with CLI git, certainly when measured against my peers, but I still prefer the visual tree, context menus, command palette, etc. I like to right click and edit commit messages. I like to copy branch names. I like to do visual three way merges. I can understand what went wrong more quickly when a PR has unexpected changes. I can see what branches are in origin at a glance. I don’t have to remember the name or hash of anything.
- zdimension 3y ago
  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 3y ago
    Lately I've been using this: https://martinvonz.github.io/jj/v0.10.0/ 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.
- aulin 3y ago
  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.
lolive 3y ago
How can i test that [or LazyGit, btw] in my GitBash environnent, under Windows?
pkulak 3y ago
Last I tried this it required setting up an SSH agent to actually push anything… and I was just too lazy.
barbs 3y ago
Is there a comparison with tig anywhere? Spose I should just download it myself and give it a go.
wruza 3y ago
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 3y ago
  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.

GitUI

405 points by jethronethro 3y ago

abdullahkhalids 3y ago

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

kentosi 3y ago
Even after 10 years, SourceTree is still my goto when I need UI click-and-drag.
Yasuraka 3y ago
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=trunkflow.trunk-flow https://marketplace.visualstudio.com/items?itemName=trunkflo...
danielhep 3y ago
Git Tower for Mac works great for this
charrondev 3y ago
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.
ric2b 3y ago
GitKraken
BerislavLopac 3y ago
I'm not sure what's kind of of operations could be done by "dragging branches around", but in GitKraken
- drak0n1c 3y ago
  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 3y ago
    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:
nurgasemetey 3y ago
Sublime Merge
memco 3y ago
My favorite got GUI is Fork: https://git-fork.com/ https://git-fork.com/ It supports drag and drop for several operations including merge, rebase, and stage/unstage (and probably more).
- ap-andersson 3y ago
  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.
  - namtab00 3y ago
    did you evaluate GitExtensions?
  - stsrki 3y ago
    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 3y ago
      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 https://www.git-tower.com/pricing/mac
eddd-ddde 3y ago
Not exactly git, but meta's version of mercurial (I think it's called sapling) has this, you can rebase really easily your commits.

jethronethro 3y ago

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

BaculumMeumEst 3y ago

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

Takennickname 3y ago
This one is fine. The funny ones are the ones that put "Written in Rust" in the features section.
- rrr_oh_man 3y ago
  Reminds of those terrible startup pitch competitor comparison tables
codetrotter 3y ago
Probably similar to the the percentage for projects written in Go.
- motza 3y ago
  Not as many as Go
  - diggan 3y ago
    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.
Daeraxa 3y ago
Blazingly fast
- awson 3y ago
  And using `libgit2`, written in C, for heavy-lifting.

pama 3y ago

"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?

eddieh 3y ago
Yeah, I never do a big merge in magit. I just use the git CLI for those.
lolinder 3y ago
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 3y ago
  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 3y ago
    That seems like a problem that could and should be solved.
    - machomaster 3y ago
      It's not a bug, but a feature. No cache is by design.
      - mschuster91 3y ago

jonwest 3y ago

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.

NERD_ALERT 3y ago
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 3y ago
  I was missing interactive rebase, as it is missing from libgit2 https://github.com/extrawurst/gitui/issues/32 https://github.com/extrawurst/gitui/issues/32
- piersolenski 3y ago
  I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.
rrr_oh_man 3y ago
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 3y ago
  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.

ChrisArchitect 3y ago

(2020)

deleted 3y ago
[deleted]

hesdeadjim 3y ago

Ah bummer, no LFS support.

amelius 3y ago
And no sparse repo support.

platz 3y ago

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

38 3y ago
what the fuck is a sticky wicket
- nineteen999 3y ago
  https://en.wikipedia.org/wiki/Sticky_wicket https://en.wikipedia.org/wiki/Sticky_wicket
  - 38 3y ago
    that doesn't help...
    - nineteen999 3y ago
      It's a bad sporting metaphor that doesn't really relate to how the writer used it
- swiftcoder 3y ago
  A cricket (the sport) metaphor. What it means here is however a mystery

badsectoracula 3y ago

> 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 3y ago
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.

yetanother12345 3y ago

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?

not_the_fda 3y ago
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.
steveklabnik 3y ago
I mean, there's tools that make it easy to make a .deb https://crates.io/crates/cargo-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.
mschuster91 3y ago
> 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.
yetanother12345 3y ago

zmmmmm 3y ago

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.

dang 3y ago

Related: GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 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 https://news.ycombinator.com/item?id=25504811 - Dec 2020 (1 comment)

facorreia 3y ago

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

nomilk 3y ago

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

zamalek 3y ago
I use it exclusively for paroosing/double-checking my changes and staging (especially individual hunks).
- philsnow 3y ago
  > 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 3y ago
    Probably, dyslexia can be like that.
insin 3y ago
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 3y ago
  How does this differ from git commit --patch?
  - halostatue 3y ago
    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 3y ago

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.

Ancapistani 3y ago

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 https://github.com/NeogitOrg/neogit

bananapub 3y ago

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 3y ago
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 3y ago
Ex emacs user, still run emacs for magit. Use it hourly.

glitchc 3y ago

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.

Spunkie 3y ago
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.
nichos 3y ago
Gitex is fantastic. I'm still using the 2x mono version on Linux.
namtab00 3y ago
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.

divbzero 3y ago

GitUI could be also named GiTUI.

Sleaker 3y ago

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?

StimDeck 3y ago
I am perfectly comfortable with CLI git, certainly when measured against my peers, but I still prefer the visual tree, context menus, command palette, etc. I like to right click and edit commit messages. I like to copy branch names. I like to do visual three way merges. I can understand what went wrong more quickly when a PR has unexpected changes. I can see what branches are in origin at a glance. I don’t have to remember the name or hash of anything.
zdimension 3y ago
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 3y ago
  Lately I've been using this: https://martinvonz.github.io/jj/v0.10.0/ 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.
aulin 3y ago
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.

lolive 3y ago

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

pkulak 3y ago

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

barbs 3y ago

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

wruza 3y ago

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 3y ago
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.