Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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.
Reply to: