git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* Request: git add --interactive: split hunk: When can't split further, split on empty lines
@ 2019-05-30  0:19 James Harvey
  2019-05-30 14:53 ` Johannes Schindelin
  0 siblings, 1 reply; 5+ messages in thread
From: James Harvey @ 2019-05-30  0:19 UTC (permalink / raw)
  To: git, gitster

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() {
}
---------

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines
  2019-05-30  0:19 Request: git add --interactive: split hunk: When can't split further, split on empty lines James Harvey
@ 2019-05-30 14:53 ` Johannes Schindelin
  2019-05-30 19:26   ` Philip Oakley
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Schindelin @ 2019-05-30 14:53 UTC (permalink / raw)
  To: James Harvey; +Cc: git, gitster, Phillip Wood

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines
  2019-05-30 14:53 ` Johannes Schindelin
@ 2019-05-30 19:26   ` Philip Oakley
  2019-05-30 19:43     ` Johannes Schindelin
  0 siblings, 1 reply; 5+ messages in thread
From: Philip Oakley @ 2019-05-30 19:26 UTC (permalink / raw)
  To: Johannes Schindelin, James Harvey; +Cc: git, gitster, Phillip Wood

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines
  2019-05-30 19:26   ` Philip Oakley
@ 2019-05-30 19:43     ` Johannes Schindelin
  2019-05-30 20:30       ` Philip Oakley
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Schindelin @ 2019-05-30 19:43 UTC (permalink / raw)
  To: Philip Oakley; +Cc: James Harvey, git, gitster, Phillip Wood

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines
  2019-05-30 19:43     ` Johannes Schindelin
@ 2019-05-30 20:30       ` Philip Oakley
  0 siblings, 0 replies; 5+ messages in thread
From: Philip Oakley @ 2019-05-30 20:30 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: James Harvey, git, gitster, Phillip Wood

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-05-30 20:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-30  0:19 Request: git add --interactive: split hunk: When can't split further, split on empty lines James Harvey
2019-05-30 14:53 ` Johannes Schindelin
2019-05-30 19:26   ` Philip Oakley
2019-05-30 19:43     ` Johannes Schindelin
2019-05-30 20:30       ` Philip Oakley

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git