Re: A question of workflow

[Patrick Ohly <Patrick.Ohly@gmx.de>]

On Tue, 2007-01-09 at 09:42 +0000, Richard Purdie wrote:
> On Mon, 2007-01-08 at 13:53 -0800, Justin Patrin wrote:
> > On 1/8/07, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
> > > So after every first commmit the tree is in a broken state, where-as if a developers
> > > applied a fixed patch in one go it wouldn't be. Sounds like your concept is badly broken.
> > 
> > Apply, commit (note brokenness if needed in commit message), then fix
> > it, commit, and push. Don't push before fixing.
> 
> The argument against this in other projects like the kernel is that you
> just broke the git-bisect method of debugging...

That's a valid point, although I am not sure whether the same argument
applies to monotone: an OE developer choosing the next pivot version
manually could be smarter than "git bisect" and always pick the version
which includes the fixes for the immediately preceeding patch
submission.

Anyway, it seems like there are contradicting criteria for what is
desirable when pushing patches, and the ones of the core OE developers
absolutely trump the ones from external contributors. It would have been
nice if there had been a solution which worked for both, but that seems
unlikely.

> I'm not a fan of broken patches being committed...

One last word: perhaps there is a middle ground where functionally
correct patches are applied as they are and then cosmetic changes like
fixing the formating or exchanging lines is applied on top of that.
Obviously, its entirely up to the OE developer importing the patch
whether he wants to do that.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly@gmx.de
http://www.estamos.de/