[PATCH 2 of 2] patchbomb: add --no-intro option

[David M. Carr]

On Friday, March 2, 2012, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> David, Greg, All,
>
> On Friday 02 March 2012 02:41:23 David M. Carr wrote:
>> On Thu, Mar 1, 2012 at 2:31 PM, Yann E. MORIN <yann.morin.1998 at free.fr>
wrote:
>> >> On 29 February 2012, Yann E. MORIN said:
>> >> > # HG changeset patch
>> >> > # User "Yann E. MORIN" <yann.morin.1998 at free.fr>
>> >> > # Date 1330467959 -3600
>> >> > # Node ID 18cdc18bd6cc4bbd9cb9a0512faa6b1151c000e7
>> >> > # Parent  e6fb31285eabdb9f3092860791be954ea826d82e
>> >> > patchbomb: add --no-intro option
> [--SNIP--]
>> > If the first patch is applied, and not the second, then it is no longer
>> > possible for users to properly and easily contribute to
different-policy
>> > projects.
> [--SNIP--]
>> If the first patch was applied, but not the second, wouldn't it still
>> be possible for users to contribute to different projects differently
>> by applying the config in a per-repository config file?
>
> That's doable, but I do not find it very convenient: you have to edit
> that .hg/hgrc config file everytime you clone the repository.
>
> For the (very small) changes I do to Mercurial, I am working with at
> least three clones:
> 1- a pure clone of upstream that I never commit into, but in which I
>   run "hg pull -u" every day.
> 2- a clone of that, for each feature-set I work on, with one versioned MQ
> 3- a qclone of 2 where I do the tests
>
> If I bork clone 3, I can simply trash it and qclone it again to start
> afresh.
>
> Once I have finished a set of changes, I send them from clone 2, and when
> they've been applied/refused upstream, I trash clones 2 and 3, and start
> again from a clean clone of 1.
>
> So, each time I start a new feature set, I would have to remember to edit
> the repository-local hgrc.
>
> OTOH, when I work on my project, I behave as if I was just a contributor,
> and do about the same as I do for Mercurial, but with many more clones,
> one for each feature-set I work on. The only difference is I push directly
> to upstream, instead of going through the ML.
>
> If I was to work on another Hg-based project, I think I would follow this
> procedure, because it is very solid (at least for me!).
>
> The fact is, whatever the solution retained, I would have to settle for
> a default in ~/.hgrc to be the behavior of the majority of projects I
> would contribute to. That's a limitation of .hg/hgrc that does not
> convey configuration options on clone (and that is a sane behavior,
> I believe).
>
>> While I don't like it as a user interface, I
>> think it would be possible to do a one-off equivalent to --no-intro
>> using "--config patchbomb.intro=no" using just the first patch.
>
> Yes, this is possible, too. But for recurrent contribution, --no-intro
> (or --intro) is much easier to type and remember than "--config
> patchbomb.intro=no" (conversely, "--config patchbomb.intro=yes").
>
> But before we go further, I would like to hear from Matt what he thinks
> about all this, so I can adapt/tweak/dump these changes. Matt? ;-)
>
> Regards,
> Yamm E. MORIN.
>
> --
>
.-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
      |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There
is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
conspiracy.  |
>
'------------------------------^-------^------------------^--------------------'
>

If you actually wanted this configuration to spread between your clones, I
believe that the projrc extension might easily handle this for you.

http://mercurial.selenic.com/wiki/ProjrcExtension

-- 
David M. Carr
david at carrclan.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120302/61ad3db9/attachment.html>