Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lazy Git UI you didn't know you need

bwplotka.dev

Post reply on HN
Print view View original

151–160 of 224 posts

Re: The lazy Git UI you didn't know you need

#151

Post by gpderetta »

skydhash wrote: post #59
1718627440 wrote: post #54

Earlier quoted context omitted.

The task that absorb speeds up is finding the commit where each hunk was last changed. The actual committing and rebaseing is still basically the same.

Git blame using `M-x vc-annotate` with Emacs. But If I have a clean PR that usually means one to three commits (If it's not a big refactoring). So the whole point become moot. In magit, if you create a fixup or a squash commit, it will present you with the log to select the target.

Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.

Re: The lazy Git UI you didn't know you need

#152

Post by stavros »

promiseofbeans wrote: post #72

People often avoid it because of the name, but Github desktop is pretty amazing. It works great with all git repos (including ones not on Github), and makes it super easy to amend commits and cherry-pick files/lines to include. Everything has handy names, and all the complex operations have text explaining what they do. GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired, but it's alrea…

> it's already 1000 times better than the git cli

Sure, but that's such a low bar, that everything clears it.

Re: The lazy Git UI you didn't know you need

#153

Post by fergonco »

I have some bash_aliases and scripts.

The king of all alias is fixup, which commits everything and fixes up the commit with the previous one.

Another script just goes over the changes and allows me to add/skip/restore.

Then I can pipe the log to another script that will analyze tags and tell me what is not yet in prod.

cli is hard... but it composes. I want to know that CLI as well as possible. And I don't want to start from scratch each few years with a new UI / concept.

Re: The lazy Git UI you didn't know you need

#154

Post by robin_reala »

keyle wrote: post #63

Lazygit is great, I use it all the time for straight forward git-fu. I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache. But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does…

To be clear, there isn’t a free version. There’s a cost-less download that’s meant for evaluation purposes, with the goal of paying them if you like it and find yourself using it long-term.

Given that Fork is a two-person family company that’s somehow managed to make the best Git client in the world for a single reasonable price with free updates and no subscription, I’d suggest that it’s worth paying for to keep their business sustainable.

Re: The lazy Git UI you didn't know you need

#155

Post by gpderetta »

keyle wrote: post #63

Lazygit is great, I use it all the time for straight forward git-fu. I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache. But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does…

--force-with-lease should be safer.

Re: The lazy Git UI you didn't know you need

#156

Post by chrisan »

jonathanlydall wrote: post #132
prmph wrote: post #7

You might laugh, but in years of serious development, I have not come across a better git UI tool than SourceTree. If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried. Its file status and history view is…

On Windows I've been using TortoiseGit for over a decade now and in terms of Git power user features in a GUI I think it's unmatched. People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head. A GUI really makes a lot of sense for something like Git, most of the time what you…

Man, those are 2 apps I haven't touched in decades. They felt novel at the time, but they just aren't as fast for me since it requires leaving my IDE which already has both CLI and visual git methods (I use intellij products)

Re: The lazy Git UI you didn't know you need

#157

Post by 1718627440 »

gpderetta wrote: post #151
skydhash wrote: post #59

Earlier quoted context omitted.

Git blame using `M-x vc-annotate` with Emacs. But If I have a clean PR that usually means one to three commits (If it's not a big refactoring). So the whole point become moot. In magit, if you create a fixup or a squash commit, it will present you with the log to select the target.

Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.

> I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.

It is not, but git absorb only produces fixup commits, you can still change what they change in the autosquash step.

Re: The lazy Git UI you didn't know you need

#158

Post by gfna »

stevoski wrote: post #117

Anyone used GitKraken? I haven’t, but for reasons, I’m interested to hear about your experience with it.

Been using gitkraken for ages and still like it, but they do make it harder and harder to like every update. The enshittification seems to have started and every update seems to bring more and more ai features, and pushing more ”cloud” features as well

Re: The lazy Git UI you didn't know you need

#159

Post by pqdbr »

IshKebab wrote: post #46
prmph wrote: post #7

You might laugh, but in years of serious development, I have not come across a better git UI tool than SourceTree. If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried. Its file status and history view is…

It's pretty good but also really slow. I never found one better than GitX, but that was in the days before IDEs had Git support built in. Now they do it doesn't really make sense to use a separate program IMO. These days I use VSCode and the Git Graph extension.

+1 for GitX. For some reason the most recent version in GitHub doesn't work well for me anymore, so I keep an extremely old version (Version 0.15.1964 dev (0.15.1964) in a Dropbox folder and it's my daily driver for years.

Re: The lazy Git UI you didn't know you need

#160

Post by greenicon »

__float wrote: post #105
wredcoll wrote: post #102

Earlier quoted context omitted.

I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.

I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight. A tool like https://github.com/tummychow/git-absorb has been on my to-try list for a while, but for now I do it by hand.

git absorb works surprisingly well. I was quite skeptical in the beginning, but it really turned into something I used daily (until I switched to jj, where I haven't found a replacement yet). If you use stepwise commits I can really recommend it.

small edit: It seems that jj supports `jj absorb` now as well. Wonderful!

Post reply on HN