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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
