All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Helmberger <sven.helmberger@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Alternative to manual editing with git add --patch
Date: Thu, 15 Oct 2015 01:36:32 +0200	[thread overview]
Message-ID: <561EE700.3020002@gmx.de> (raw)
In-Reply-To: <xmqqk2qp8hlj.fsf@gitster.mtv.corp.google.com>

Am 14.10.2015 um 19:50 schrieb Junio C Hamano:
> Sven Helmberger <sven.helmberger@gmx.de> writes:
> 
> As a quick-and-dirty change, you could invent a new variant of
> 's'plit that breaks a N-line hunk into N hunks with 1-line each, but
> obviously that would not be a pleasant-enough UI to be called usable
> when you have a hunk that adds 100 lines.  Perhaps "Split this hunk
> into two by ending the earlier one immediately before the line that
> has this substring" or something might be an idea?
> 

If we go by the style of interaction in git add --patch and git add
--interactive, I think the most canonical solution would be to implement
it like this.

If we know when we can't split the current patch any further ( the point
at which selecting s changes nothing anymore), why shouldn't add --patch
not work similar to add --interactive in that it prints the lines of the
diff prefixed with numbers and the user can define a numerical range to
"split off". Then they decide whether to add those lines or not and
return to the line-numbers until they're trough with the patch.

Regards,
Sven Helmberger

  reply	other threads:[~2015-10-14 23:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 15:07 Alternative to manual editing with git add --patch Sven Helmberger
2015-10-14 16:30 ` Matthieu Moy
2015-10-14 16:52 ` Johannes Schindelin
2015-10-14 17:50 ` Junio C Hamano
2015-10-14 23:36   ` Sven Helmberger [this message]
2015-10-15 10:11     ` Johannes Schindelin
2015-10-15 13:37       ` Sven Helmberger
2015-10-15 15:06         ` Johannes Schindelin
2015-10-15 15:22           ` Sven Helmberger

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=561EE700.3020002@gmx.de \
    --to=sven.helmberger@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.