Extended splitting for "git add --interactive"

Hi!

This is for git-1.7.12 (an older version from the SLES11 SP3 SDK). If the issue is solved meanwhile, I'll be happy, and I apologize for being too lazy to find out.

Currently Git cannot split a block of changes like

-AAA -BBB +CCC +DDD

Into -AAA +CCC and -BBB +DDD

So you'll have to edit it and waste me extra time (People probably use split if they know what they are doing, so maybe allow that).

Another split that is not possible is a split across an empty line, like:

+AAA
+     <empty line (in reality)>
+BBB

One could split that either into two parts with the empty lines belonging to one of AAA or BBB, or into three parts where the empty line is just another junk to accept or refuse. See comment above on why I'd like that.

Regards, Ulrich Windl

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:

The answer is no ;-).

And it is unlikely to do so ever, because it is a wrong thing to do.

What makes the user happy to see above split when the user is expecting this instead?

-AAA and -BBB +CCC +DDD

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.

Junio C Hamano <gitster@pobox.com> writes:

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.

I probably forgot to mention the obvious: My enhancement request was for cases where git would reject so split a junk. I don't want to change the default split (if it finds a point to split). So maybe call it a "2nd-level-split". Only if split refuses to split, you could avoid using "edit" to manually split. Iknow that in gerneral such things can't be right, but you can eith reject the new junks or use "edit". I just guessed the feature could save some time on the average.

<xmqq3895rdr1.fsf@gitster.dls.corp.google.com>:

On Thu, Nov 27, 2014 at 9:55 AM, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

FWIW, I would very much like a "2nd-level split" where it simply splits into individual lines. I think it's not worth trying to be extra clever about it. For your example, I'd simply want the following behavior:

  -AAA
  -BBB
  +CCC
  +DDD
  Stage this hunk? SPLIT

  -AAA
  Stage this hunk? YES

  -BBB
  Stage this hunk? NO

  +CCC
  Stage this hunk? YES

  +DDD
  Stage this hunk? NO

This would allow me to stage the following:

  -AAA
  +CCC

and leave the following unstaged:

  -BBB
  +DDD

but would also allow any other combination.

...Johan

Hello,

On Thu, Nov 27, 2014 at 5:14 AM, Johan Herland <johan@herland.net> wrote:

Having (e)dited a lot of hunks manually I can see it being a bit difficult to understand line-by-line (but then I rarely split as it rarely does what I need so I'm not sure what use cases this would apply). I just had an idea about re-joining added lines in the output each time to show you what you're actually doing to the hunk with each prompt. I don't know if it's a good idea. Illustration:

 AAA
 BBB
-CCC
-DDD
+EEE
+FFF
 GGG
Stage this hunk? s

  AAA
  BBB
- CCC
Stage this hunk? y

  AAA
  BBB
 -CCC
- DDD
Stage this hunk? n

  AAA
  BBB
 -CCC
  DDD
+ EEE
Stage this hunk? y

  AAA
  BBB
 -CCC
  DDD
 +EEE
+ FFF
  GGG
Stage this hunk? n

In any case, I find that editing the hunk is generally faster than trying to figure out if split is going to do something useful (perhaps studying the Git code would help in that regard).

That said, the key to making editing the hunk (or patches in general) efficient is adding keybindings to your favorite editor to edit unified diffs. In my Vim configuration I map ,, to a function that removes the current line change (removes - line, deletes + line) and ,. to add - to context lines. Both also always move down a line automatically and center that line on the screen, and have no effect on lines for which the chosen function has no meaning. So editing a hunk typically becomes ,, to remove unwanted changes from the current hunk or skip context lines and j to skip good lines to get to the next changes. Occasionally I use ,. to remove a context line that was in my original source. And if I want to invent a + line it's just o or O. The bit I'm editing remains in the middle of my screen with my whole screen for context. My relevant vimrc:

autocmd FileType diff
            \ nnoremap ,, :call UndoPatch()<CR>|
            \ nnoremap ,. :s/^ /-/e<CR>:nohl<CR>jzz

function! UndoPatch()
    normal! 0

    if getline('.') =~ '^+'
        delete
        normal! zz
        return
    endif

    if getline('.') =~ '^-'
        s/^-/ /
        nohlsearch
    endif

    normal! j
    normal! ^
    normal! zz
endfunction

Maybe that'll be useful for somebody else. Any editor suitable for a programmer will be able to do something similar. I suspect that customizing your editor will be time better spent.

Regards,