Re: Extended splitting for "git add --interactive"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> writes:
>
>> 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.

Of course, splitting at blank or at any arbitrary point that the
implementor of this new feature decides to be good is not end of the
world.  If the split at that chosen point is undesirable, the user
can join them back.  But then the feature did not help such a user
very much.  So that selection of "any arbitrary point" has to be
fairly a good heuristic, making majority of users happy, to be worth
for users to try.  If they try splitting with the heuristics and get
a good result 80% of times, 20% of time they instead may need to
join the wrong splits back, but overall it will be a win.

In an extreme case, we could have an option to split a run of zero
or more "-" lines followed by zero or more "+" lines into one line
per hunk, and let the user pick the line they want, which would
solve your original issue of turning "-A-B+C+D" into "-A+C" and
"-B+D", while allowing them to be commited with a different
splitting, e.g. "-A" and "-B+C+D".

But at that point, I suspect most people may choose to (e)dit the
patch themselves instead.  I dunno.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]