Re: Can we do better than "git checkout/add -p"

On Mon, Aug 10, 2026 at 08:23:00AM -0700, Junio C Hamano wrote:
> Stefan Haller <[email protected]> writes:
> 
> > On 10.08.26 08:03, Patrick Steinhardt wrote:
> >> I've been playing around with the thought of introducing ncurses-based
> >> interfaces into Git. I've been mostly thinking about git-history(1) here
> >> so that you can just move commits around, squash them together, drop
> >> them and so on. But I think fancy stuff like TUIs can also be applied to
> >> other parts of Git, as well, to make things a bit more visual to our
> >> users and, as a consequence, easier to use.
> >
> > That sounds a whole lot like lazygit to me [1]; it does all those things
> > in a rather intuitive way, including Junio's original use case of
> > selecting a hunk and staging or discarding it.
> >
> > Is it really worth adding such functionality to core git? I like the
> > idea of tools specializing on what they do well; core git on providing
> > the core functionality, GUI tools on presenting it in a UI.
> >
> > [1] https://github.com/jesseduffield/lazygit
> 
> My philosophy has always been "do not compete with your customer".
> 
> If we add an officially sanctioned XYZ to 'git-core', it would hold
> an undue advantage over tools built on 'git-core' that perform the
> same task, not because ours is implemented better but merely
> because it comes bundled with 'git-core'.  I do not want that.
> 
> An exception is when our XYZ is truly of "we wish someone had
> written something better that offers functionality like this"
> quality, serving as a "usable but perhaps not pretty" demonstration.

I guess that's fair. As I said in my parallel reply to this message, I
could also see that having something like a git-history(1) UI might be
too much. But I think having a TUI for selecting individual hunks in a
better way compared to `git add -i` and friends might be sensible and
not significantly overlap with other projects.

Patrick