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: git@vger.kernel.org
Subject: Re: [PATCH 1/2] am -3: allow nonstandard -p<num> option
Date: Wed, 29 Feb 2012 02:27:42 -0500	[thread overview]
Message-ID: <20120229072742.GA11896@sigill.intra.peff.net> (raw)
In-Reply-To: <7vvcmqwbto.fsf@alter.siamese.dyndns.org>

On Tue, Feb 28, 2012 at 07:36:03PM -0800, Junio C Hamano wrote:

> > $git_apply_opt can have other stuff in it, too (from my cursory reading,
> > it looks like --whitespace, --directory, --exclude, -C, --reject,
> > --ignore-whitespace, and --ignore-space-change).  Those options are now
> > passed, too.
> >
> > Naively, I don't think it should be a problem. Many of them will do
> > nothing (because the patch _should_ apply cleanly to the blobs it
> > mentions). Some seem like an obvious improvement (e.g., "--directory"
> > should be just as necessary as "-p", I would think). For something like
> > "--whitespace=error", I would think we would have errored out already
> > when we first tried to apply the patch. Or maybe not. I didn't test.
> 
> An honest answer is that I didn't think deeply if they matter ;-).

I figured. But once in a while it is good to hold you to the same
standard that we do of other contributors. :)

> Certainly we would want to honor the original settings for whitespace
> errors by propagating the option, so that we would reject or adjust when
> synthesizing the fake ancestor tree the same way as we deal with them when
> apply the patch for real.

I did a quick test, and yes, your patch is an improvement for the other
options, too. Though it's still not perfect. My test was:

  # make a repo with a simple file
  git init -q repo && cd repo &&
  perl -le 'print for(1..10)' >foo && git add foo && git commit -qm base &&

  # now make a whitespace-damaged patch
  sed -i 's/3/trailing whitespace  /' foo && git commit -qam ws &&
  git format-patch -1 --stdout >patch &&
  git reset -q --hard HEAD^ &&

  # now make a change that needs a 3-way merge
  sed -i 's/5/conflicting context/' foo && git commit -qam conflict &&

  # and then apply our patch with 3-way fallback, erroring out on
  # whitespace
  git am --whitespace=error -3 patch

which does indeed apply the patch with the wrong whitespace settings.
With your patch, it correctly refuses to apply. Though the output is:

  Applying: ws
  /home/peff/foo/am/repo/.git/rebase-apply/patch:13: trailing whitespace.
  trailing whitespace  
  fatal: 1 line adds whitespace errors.
  Repository lacks necessary blobs to fall back on 3-way merge.
  Cannot fall back to three-way merge.
  Patch failed at 0001 ws

which is misleading. We do not lack the necessary blobs, but rather
git-apply failed for a different reason. However, git-apply doesn't
differentiate the situations by exit code, so git-am is left to guess.

So I think the unintended side effects of your patch are likely to be a
good thing and fix bugs. Possibly the commit message should explain
that, but as it is already in next, I'm content to leave this thread in
the list archive as a footnote.

We could assign a special exit code to git-apply to allow git-am to
produce a better error message. I don't know if it's worth the effort.

-Peff

  reply	other threads:[~2012-02-29  7:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 23:24 [PATCH 0/2] "am -3" and "--no-prefix" does not work well Junio C Hamano
2012-02-28 23:24 ` [PATCH 1/2] am -3: allow nonstandard -p<num> option Junio C Hamano
2012-02-29  2:58   ` Jeff King
2012-02-29  3:36     ` Junio C Hamano
2012-02-29  7:27       ` Jeff King [this message]
2012-02-28 23:24 ` [PATCH 2/2] test: "am -3" can accept non-standard -p<num> Junio C Hamano

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=20120229072742.GA11896@sigill.intra.peff.net \
    --to=peff@peff.net \
    --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 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).