El 12/12/2007, a las 21:18, Junio C Hamano escribió:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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
-
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
