On 12/15/2014 02:46 AM, Mark Cave-Ayland wrote:
> Interestingly enough, I tend to work in a very similar way to this. When
> submitting patches upstream, I tend to rebase on a new branch and then
> squash/rework as required.
Same here, and I find it works really well ... when I do it properly.
I usually have a private development branch that's full of "fixup! "
commits, WIPs, awful commit messages, etc.
Then I have the tree that's been rebased, squashed, and tided up.
I periodically tidy my latest work and replace the old clean tree with
it, then start my new development branch on top of the new clean tree.
This gives me a somewhat nice looking, well ordered patch series to work
on top of, while retaining the flexibility to do lots of quick fixes etc.
Admittedly, sometimes the development tree gets a bit large and it takes
a while before I give it a proper cleanup. My current project being very
much in that category. Still - it works well in general.
> I find that this isn't too bad in practice. If you think about
> monolithic patches during a commitfest, you can imagine that most of
> them will touch one of the core .h files which will require most things
> to be rebuilt once applied during bisection.
It's not build time, it's test-run time. Especially if you can't
automate the test, or it isn't practical to.
That's a legitimate concern - but I don't think we'd see a blowout of
patch counts to quite the same degree.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
