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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 10, 2026, 15:23 UTC
Message-ID: <xmqqldae6luz.fsf@gitster.g>
In-Reply-To: <26c2f7e0-03ef-4c45-8175-adcc2e0395ac@haller-berlin.de>

Stefan Haller <lists@haller-berlin.de> writes:

Show 17 quoted lines

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

Thanks.