git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: git@vger.kernel.org, Jacob Keller <jacob.keller@gmail.com>
Subject: Re: [PATCH] format-patch: teach format.useAutoBase "whenAble" option
Date: Sat, 26 Sep 2020 15:38:43 -0700	[thread overview]
Message-ID: <xmqqk0wgi2oc.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200925230701.2814287-1-jacob.e.keller@intel.com> (Jacob Keller's message of "Fri, 25 Sep 2020 16:07:01 -0700")

Jacob Keller <jacob.e.keller@intel.com> writes:

> From: Jacob Keller <jacob.keller@gmail.com>
>
> The format.useAutoBase configuration option exists to allow users to
> enable '--base=auto' for format-patch by default.
>
> This can sometimes lead to poor workflow, due to unexpected failures
> when attempting to format an ancient patch:
>
>     $ git format-patch -1 <an old commit>
>     fatal: base commit shouldn't be in revision list
>
> This can be very confusing, as it is not necessarily immediately obvious
> that the user requested a --base (since this was in the configuration,
> not on the command line).
>
> We do want --base=auto to fail when it cannot provide a suitable base,
> as it would be equally confusing if a formatted patch did not include
> the base information when it was requested.
>
> Teach format.useAutoBase a new mode, "whenAble". This mode will cause
> format-patch to attempt to include a base commit when it can. However,
> if no valid base commit can be found, then format-patch will continue
> formatting the patch without a base commit. --base also learns the same
> mode using the term "if-able".
>
> Add tests to cover the new mode of operation for --base.

Two minor points.

 * would users get confused choosing between if-able and whenAble to
   use for the configuration and the command line option?

 * what if there is a branch called "if-able"?  The same problem
   already exists with a refname "auto", and this makes it worse.

I do not know what the best approach to solve the latter, but the
former would be easier to solve by just picking one and sticking to
it.

Thanks.

      reply	other threads:[~2020-09-26 22:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 23:07 [PATCH] format-patch: teach format.useAutoBase "whenAble" option Jacob Keller
2020-09-26 22:38 ` Junio C Hamano [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqk0wgi2oc.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jacob.keller@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).