Re: [PATCH] Teach git-gui to split hunks

From: Wincent Colaiuta <win@wincent.com>
Date: Dec 12, 2007, 23:02 UTC
Message-ID: <0B657FBB-A1D9-4C86-BC80-C33F92D7AF77@wincent.com>
In-Reply-To: <7vk5nj7jkp.fsf@gitster.siamese.dyndns.org>

El 12/12/2007, a las 21:18, Junio C Hamano escribió:

Show 30 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> When you select the context menu item "Split Hunk" in the diff area,
>> git-gui will now split the current hunk so that a new hunk starts at
>> the current position.
>>
>> For this to work, apply has to be called with --unidiff-zero, since
>> the new hunks can start or stop with a "-" or "+" line.
>> ...
>
> I still have conceptual problem with this whole thing.  For example,
> what does that MEAN to split this hunk from your patch...
>
>> @@ -296,7 +369,7 @@ proc apply_hunk {x y} {
>> 	if {$current_diff_path eq {} || $current_diff_header eq {}} return
>> 	if {![lock_index apply_hunk]} return
>>
>> -	set apply_cmd {apply --cached --whitespace=nowarn}
>> +	set apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}
>> 	set mi [lindex $file_states($current_diff_path) 0]
>> 	if {$current_diff_side eq $ui_index} {
>> 		set failed_msg [mc "Failed to unstage selected hunk."]
>
> ... by clicking between the '-' and '+' lines, and apply only one  
> half?
>
> Well, the question was not very well stated.  I know what it means --
> remove that old line, without replacing with the corrected/updated  
> one.
> The real question is how would that be useful?

I don't know if it would be useful, but I think the more important concern here is consistency. ie. it should split hunks the same way "git add -i" does. Both "git gui" and "git add -i" are official parts of Git, so in the interests of coherency they should share the same concept of "what it means to split a hunk".

"git add -i" considers any hunk where a there are multiple groups of deletions and/or insertions separated by context lines to be "splittable" (on the boundaries defined by those intervening context line), and all others to be unsplittable. I think this is a fairly intuitive way to conceptualize splitting, so if it comes down to making "git gui" split like "git add -i", or making "git add -i" split like this patch proposes that "git gui" should do it, then I'd vote for the former.

Cheers, Wincent