Re: Re: Extended splitting for "git add --interactive"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Thu, Nov 27, 2014 at 5:14 AM, Johan Herland <johan@xxxxxxxxxxx> 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.

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,


-- 
Brandon McCaig <bamccaig@xxxxxxxxx> <bamccaig@xxxxxxxxxxxxxxxx>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bambams.ca/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]