I probably forgot to mention the obvious: My enhancement request was for cases where git would reject so split a junk. I don't want to change the default split (if it finds a point to split).
So maybe call it a "2nd-level-split". Only if split refuses to split, you could avoid using "edit" to manually split.
Iknow that in gerneral such things can't be right, but you can eith reject the new junks or use "edit". I just guessed the feature could save some time on the average.
>>> Junio C Hamano <gitster@xxxxxxxxx> schrieb am 26.11.2014 um 19:57 in Nachricht
<xmqq3895rdr1.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
> "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> writes:
>
>> This is for git-1.7.12 (an older version from the SLES11 SP3 SDK). If
>> the issue is solved meanwhile, I'll be happy, and I apologize for
>> being too lazy to find out.
>
> The answer is no ;-).
>
>> Currently Git cannot split a block of changes like
>>
>> -AAA
>> -BBB
>> +CCC
>> +DDD
>>
>> Into
>> -AAA
>> +CCC
>> and
>> -BBB
>> +DDD
>
> And it is unlikely to do so ever, because it is a wrong thing to do.
>
> What makes the user happy to see above split when the user is
> expecting this instead?
>
> -AAA
> and
> -BBB
> +CCC
> +DDD
>
>> Another split that is not possible is a split across an empty line, like:
>>
>> +AAA
>> + <empty line (in reality)>
>> +BBB
>
> Likewise. An empty line is not that special. AAA may be adding one
> block of lines "if (condition) { ... }" and BBB may be another, and
> it often happens that you would want to separate these into two
> changes, with or without an empty line in between.
>
> +if (foo) {
> + do foo thing
> +}
> +if (bar) {
> + do bar thing
> +}
>
> Having said all that, I am not opposed to a usable idea to allow the
> user to specify where in a contiguous block of -*+* to break a hunk
> and how.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html