Re: [PATCH v2 2/4] Add format.coverauto boolean

From: Frank Terbeck <ft@bewatermyfriend.org>
Date: May 5, 2009, 13:29 UTC
Message-ID: <20090505132923.GC26208@fsst.voodoo.lan>
In-Reply-To: <7vvdof25oe.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com>: [...]

Show 12 quoted lines

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

Yes, this whole compatibility issue is exactly the reason why I said earlier, that we could only take format.coverletter (the way it's currently implemented in the latest series) and forget about format.coverauto (and its implications) altogether:

<1241431142-8444-1-git-send-email-ft@bewatermyfriend.org>: } Now that I think of it again, two weeks after writing this mail } originally, I guess it would be possible to drop format.coverauto } altogether and tell users to use: } } % git config --global alias.fp format-patch --cover-letter } } I don't know which solution would be preferred. If it's the user-should- } use-an-alias approach, I'll create a series that gets rid of } format.coverauto changes.

I obviously was missing quotes around the alias's value but then, 'git fp' would do exactly what I'm after with this series. You could just set format.coverletter to 2 and use 'git fp'. You always get a cover letter for patch series longer than one patch.

The other approach, to create yet another subcommand just for this would be too much IMHO. There are enough of them already.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925