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

Jean-François Veillette [off-list ref] writes:

quoted

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 often get big hunk just because I modified whitespaces around
relevent pieces of code, the ability to segment the changes and only
pick isolated and specific lines for a commit (not commiting
whitespaces surrounding real code changes) would be very welcome.
Maybe I should know better, but the actual hunk selection in git gui
is quite good already, but the ability to be more precise on how a
hunk is defined is a welcome change.

Oh, I wasn't questioning the usefulness of hunk splitting in general.
It is sometimes useful and that is why we have "add -i".

If you have something like this:

        @@ -j,k +l,m @@
         common 1
         common 2
        -preimage
        +postimage
         common 3
        -deleted
         common 4
         common 5

I think it makes sense to split it into two logical (overlapping) hunks:

        @@ -j,(k-3) +l,(m-2) @@
         common 1
         common 2
        -preimage
        +postimage
         common 3

and

        @@ -j,(k-3) +l,(m-3) @@
         common 3
        -deleted
         common 4
         common 5

and being able to apply one of them independent from the other, or
re-combine them back into one hunk.

I was just questioning if it makes sense to split a hunk like this in
the middle of -/+ lines:

	@@ -j,k +l,m @@
	 common
	 common
	-pre 1
	-pre 2
        -pre 3
        +post 1
	+post 2
	 common

You could split between "-pre 2" and "-pre 3", but I do not think that
would be so useful.  It is a different story if you allowed the above to
first be transformed into this way (assuming that "pre 1" and "pre 2"
corresponds to "post 1"):

	@@ -j,k +l,m @@
	 common
	 common
	-pre 1
	-pre 2
        +post 1
        -pre 3
	+post 2
	 common

and then be split between "+post 1" and "-pre 3".  That may make sense
in some context.