[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefano Lattarini
Subject: Re: [PATCH] Make badopt.test stricter (by enabling `set -e').
Date: Sun, 25 Apr 2010 14:42:04 +0200
User-agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.4; i686; ; )

At Sunday 25 April 2010, Ralf Wildenhues <address@hidden> 
> Hello Stefano,
> > 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.
OK, I'll use bigger lumps when it makes sense.

> >   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.
Well, this is exactly what I usually do, and is also very convenient 
for me; but I tought that it would have been less convient *for you* 
to have bigger patches to review, especially if these patches had been 
written incrementally.  Apparently this is not the case: thanks for 
claryfing this out.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]