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.
prev parent 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).