All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jochen Sprickerhof <jochen@sprickerhof.de>
To: phillip.wood@dunelm.org.uk
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] add -p: coalesce hunks before testing applicability
Date: Sun, 23 Sep 2018 19:16:26 +0200	[thread overview]
Message-ID: <20180923171626.GN26251@vis> (raw)
In-Reply-To: <d6a8f77b-0a83-90ae-a7fb-a3954ac3b346@talktalk.net>

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

* Phillip Wood <phillip.wood@talktalk.net> [2018-09-13 11:20]:
>Yes in the long term we want to be able to coalesce edited hunks, but I
>think it is confusing to call coalesce_overlapping_hunks() at the moment
>as it will not coalesce the edited hunks.

I would see it as a first step into that direction.

>I think that if you split a hunk, edit the first subhunk, transforming a
>trailing context line to a deletion then try if you try to stage the
>second subhunk it will fail. With your patch the edit will succeed as
>the second subhunk is skipped when testing the edited patch. Then when
>you try to stage the second subhunk it will fail as it's leading context
>will contradict the trailing lines of the edited subhunk. With the old
>method the edit failed but didn't store up trouble for the future.

Agreed. I guess the question is if you assume a hunk to be applied or 
skipped as the default. You can still find enough cases where neither 
the current nor the patched version works. I stumbled upon the one case 
where I wanted to stage only one part of a split hunk and that one 
worked after my patch. I leave it up to you if the added benefit 
overweights the stored up trouble.

Cheers Jochen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-09-23 17:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28  8:58 [PATCH] add -p: coalesce hunks before testing applicability Jochen Sprickerhof
2018-08-28 18:07 ` Junio C Hamano
2018-08-30 13:47   ` Phillip Wood
2018-08-30 14:51     ` Junio C Hamano
2018-09-03 19:01     ` Jochen Sprickerhof
2018-09-13 10:20       ` Phillip Wood
2018-09-23 17:16         ` Jochen Sprickerhof [this message]
2019-03-22 14:06         ` Johannes Schindelin
2019-06-02 14:17           ` Phillip Wood
2019-06-03 13:40             ` Johannes Schindelin
2019-06-03 14:59               ` Phillip Wood
2019-06-04 13:32                 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180923171626.GN26251@vis \
    --to=jochen@sprickerhof.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.