Ian Jackson writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)"): > It is very unfortunate for git that most of its advocates want to > adopt these almost unmanageable development practices along with the > revision control software.
I'd like to expand on this, and partly reiterate what John Goerzen said earlier about other revision control systems. If dpkg were in darcs, bzr or arch, hardly anyone would seriously suggest a workflow like the suggested git-rebase; we've heard that it's in a minority amongst hg users as well. Everyone would assume that we would use the workflow I am proposing. That workflow is indeed supported by git. So it is clear that my suggested workflow is not inherently unacceptable or unworkable for dpkg. Is it really the case that just because git has this rebase functionality (which is designed for submitting patches in enormous projects), we must use it ? Surely the question is whether the benefits of the rebase workflow outweigh the costs. Costs: * Code changes need to be reworked and reorganised * Commit logs need to be reedited * Code needs to be retested after the above changes have been made, probably several times * The commit logs do not reflect reality Benefits: * It is somewhat easier to read the diffs when considering whether to merge, or whether to do substantial structural rework first * The commit logs are neater The first one of those two benefits is obviously the only one that is relevant. But it can only be relevant if there is some doubt as to whether my triggers code should be merged without substantial rework. Surely it must be clear that it should ? The specification was discussed extensively and agreed in the appropriate Debian fora. The implementation has been deployed and tested in a very widely used Debian derivative. The cost of attempting to reorganise the timeline of code changes should not be underestimated. It's not just the work (and its tiresome nature). These kind of activities, like merging, are very error-prone. Ie, if we adopt the rebase workflow the result is likely to have more bugs. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]