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

51–60 of 224 posts

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

#51

Post by notpublic »

jmkmay wrote: post #45

Something not mentioned in the article which has changed the way I interact with git repos (and the reason I will never not use LazyVim until something better comes along) is just how well the system plays with tmux floating panes. I have it so that anytime I press ctrl-g in a git repo, I open a floating tmux pane in my current working directory. This might sound "whatever", but it means I don't have to actually be i…

Indeed! I just found out about tmux display-popup recently.

  # ~/.tmux.conf 
  bind-key C-g display-popup -E -d "#{pane_current_path}" -xC -yC -w 80% -h 75% "lazygit"
Then, in tmux:

  ctrl-b ctrl-g will open a popup window with lazygit
  q to quit

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

#52

Post by wingerlang »

Sammi wrote: post #36
CamJN wrote: post #28

Earlier 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.

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 this in Fork)

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

#54

Post by 1718627440 »

skydhash wrote: post #15
nicois wrote: post #12

A 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.

I see the usefulness. But my client is magit, and committing and rebasing are so quick that this will reduce perhaps 30 seconds to one minute to my workflow. And I do not like most rust tools, because they're too dependency heavy.

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.

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

#55

Post by 1718627440 »

kazinator wrote: post #49

"git gui" is not just a wrapper for commands; it has usefully different workflows. For instance, you can visually select a range of lines in a file, and stage those lines. This is much easier than doing "git add --patch" and using edit, where you are deleting unwanted lines starting with +, turning - lines into context and whatnot. I have found it useful to fire up "git gui" during rebase workflows with conflicts. It…

> For instance, you can visually select a range of lines in a file, and stage those lines.

Isn't this the standard for every Git GUI? Are there people who use a GUI that can't do that?

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

#56

Post by imiric »

nicois wrote: post #12

A 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.

I gave it a try a few months ago, and wasn't impressed. About a quarter of the time it got confused about the commit it should squash into, and left the repo in a half-applied state. This inconsistency was enough for me to not trust it when it did work, so I stopped using it.

Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.

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

#57

Post by 1718627440 »

krapht wrote: post #32
WolfeReader wrote: post #22

Earlier quoted context omitted.

As much as I heartily disagree with most of what you wrote - and seeing all the downvotes, I'm not the only one - there is a nugget of truth in what you wrote, which answers a lot of your complaints. "Using it was a harsh reminder of what people running emacs or vim for the first time have to go through." The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly mo…

> The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+. I have never been rate-limited by my keyboard input speed. I have lost many minutes of time daily looking up cheatsheets for terminal tools that I use occasionally. Ironically, when I see what impact AI has had on my programming, the biggest has been in…

The speed change you see is not due to raw input speed, but do to eliminating a context switch in the brain. I thinking I want to see X and already seeing it on the screen.

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

#58

Post by ericfr11 »

rc_kas wrote: post #29
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…

There are few UI's that I hate more in the world than SourceTree. That pile of junk has cost me so many hours of life trying to support the developers in fixing a thousand weird issues. No, please throw SourceTree into the garbage can.

I've used SourceTree for years, and for advanced flows, with an external tool for diff. Never failed me from the base, squash, orphans, forks,...

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

#59

Post by skydhash »

1718627440 wrote: post #54
skydhash wrote: post #15

Earlier quoted context omitted.

I see the usefulness. But my client is magit, and committing and rebasing are so quick that this will reduce perhaps 30 seconds to one minute to my workflow. And I do not like most rust tools, because they're too dependency heavy.

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.
Post reply on HN