Request: git add --interactive: split hunk: When can't split further, split on empty lines

Request: git add --interactive: split hunk: When can't split further, split on empty lines

[James Harvey]

When adding interactively, 's' can be used to split the current hunk.
Once it gets down to where 's' reports "Sorry, cannot split this
hunk", it could be useful if it would then start splitting based on
empty lines, probably leaving empty lines at the top of the split
hunks.  It certainly wouldn't be perfect, and might create many hunks,
but it would be a nice alternative to manually editing the hunk.
Certainly someone could still manually edit the hunk if they didn't
want to use it in a particular situation.

Example:

----------
int a() {
}

int b() {
}
----------

becomes

---------
int a() {
}
---------

int b() {
}
---------

Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines

[Johannes Schindelin]

Hi James,

On Wed, 29 May 2019, James Harvey wrote:

> When adding interactively, 's' can be used to split the current hunk.
> Once it gets down to where 's' reports "Sorry, cannot split this
> hunk", it could be useful if it would then start splitting based on
> empty lines, probably leaving empty lines at the top of the split
> hunks.  It certainly wouldn't be perfect, and might create many hunks,
> but it would be a nice alternative to manually editing the hunk.
> Certainly someone could still manually edit the hunk if they didn't
> want to use it in a particular situation.

While a neat idea from the users' perspective, I think that it is
technically a bit challenging, as you then have a problem to coalesce the
patches appropriately.

The thing with the splitting at context lines is that you have a much
easier time to merge individual split-hunks into a "coalesced" hunk
because the context lines stay context lines.

Having said that, there was a patch series recently to add the ability to
stage individual lines, and I think that your feature request could be
implemented on top of that.

In the meantime, an Outreachy intern and I worked on turning `git add -i`
into a built-in (it was written in Perl, and the built-in is written in
portable C instead), and I *think* that the plan with the patch series to
stage individual lines was to re-implement it on top of the built-in patch
series.

Would you be interested in participating in that project?

Ciao,
Johannes

Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines

[Philip Oakley]

Hi,  some minor comments.
On 30/05/2019 15:53, Johannes Schindelin wrote:
> Hi James,
>
> On Wed, 29 May 2019, James Harvey wrote:
>
>> When adding interactively, 's' can be used to split the current hunk.
>> Once it gets down to where 's' reports "Sorry, cannot split this
>> hunk", it could be useful if it would then start splitting based on
>> empty lines, probably leaving empty lines at the top of the split
>> hunks.  It certainly wouldn't be perfect, and might create many hunks,
A binary search style split may be an option to avoid the 'many hunks' 
issue.
>> but it would be a nice alternative to manually editing the hunk.
>> Certainly someone could still manually edit the hunk if they didn't
>> want to use it in a particular situation.
> While a neat idea from the users' perspective, I think that it is
> technically a bit challenging, as you then have a problem to coalesce the
> patches appropriately.
>
> The thing with the splitting at context lines is that you have a much
> easier time to merge individual split-hunks into a "coalesced" hunk
> because the context lines stay context lines.
>
> Having said that, there was a patch series recently to add the ability to
> stage individual lines,
I believe that the git-gui (in tk/tcl, but using git commands) was 
already able to stage individual/selected lines, so there may be some 
ideas from there.

> and I think that your feature request could be
> implemented on top of that.
>
> In the meantime, an Outreachy intern and I worked on turning `git add -i`
> into a built-in (it was written in Perl, and the built-in is written in
> portable C instead), and I *think* that the plan with the patch series to
> stage individual lines was to re-implement it on top of the built-in patch
> series.
>
> Would you be interested in participating in that project?
>
> Ciao,
> Johannes
--
Philip

Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines

[Johannes Schindelin]

Hi Philip,

On Thu, 30 May 2019, Philip Oakley wrote:

> On 30/05/2019 15:53, Johannes Schindelin wrote:
> >
> > Having said that, there was a patch series recently to add the ability to
> > stage individual lines,
>
> I believe that the git-gui (in tk/tcl, but using git commands) was
> already able to stage individual/selected lines, so there may be some
> ideas from there.

Sadly, no.

There is one very big difference between Git GUI and `git add -p`: when
you stage a line in Git GUI, it is staged *immediately*.

When you stage a single line in the Git GUI, the diff you see in the
window is reloaded. That is quite slow in the long run, and no fun.

In contrast, `git add -p` does not stage *anything* until you're done
selecting what you want to stage.

Therefore, `git add -p` does have to do things quite a bit differently, as
it will have to eventually build a single diff that is applied in one fell
swoop, no matter how many lines you select individually.

And naturally, there is also the difference between the user interfaces:
while you can ask the user to select (part of) the line to stage in Git
GUI via the mouse, that is not at all an option in `git add -p`.

Likewise, the very convenient option to navigate via regular expressions
in `git add -p` is not available in Git GUI at all.

In short: I think that it makes more sense to come up with a design
specific to `git add -p` and not get distracted by Tcl code that works
quite differently.

Ciao,
Dscho

Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines

[Philip Oakley]

Thanks for the clarification. Funny that we are "staging" the patch 
preparation to avoid real staging;-)

On 30/05/2019 20:43, Johannes Schindelin wrote:
> Hi Philip,
>
> On Thu, 30 May 2019, Philip Oakley wrote:
>
>> On 30/05/2019 15:53, Johannes Schindelin wrote:
>>> Having said that, there was a patch series recently to add the ability to
>>> stage individual lines,
>> I believe that the git-gui (in tk/tcl, but using git commands) was
>> already able to stage individual/selected lines, so there may be some
>> ideas from there.
> Sadly, no.
>
> There is one very big difference between Git GUI and `git add -p`: when
> you stage a line in Git GUI, it is staged *immediately*.
>
> When you stage a single line in the Git GUI, the diff you see in the
> window is reloaded. That is quite slow in the long run, and no fun.
>
> In contrast, `git add -p` does not stage *anything* until you're done
> selecting what you want to stage.
>
> Therefore, `git add -p` does have to do things quite a bit differently, as
> it will have to eventually build a single diff that is applied in one fell
> swoop, no matter how many lines you select individually.
>
> And naturally, there is also the difference between the user interfaces:
> while you can ask the user to select (part of) the line to stage in Git
> GUI via the mouse, that is not at all an option in `git add -p`.
>
> Likewise, the very convenient option to navigate via regular expressions
> in `git add -p` is not available in Git GUI at all.
>
> In short: I think that it makes more sense to come up with a design
> specific to `git add -p` and not get distracted by Tcl code that works
> quite differently.
>
> Ciao,
> Dscho