Re: Alternative to manual editing with git add --patch

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2015, 17:50 UTC
Message-ID: <xmqqk2qp8hlj.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <561E6FBB.7060302@gmx.de>

Sven Helmberger <sven.helmberger@gmx.de> writes:

Show 12 quoted lines

> I hope this hasn't been discussed before.
>
> I'm a big fan of cleanliness in commits and therefore often use git add
> --patch to sort code changes I made into the right commits etc.
>
> What I then often encountered was the situation where I happened to have
> inserted consecutive lines of code that conceptually belong to different
> commits. Normally I can nicely split patches, but not in this case,
> making manually editing the patch the only alternative.
>
> Shouldn't there be at least a way to quickly say line-by-line if you
> want to have it added or not?

I think this has been discussed a few times (and you should actually hope that is the case---it shows that something that allows you to split a hunk that consists of consecutive lines is not an obscure and useless feature wish). But I do not think we saw anybody came up with a convincingly usable design (not the code design but how the user interaction specifies where the hunk is cut in the first place), let alone a prototype for it, so that we can discuss further. At least not yet.

As a quick-and-dirty change, you could invent a new variant of 's'plit that breaks a N-line hunk into N hunks with 1-line each, but obviously that would not be a pleasant-enough UI to be called usable when you have a hunk that adds 100 lines. Perhaps "Split this hunk into two by ending the earlier one immediately before the line that has this substring" or something might be an idea?