From: Wincent Colaiuta Date: Wed, 12 Dec 2007 23:02:20 GMT Subject: Re: [PATCH] Teach git-gui to split hunks 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ó: > Johannes Schindelin 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