Re: [PATCH] Make badopt.test stricter (by enabling `set -e').

[Ralf Wildenhues]

Hello Stefano,

* Stefano Lattarini wrote on Wed, Apr 21, 2010 at 01:59:51PM CEST:
> In fact, I'm inclined to keep the patches enabling `set -e' separated
> for three reasons:
> 
>   1. To make the analysis of these patches simpler (as they are very
>   short); this should tendentially lead to more accurate reviews --
>   which is very important for the kind of changes introduced by the
>   patches, because, as you pointed out in a previous thread, the
>   `errexit' shell flag is particularly prone to portability problems
>   and bugs.
> 
>   2. To make it easy for you to reject changes deemed unworthy,
>   dubious or dangerous, and to make it easier for me to amend
>   changes (if required).

> However, I could at least clump the changes in bigger lumps (say a 
> dozen of files modified togheter), if you still think this would be more 
> convenient.  WDYT?

Yes, that would be better, because it would lower the per-patch effort.
Thanks.

>   3. So that the changes can be done incrementally, maybe even on
>   an extended time period (which should alleviate the "not enough
>   time for the review" problem).

For what it's worth, since git this issue should be fairly moot.
You can keep branches for a long time, and merge them into your
devel-branch-du-jour for testing them.  You can squash stuff into
them.  You can rebase them if you think that would help you, but
frankly, don't.  Just keep the patch from where you developed it,
unless it requires newer stuff.  When that happens, you can either
rebase, or merge maint (or whatever else newer you need) into your
branch and continue.  Only then, you would need to start publishing
trees or git bundles, so that merges are handled upstream.

Cheers,
Ralf