git add -p—splitting hunks, limit is too large

git add -p—splitting hunks, limit is too large

[Beau Martinez]

Hi git developers and community,

I'd like to inquire as to why `git add -p` can only split hunks so
much. The limit is too large; why can't you split until each hunk is
only a line? I often have to run `edit` and split them manually
myself.

I'd like to contribute a patch to change it, although my C is rusty.
Are there resources that will help me to do this?

Thank you for your time.

Beau

Re: git add -p—splitting hunks, limit is too large

[Jeff King]

On Fri, Sep 02, 2016 at 03:36:58PM +0100, Beau Martinez wrote:

> I'd like to inquire as to why `git add -p` can only split hunks so
> much. The limit is too large; why can't you split until each hunk is
> only a line? I often have to run `edit` and split them manually
> myself.

There's some previous discussion in this thread:

  http://public-inbox.org/git/200805232221.45406.trast@student.ethz.ch/t/#u

and further back, this message:

  http://public-inbox.org/git/7vbq8v7cdx.fsf@gitster.siamese.dyndns.org/

I think one problem is that in a given contiguous hunk, not all of the
lines are independent, because edits are represented as a pair of -/+
lines. E.g., if the preimage is:

  one
  two
  four

and the postimage is:

  one
  two modified
  three
  four

your diff will be:

   one
  -two
  +two modified
  +three
   four

The ideal split is two groups:

  -two
  +two modified

  +three

So you could possibly achieve that by specifying the exact line to split
at. But let's imagine "two" was the missing item, and we modified
"three". Then your diff is:

   one
  -three
  +two
  +three modified
   four

Now the related lines are non-adjacent! I don't think there's a general
solution, and of course it can get arbitrarily complicated, with many
interleaved pairs. I don't think we can rely on figuring out which lines
form a pair. In this toy example it's obvious, but in real diffs the
lines might not bear any resemblance.

Splitting to single lines means you need to remember to add the matched
pairs, which might be arbitrarily far apart.  That's not really any
different than dumping the hunk in your editor, but I find there that
it's easy to rearrange and group things as appropriate.

> I'd like to contribute a patch to change it, although my C is rusty.
> Are there resources that will help me to do this?

The good news (or maybe the bad) is that "add -p" is implemented
entirely in Perl. :) It's in git-add--interactive.perl.

-Peff

Re: git add -p—splitting hunks, limit is too large

[Christian Neukirchen]

Jeff King <peff@peff.net> writes:

> Splitting to single lines means you need to remember to add the matched
> pairs, which might be arbitrarily far apart.  That's not really any
> different than dumping the hunk in your editor, but I find there that
> it's easy to rearrange and group things as appropriate.

My main use case for this would be to split a plain addition into
several small additions.  Which would be much easier with the
menu-driven approach.

(Mostly I just use magit, but sometimes I want to do this on machines
without emacs set up.)

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: git add -p—splitting hunks, limit is too large

[Johannes Schindelin]

Hi Beau,

On Fri, 2 Sep 2016, Beau Martinez wrote:

> Hi git developers and community,
> 
> I'd like to inquire as to why `git add -p` can only split hunks so
> much. The limit is too large; why can't you split until each hunk is
> only a line? I often have to run `edit` and split them manually
> myself.

Please note that git gui lets you stage lines individually.

Ciao,
Johannes

Re: git add -p—splitting hunks, limit is too large

[Johannes Schindelin]

Hi Peff,

On Fri, 2 Sep 2016, Jeff King wrote:

> The good news (or maybe the bad) is that "add -p" is implemented
> entirely in Perl. :)

Yeah, you would definitely not call this "good news" if you were in my
shoes.

There is no question that it has grown way too unwieldy and that we (once
again, as with so many other scripts) missed the boat to convert it to C.

Scripting is nice for prototyping. But it comes at a high
portability/performance cost if taken too far. And we took it way too far.

Just look at all of those 1667 lines of git-add--interactive and weep. So
many things reimplemented in Perl instead of reusing functions in
libgit.a (or introducing them, making them usable from other parts of
Git). Wasted time is what I see there.

The worst part is that it completely violates our original "Unix
philosophy" of implementing the business logic in C and combinig it using
light-weight scripting.

And of course now the script is *so large* that nobody wants to undertake
the task of porting it to C.

Ciao,
Dscho