Re: [PATCH] Teach git-gui to split hunks
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 13, 2007, 08:45 UTC
- Message-ID
- <7vhcin3rv4.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <Pine.LNX.4.64.0712121931050.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> For this to work, apply has to be called with --unidiff-zero, since > the new hunks can start or stop with a "-" or "+" line.
You do not have to do "unidiff zero". Suppose you have this hunk you need to split.
diff --git a/read-cache.c b/read-cache.c index 7db5588..4d12073 100644 --- a/read-cache.c +++ b/read-cache.c @@ -12,8 +12,8 @@ /* Index extensions. * * The first letter should be 'A'..'Z' for extensions that are not - * necessary for a correct operation (i.e. optimization data). - * When new extensions are added that _needs_ to be understood in + * necessary for a correct operation (that is, optimization data). + * When new extensions are added that needs to be understood in * order to correctly interpret the index file, pick character that * is outside the range, to cause the reader to abort. */ Think about taking the s/i.e./that is,/ substitution without taking the other s/_needs_/needs/ substitution. You do not split the hunk between two '-' lines, but effectively make it into this hunk instead: diff --git a/read-cache.c b/read-cache.c index 7db5588..4d12073 100644 --- a/read-cache.c +++ b/read-cache.c @@ -12,8 +12,8 @@ /* Index extensions. * * The first letter should be 'A'..'Z' for extensions that are not - * necessary for a correct operation (i.e. optimization data). + * necessary for a correct operation (that is, optimization data). * When new extensions are added that _needs_ to be understood in * order to correctly interpret the index file, pick character that * is outside the range, to cause the reader to abort. */ That is, , if you want to do finer grained hunk splitting than what "git add -p" lets you do, you do _not_ let user specify "I want to split the hunk into two, before this point and after this point". Instead, let the user pick zero or more '-' line and zero or more '+' line, and adjust the context around it. An unpicked '-' line becomes the common context, and an unpicked '+' line disappears. After that, you recount the diff. That way, you do not have to do any "unidiff zero" cop-out. At the same time, you can stash away what was _not_ picked, creating two variants to be applied on top of the result of applying (or not applying) the picked patch, if you want to allow "undo". (variant one: applies after the above is applied) @@ -12,8 +12,8 @@ /* Index extensions. * * The first letter should be 'A'..'Z' for extensions that are not * necessary for a correct operation (that is, optimization data). - * When new extensions are added that _needs_ to be understood in + * When new extensions are added that needs to be understood in * order to correctly interpret the index file, pick character that * is outside the range, to cause the reader to abort. */ (variant two: applies if the above is not applied) @@ -12,8 +12,8 @@ /* Index extensions. * * The first letter should be 'A'..'Z' for extensions that are not * necessary for a correct operation (i.e. optimization data). - * When new extensions are added that _needs_ to be understood in + * When new extensions are added that needs to be understood in * order to correctly interpret the index file, pick character that * is outside the range, to cause the reader to abort. */