If you're on Windows and you like the git CLI, try GitExtensions. It maps pretty much 1-to-1 to the git CLI and is still discoverable.
The lazy Git UI you didn't know you need
121–130 of 224 posts
Re: The lazy Git UI you didn't know you need
#122Earlier quoted context omitted.
I’ve used SourceTree for a decade, Fork is the only one I’ve switched to partially (at work). I probably will switch back to ST even at work because I dislike: - I want the split view of ST where I can simply see the changes and not lose the commit log. - “see only current branch” is super useful in ST to see only the current branch’s commit log. (Partially writing this in hopes of someone pointing out ways to do thi…
You can do "see only current branch" with the little filter icon when you hover next to a branch. Although I do find myself getting lost amongst branches more easily compared to Sourcetree, I think there's some difference in how filters are combined that isn't ideal (but I can't remember specifics)
You can also go to View in the menu and click "Filter by active branch" (Ctrl+Shift+A).
Also if you, like me, wanted to blame or view history for specific files there does not seem to be a way by clicking in the GUI to achieve it. But by using Ctrl+P you get the command search and can search for "Blame" or "File history".
Re: The lazy Git UI you didn't know you need
#123I recently started working on a repo which historically had 100+ parallel branches. I've been jumping between a few tools recently trying to find something which handles browsing these sanely - I always liked browsing graphs, but the sheer amount of branches ruins most of them.
Currently the best workflow I've worked out is just a plain
git log --oneline --graph --
Re: The lazy Git UI you didn't know you need
#124Lazygit is the only way I review PRs these days because it is trivial to step through a file commit by commit when that is necessary (which maybe says something about the quality of the PRs I'm reviewing...). They also won me over by using Legend of the Galactic Heroes references in the github readme gifs.
Glad somebody got the reference!
Re: The lazy Git UI you didn't know you need
#125I was a big fan of a good keyboard-driven git TUI like magit, neogit, lazygit, etc... (as long as you learn the CLI first and understand it). Now I no longer directly use git, but instead use jujutsu (jj). Once I became very proficient in the jj cli, I picked up jjui: https://github.com/idursun/jjui Also, as splitting commits is an extremely frequent operation, this neovim plugin is really nice: https://github.com/ju…
I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd…
If you could make it opinionated in one or two ways, how would you do it? I'm having a hard time thinking about situations that would be solved by this
Re: The lazy Git UI you didn't know you need
#126A large percentage of git users are unaware of git-absorb ( https://github.com/tummychow/git-absorb ). This complements just about any git flow, vastly reducing the pain of realising you want to amend your staged changes into multiple commits. This sits well alongside many TUIs and other tools, most of which do not offer any similar capability.
to me this appears to be trading off a valid change log for neat naming ... i dont see why rewriting history is ever a good idea
I find it quite hard to follow PRs when there is a lot of rebasing. I don't really find separate non-time-based commits useful.
So I agree but unfortunately it's the norm and policy for some clients.
Git-absord by default doesn't squash the fixups though, it creates new ones with special tags for easy rebasing later.
Re: The lazy Git UI you didn't know you need
#127> This site was paused as it reached its usage limits.
https://web.archive.org/web/20251111071832/https://www.bwplo...
Re: The lazy Git UI you didn't know you need
#128Earlier quoted context omitted.
I have tried jj several times but I feel like it slows me down significantly because I can’t grok the workflow. I like to do a bunch of changes then quickly select them in my editor and commit them, breaking them up into different commits to keep them organized. With jj’s lack of editor integration, I don’t know how to do this with the cli alone so I end up with bigger messier commits.
You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.
With git I can stage lines right in my IDE, no messing around in shitty TUIs.
Re: The lazy Git UI you didn't know you need
#129Earlier quoted context omitted.
I find both Fork and Tower to be much better than SourceTree, have you only tried free tools?
I can't live without Fork. It's the one thing I miss on Linux. I have it in Wine, but it's running terribly there unfortunately.
Another vote for Fork here. Used to use many different UI clients, including ST and Tower but left Tower for Fork. I still add P4 Merge as my external merge tool though. It seems to have the best algorithm and often solves conflicts automatically.
Re: The lazy Git UI you didn't know you need
#130I'm the "git guy" at every place I work and I don't touch the git CLI. Been using Magit for 15 years now. I just don't think a CLI is a good interface for state mutation.
CLIs are perfect for functional interfaces, like grep, sed etc. But I think they are very hard to get right when side effects are in play. Really basic things like mkdir and rm are ok, but when you have enormously powerful things like git rebase I find it difficult to keep track of what's going on.
I wonder what a more functional Unix would look like... Instead of mkdir just write to any path, instead of rm just overwrite a path with nothing, maybe we'd accept that mv would be implemented as "porcelain". The balance I think is keeping a lid on how complex that porcelain can become, and git has way overstepped the mark. So I prefer GUI/TUI interfaces for mutation, and Emacs is the best there is for building those.