From: Junio C Hamano <gitster@pobox•com>
To: Frank Terbeck <ft@bewatermyfriend•org>
Cc: git@vger•kernel.org, Jeff King <peff@peff•net>
Subject: Re: [PATCH v2 2/4] Add format.coverauto boolean
Date: Tue, 05 May 2009 03:41:05 -0700 [thread overview]
Message-ID: <7vvdof25oe.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20090505084916.GB26208@fsst.voodoo.lan> (Frank Terbeck's message of "Tue\, 5 May 2009 10\:49\:16 +0200")
Frank Terbeck <ft@bewatermyfriend•org> writes:
> ... That could potentially break
> people's existing scripts - either by new default behaviour or by the
> setting of format.coverletter of an individual user. That could still
> happen when using coverauto, so maybe my reasoning was flawed - given
> that Stephen raised the same question.
That part I agree with 100%. A separate configuration variable does not
help here; it will not act as an "I know what I am doing" flag.
"rebase" is not a problem because both format-patch and rebase come from
the same git and people do not mix and match. The only thing we need to
do is to make sure that rebase is updated to explicitly decline the cover
letter in the same or earlier version of git that adds this new option.
However, there are other people's scripts to worry about, and no matter
what you do, you cannot avoid breaking them if you introduce a
configuration variable that changes the behaviour of the command in a
backward incompatible way. This could be a disruptive change that needs
to happen at a major revision boundary, if we were to add it.
> If so, do you want coverletter to default to zero (which wouldn't
> change the default behaviour) or do you want it to default to two?
The default between 0 and 2 does not matter much. If people find this new
feature useful (if not, then this new feature is not worth adding), then
they will set it to non-zero themselves, and then get their scripts
broken. In a sense, defaulting it to zero is just delaying an inevitable
breakage.
If we were to do this, we should rather default it to two from day one and
make sure we break people's scripts that (rightly) rely on format-patch
not producing covers that the caller never asked, to make sure they are
adjusted to decline cover explicitly. And such a release should come with
a note in huge red letters that says "this new feature allows you not to
say --cover on the command line, and it is far more important than keeping
your scripts that run format-patch and process its output working. You
must adjust your scripts to the new reality. Sorry for the inconvenience,
and have a nice day."
I do not think I would stand behind such a release note, though.
For one thing, I do not see a huge need for this configuration variable.
Why is "--cover" too cumbersome to type, when you are already willing to
type "format-patch"? You can alias the whole thing away to make it even
shorter. For another, we do not simply break people's scripts knowingly.
For this feature to go forward, somebody has to find a way not to break
people's scripts even when the user uses it. One possibility is to find a
nicer verb X and introduce "git X" command that does what "format-patch"
does but with a better default (and syntax --- people get confused by the
oldest form "git format-patch $commit", which does not behave like "git
log $commit" simply because the syntax predates the modern "revision
range" notation the "log" family supports, such as A..B).
next prev parent reply other threads:[~2009-05-05 10:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-18 16:16 [PATCH 0/6] more automation for cover letter generation Frank Terbeck
2009-04-18 16:16 ` [PATCH 1/6] format-patch: add cover{letter,onepatch} options Frank Terbeck
2009-04-18 16:16 ` [PATCH 2/6] Add documentation for format-patch's --cover-one-patch Frank Terbeck
2009-04-18 16:16 ` [PATCH 3/6] Document format.coverletter and format.coveronepatch Frank Terbeck
2009-04-18 16:16 ` [PATCH 4/6] format-patch: introduce overwritecoverletter option Frank Terbeck
2009-04-18 16:16 ` [PATCH 5/6] Add documentation for --cover-overwrite Frank Terbeck
2009-04-18 16:16 ` [PATCH 6/6] Document format.overwritecoverletter Frank Terbeck
2009-04-18 18:31 ` [PATCH 0/6] more automation for cover letter generation Junio C Hamano
2009-05-04 9:58 ` [PATCH v2 0/4] " Frank Terbeck
2009-05-04 9:58 ` [PATCH v2 1/4] Add format.coverletter option Frank Terbeck
2009-05-04 9:59 ` [PATCH v2 2/4] Add format.coverauto boolean Frank Terbeck
2009-05-04 18:39 ` Stephen Boyd
2009-05-04 21:41 ` Frank Terbeck
2009-05-04 23:20 ` Junio C Hamano
2009-05-05 8:49 ` Frank Terbeck
2009-05-05 10:41 ` Junio C Hamano [this message]
2009-05-05 13:29 ` Frank Terbeck
2009-05-05 15:23 ` Frank Terbeck
2009-05-04 9:59 ` [PATCH v2 3/4] Add tests for coverauto, coverletter and --cover-letter Frank Terbeck
2009-05-04 9:59 ` [PATCH v2 4/4] Documentation for format.coverletter " Frank Terbeck
2009-04-21 3:32 ` [PATCH 0/6] more automation for cover letter generation Jeff King
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=7vvdof25oe.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=ft@bewatermyfriend$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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