git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Miklos Vajna <vmiklos@frugalware.org>,
	git@vger.kernel.org
Subject: Re: [PATCH] docs: give more hints about how "add -e" works
Date: Mon, 8 Nov 2010 22:03:58 -0500	[thread overview]
Message-ID: <20101109030358.GA17747@sigill.intra.peff.net> (raw)
In-Reply-To: <7vlj53nwjl.fsf@alter.siamese.dyndns.org>

On Mon, Nov 08, 2010 at 04:57:34PM -0800, Junio C Hamano wrote:

> The new text indeed looks much clearer, except for one part I am not
> absolutely sure...
> 
> > +new content::
> > +
> > +You may also add new content that does not exist in the patch. Simply
> > +add new lines, each starting with "{plus}".
> > +
> > +You can also perform more complex operations, such as modifying the
> > +content to be staged by a "{plus}" line. However, note that this impacts
> > +_only_ the index; the working tree file will remain unchanged, and will
> > +appear to "undo" the content you have staged. Such operations should be
> > +performed only if you know what you are doing.
> 
> This "However, note that" part should apply not only to newly introduced
> {plus} lines but also to {plus} lines whose change were edited (lines from
> "added content" and from post-image half of "modified content"), no?

Right. The final paragraph you quoted is not part of the list, and it
looks better when rendered by asciidoc, as it's indented differently. So
I think some of the confusion is from the source formatting. But...

> I tried to be careless when reading the two paragraphs above, and managed
> to get an incorrect impression that the caveat applies only to "more
> complex operations", even though it actually applies not just the previous
> "new content" but also "added/modified" content.
> 
> Thinking about it a bit more, it is worse than that.  Turning " " into "-"
> has the same "getting reverted" issue, no?

Yeah, some of the operations described in the upper list are actually
"more complex" in the sense of looking like reverts. Basically any time
you are _introducing_ a change during the diff edit rather than simply
selecting or not-selecting changes that exist in the working tree, you
are going to get confusing results. So let me take one more stab at it,
and I think the correct breakdown is:

  1. stuff you might want to do: staging or not staging added, removed,
     and modified lines

  2. stuff you might want to do if you're insane: marking context lines
     for removal, adding new content, changing content on existing add
     lines

  3. stuff that you never want to do, because it makes the patch
     impossible to apply: deleting, adding, or changing context or
     removal lines

I'll try to do a patch later tonight.

-Peff

  reply	other threads:[~2010-11-09  3:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 14:30 [PATCH] docs: give more hints about how "add -e" works Jeff King
2010-10-21 19:04 ` Jonathan Nieder
2010-10-21 22:32 ` Junio C Hamano
2010-10-22 19:25   ` Jeff King
2010-10-22 21:54     ` Junio C Hamano
2010-11-08 22:33       ` Jeff King
2010-11-09  0:57         ` Junio C Hamano
2010-11-09  3:03           ` Jeff King [this message]
2010-11-09  4:58             ` Jeff King
2010-10-24  0:32 ` Miklos Vajna

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=20101109030358.GA17747@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=vmiklos@frugalware.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).