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

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'