All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Thomas Rast <trast@student.ethz.ch>
Cc: "Oded Shimon" <ods15@ods15.dyndns.org>,
	"Junio C Hamano" <gitster@pobox.com>, "Jan Krüger" <jk@jk.gs>,
	git@vger.kernel.org
Subject: Re: [Alt. PATCH] format-patch: do not use diff UI config
Date: Thu, 9 Sep 2010 15:43:23 -0400	[thread overview]
Message-ID: <20100909194323.GA1146@sigill.intra.peff.net> (raw)
In-Reply-To: <2a6b8c51903fd6a22606b8f592b1a2e11ea68741.1284020917.git.trast@student.ethz.ch>

On Thu, Sep 09, 2010 at 10:36:54AM +0200, Thomas Rast wrote:

> format-patch read and used the diff UI config, such as diff.renames,
> diff.noprefix and diff.mnemnoicprefix.  These have a history of
> breaking rebase and patch application in general; cf. 840b3ca (rebase:
> protect against diff.renames configuration, 2008-11-10).
> 
> Instead of continually putting more options inside git-rebase to avoid
> these issues, this patch takes the stance that output from
> format-patch is intended primarily for git-am and only as a side
> effect also for human consumption.  Hence, ignore the diff UI config
> entirely when coming from format-patch.
> 
> Note that all existing calls to git_log_config except for the one in
> git_format_config use a NULL callback.

This was my first thought upon reading Oded's patch, too. We would want
to cut out anything that will cause format-patch to create a patch that
could not be applied. So from your list:

> This is a bolder approach that just outright ignores the backwards
> compatibility complaints Junio had in 840b3ca.  Among the variables
> parsed in git_diff_ui_config, namely
> 
>   color.diff (and its legacy alias diff.color)
>   diff.renames
>   diff.autorefreshindex
>   diff.mnemonicprefix
>   diff.noprefix
>   diff.external
>   diff.wordregex
>   diff.ignoresubmodules
> 
> arguably only diff.renames (and perhaps diff.ignoresubmodules, I don't
> use them) should affect format-patch.  Everything else undermines the
> guarantee (by having a consistent format) that format-patch|am works.

I would agree that diff.renames should probably be the only thing we
want to allow (because it is not about making a broken diff, but because
the receiver may or may not support it, and we already know that
git-rebase will handle it).

diff.external is debatable. If your external diff is producing real,
applicable diffs, then it is fine to use it. I have to wonder why you
would use an external diff, then. I guess because it's faster, or maybe
has an algorithm that produces equivalent but easier-to-read results
(e.g., patience before we had --patience)?

> So now I'm not so sure about diff.renames.  Perhaps it needs to be
> retained, but that requires a special case since we cannot move it to
> git_diff_basic_config() (which affects diff-* plumbing too).

I think it is reasonable to just move an explicit "diff.renames" check
into format_patch, and then set the diff_options appropriately. It
requires special case code because it _is_ a special case.

-Peff

  parent reply	other threads:[~2010-09-09 19:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-08 13:54 [PATCH] Add explicit --src/dst-prefix to git-formt-patch in git-rebase.sh for the case of "diff.noprefix" in git-config Oded Shimon
2010-09-08 20:31 ` ods15
2010-09-08 21:07 ` Jan Krüger
2010-09-09  8:07 ` [PATCH] Add --src/dst-prefix to git-formt-patch in git-rebase.sh Oded Shimon
2010-09-09  8:36   ` [Alt. PATCH] format-patch: do not use diff UI config Thomas Rast
2010-09-09 19:13     ` Sverre Rabbelier
2010-09-09 19:43     ` Jeff King [this message]
2010-09-10 16:21     ` Junio C Hamano
2010-09-09 18:35   ` [PATCH] Add --src/dst-prefix to git-formt-patch in git-rebase.sh Junio C Hamano
2010-09-09 18:49     ` ods15
2010-09-09 18:49     ` Oded Shimon

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=20100909194323.GA1146@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jk@jk.gs \
    --cc=ods15@ods15.dyndns.org \
    --cc=trast@student.ethz.ch \
    /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.