[HN Gopher] GitUI
___________________________________________________________________
GitUI
Author : jethronethro
Score : 166 points
Date : 2024-01-07 20:53 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jethronethro wrote:
| "[T]he comfort of a git GUI but right in your terminal"
| BaculumMeumEst wrote:
| i would be interested to see what proportion of rust projects put
| "written in rust" in the project description vs other languages
| Takennickname wrote:
| This one is fine.
|
| The funny ones are the ones that put "Written in Rust" in the
| features section.
| rrr_oh_man wrote:
| Reminds of those terrible startup pitch competitor comparison
| tables
| codetrotter wrote:
| Probably similar to the the percentage for projects written in
| Go.
| motza wrote:
| Not as many as Go
| Daeraxa wrote:
| Blazingly fast
| sbarre wrote:
| 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 wrote:
| I agree, I generally tend to prefer rust tools, like
| Alacrity.
| zemo wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pama wrote:
| "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 wrote:
| Yeah, I never do a big merge in magit. I just use the git CLI
| for those.
| jonwest wrote:
| 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 wrote:
| 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 wrote:
| I was missing interactive rebase, as it is missing from
| libgit2
|
| https://github.com/extrawurst/gitui/issues/32
| rrr_oh_man wrote:
| 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 |
| ChrisArchitect wrote:
| (2020)
| hesdeadjim wrote:
| Ah bummer, no LFS support.
| amelius wrote:
| And no sparse repo support.
| platz wrote:
| the sticky wicket really is a nice way to do interactive rebasing
| & resolve merge conflicts without complex external app
| configuration
| 38 wrote:
| what the fuck is a sticky wicket
| swiftcoder wrote:
| A cricket (the sport) metaphor. What it means here is however
| a mystery
| nineteen999 wrote:
| https://en.wikipedia.org/wiki/Sticky_wicket
| badsectoracula wrote:
| > 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).
| yetanother12345 wrote:
| 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 (satire!), 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?
| zmmmmm wrote:
| 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 wrote:
| 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)
| facorreia wrote:
| I use GitUI daily. It's fast and I find it very useful to double
| check changes before committing.
| nomilk wrote:
| 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 wrote:
| I use it exclusively for paroosing/double-checking my changes
| and staging (especially individual hunks).
| philsnow wrote:
| > 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) ?
| insin wrote:
| 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 wrote:
| How does this differ from git commit --patch?
| zamalek wrote:
| 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.
| abdullahkhalids wrote:
| Has anyone made a click-and-drag UI for git? Where you can do
| operations on branches by just dragging them around.
| Ancapistani wrote:
| 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
| bananapub wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-07 23:00 UTC)