GitUI(github.com)
github.com
GitUI
https://github.com/extrawurst/gitui
108 comments
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.
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.
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.
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.
> 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.
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.
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
I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.
I cannot judge whether the methodology makes sense, but the numbers seem quite impressive for my manager brain:
> Readme.md
> 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 |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.
I will always take faster tools, but sometimes things are good enough.
I found the memory gains to be more enticing than the performance improvements
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?
"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?
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.
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.
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.
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.
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.
That seems like a problem that could and should be solved.
It's not a bug, but a feature. No cache is by design.
There's nothing stopping Git from storing its state in an sqlite db.
IntelliJ has, imho, the most comprehensive & visual diff management UI. That thing alone discards any competitor [once again, imho].
[deleted]
Yeah, I never do a big merge in magit. I just use the git CLI for those.
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)
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)
Has anyone made a click-and-drag UI for git? Where you can do operations on branches by just dragging them around.
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).
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.
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.
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.
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
[0] e.g. https://www.git-tower.com/pricing/mac
did you evaluate GitExtensions?
I'm not sure what's kind of of operations could be done by "dragging branches around", but in GitKraken
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.
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:
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.
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...
https://marketplace.visualstudio.com/items?itemName=trunkflo...
Even after 10 years, SourceTree is still my goto when I need UI click-and-drag.
Not exactly git, but meta's version of mercurial (I think it's called sapling) has this, you can rebase really easily your commits.
Git Tower for Mac works great for this
Sublime Merge
GitKraken
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.
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.
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.
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.
Only other git UI that's comes close to it is Tortoise, of which I've only used the hg variant a while back.
Gitex is fantastic. I'm still using the 2x mono version on Linux.
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.
No other git ui program has ever come close to how naturally I feel using a context menu based system like tortoisegit.
GitUI could be also named GiTUI.
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
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
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.
Idk if it applies to this one. Just thought that this feedback could be interesting for tools from this category.
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.
It always shows complete commands it issues, and you can fully view the complete log.
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?
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.
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.
`git add -p`
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.
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.
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.
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.
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
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
- (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
- 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
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.
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
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.
It's fully compatible with git.
What I used to need a GUI for now I can easily do with jj.
"[T]he comfort of a git GUI but right in your terminal"
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.
Out of curiosity, what specific tasks are easier using a GUI? (I've never used one; keen to learn if I'm missing out)
> 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.
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.
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.
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.
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.
How does this differ from git commit --patch?
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).
`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).
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.
GUI stuff is not necessarily about enabling new workflows so much as making workflows _very fast_ and less error prone. In theory at least.
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".
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".
I use it exclusively for paroosing/double-checking my changes and staging (especially individual hunks).
Is there a comparison with tig anywhere? Spose I should just download it myself and give it a go.
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.
Ex emacs user, still run emacs for magit. Use it hourly.
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.
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?
> 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?
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.
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.
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.
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.
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.
> 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.
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.
Thanks all below, I was not aware. I'm (a little) wiser now.
Last I tried this it required setting up an SSH agent to actually push anything… and I was just too lazy.
I use GitUI daily. It’s fast and I find it very useful to double check changes before committing.
How can i test that [or LazyGit, btw] in my GitBash environnent, under Windows?
i would be interested to see what proportion of rust projects put “written in rust” in the project description vs other languages
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
This one is fine.
The funny ones are the ones that put "Written in Rust" in the features section.
The funny ones are the ones that put "Written in Rust" in the features section.
Reminds of those terrible startup pitch competitor comparison tables
Probably similar to the the percentage for projects written in Go.
Not as many as Go
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.
I guess it could be seen as a point of maturity at this point, when projects stop adding those suffixes.
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.
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.
I agree, I generally tend to prefer rust tools, like Alacrity.
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.
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.
Written in Go/Rust is definitely a feature for something like this.
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.
[deleted]
the sticky wicket really is a nice way to do interactive rebasing & resolve merge conflicts without complex external app configuration
what the fuck is a sticky wicket
that doesn't help...
It's a bad sporting metaphor that doesn't really relate to how the writer used it
A cricket (the sport) metaphor. What it means here is however a mystery
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).