I’ve been using TortoiseGit since the beginning, but it's Windows-only.
In TortoiseGit, the Log view is my single entry point to all regular and semi-regular operations.
Occasionally, I use native git CLI to manage refs (archive old tags into a different ref path, mass-remote-delete, etc).
Originally, it was a switch from TortoiseSVN to TortoiseGit, and from then on, no other GUI or TUI met my needs and wants. I explored/tried out many alternative GUIs and TUIs over the years, but none felt as intuitive, gave as much overview, or capabilities. Whenever I'm in Visual Studio and use git blame, I'm reminded that it is lacking - in the blame view you can't blame the previous versions to navigate backwards through history within a code view. I can do that in TortoiseGit.
I've also tried out Gitbutler and jj, which are interesting in that they're different. Ultimately, they couldn't convince me for regular use when git works well enough and additional tooling can introduce new complexities and issues when you don't make a full switch. I remember Gitbutler added refs making git use impractical. jj had a barrier to entry, to understand and follow the concepts and process, which I think I simply did not pass yet to have a more accurate assessment.
I did explore TUIs also as no-install-required fallback alternatives, but in practice, I never needed them. When I do use the console, I'm familiar with native git to cover my needs. Remote shell: native git, locally: Nushell on top of native git for mass queries and operations.
When I was researching keyboards recently, I stumbled over a pro gamer (I believe) YouTuber who was quite vocal about pretty much all gear marketed as "gaming gear" is overpriced marketing bullshit. Apparently, they tested dozens of keyboards, mice, and headsets over the years. It certainly matched my impression of reading tests about products previously.
"Gamer" chairs are racecar chairs meant to keep you from sliding sideways, not being fit for long sitting sessions on a PC. Prefer a good or decent office chair. "Gamer" headsets are worse and more expensive than other headsets. Keyboards and mice are mostly marketing. etc.
Regarding input, they made a point about physical human limitations and state like sleep and caffeine intake having much more of an effect than the hardware you use.
2022 update
So this article is quite old. There are keyboard switches now that activate as soon as you activate the key, and that can recognize lift and press without passing a trigger point. If you want that kind of edge, those are the top performers right now. I'd be more interested in the technology and maybe playful capabilities than the performance they add.
I'm always way too thorough when researching products before buying…
Brave webbrowser attempted something like that with Brave Rewards, but through ads, and basically collected for themselves until the websites actually signed up for Brave Rewards.
Why does nothing link to the content/MS page in question? Not this article, nor the Bluesky post or replies.
I would have liked to see and verify the context, and explore the git history which should lead to some context that may give some context to what the author asks at the end: How did it come to be, with what ideas or goals, or justification, etc.
The Bluesky replies mention(/claim) that the image has been replaced, now seemingly copying a graph from Atlassian docs.
Maybe I will look into more. :) I've known about fzf but I guess never gotten around to fully evaluating and integrating it.
Nushell supports fuzzy completions, globbing, and "menus" (TUI) natively. Still, the TUI aspect and possibly other forms of integrations seem like they could be worthwhile or useful as extensions.
For software to be perfect, can not be improved no matter what, you'd have to define a very specific and narrow scope and evaluate against that.
Environments change, text and data encoding and content changes, forms and protocol of input and output changes, opportunities and wishes to integrate or extend change.
pwd seems simple enough. cd I would already say no, with opportunities to remember folders, support globbing, fuzzy matching, history, virtual filesystems. Many of those depend on the environment you're in. Typically, shells handle globbing. There's alternative cd tools that do fuzzy matching and history, and virtual filesystems are usually abstracted away. But things change. And I would certainly like an interactive and fuzzy cd.
Now, if you define it's scope, you can say: "All that other stuff is out of scope. It's perfect within it's defined target scope." But I don't know if that's what you're looking for? It certainly doesn't mean it can't be improved no matter what.
I don't see anything as having to come before learning Rust.
If something about Rust requires more technical knowledge, then that learning is part of learning Rust, even if you could have learned it separately beforehand.
Better start learning Rust to get in there instead of delaying, which adds risk to never arriving, loss of interest, or lack of progress on the goal of learning Rust, with a lack of satisfaction.
Once you learned Rust, you can look around to gain broader knowledge and expertise, if you want, but that's not necessary to learn and make use of Rust.
No, it's not on the user's end. It's because you didn't use correct Markdown syntax for your link. I verified this in your post source before commenting.
You used: [https://joinhideout.vercel.app/]() - which is a link without a target, so it defaults to this page we're on.
Great analysis / report. At times a bit repetitive, but that could be useful for people skimming or jumping or quoting as well.
Despite 91% of CTOs citing technical debt as their biggest challenge, it doesn’t make the top five priorities in any major CIO survey from 2022–2024.
Sad. Tragic.
I'm lucky to be in a good, small company with a good, reasonable customer, where I naturally had and grew into having the freedom and autonomy to decide on things. The customer sets priorities, but I set mine as well, and tackle what's appropriate or reasonable/acceptable. Both the customer and I have the same goals after all, and we both know it and collaborate.
Of course, that doesn't help me as a user when I use other software.
Reading made me think of the recent EU digital regulations. Requiring due diligence, security practices, and transparency. It's certainly a necessary and good step in the right direction to break away from the endless chase away from quality, diligence, and intransparency.
I’ve been using TortoiseGit since the beginning, but it's Windows-only.
In TortoiseGit, the Log view is my single entry point to all regular and semi-regular operations.
Occasionally, I use native
gitCLI to manage refs (archive old tags into a different ref path, mass-remote-delete, etc).Originally, it was a switch from TortoiseSVN to TortoiseGit, and from then on, no other GUI or TUI met my needs and wants. I explored/tried out many alternative GUIs and TUIs over the years, but none felt as intuitive, gave as much overview, or capabilities. Whenever I'm in Visual Studio and use git blame, I'm reminded that it is lacking - in the blame view you can't blame the previous versions to navigate backwards through history within a code view. I can do that in TortoiseGit.
I've also tried out Gitbutler and
jj, which are interesting in that they're different. Ultimately, they couldn't convince me for regular use when git works well enough and additional tooling can introduce new complexities and issues when you don't make a full switch. I remember Gitbutler added refs making git use impractical. jj had a barrier to entry, to understand and follow the concepts and process, which I think I simply did not pass yet to have a more accurate assessment.I did explore TUIs also as no-install-required fallback alternatives, but in practice, I never needed them. When I do use the console, I'm familiar with native
gitto cover my needs. Remote shell: native git, locally: Nushell on top of native git for mass queries and operations.