Barry Warsaw writes:
I personally think that rebase is an abomination generally required by workflow policies that try to overcome tool deficiencies. By not *requiring* rebase (it is of course possible), it means that all your intermediate commits are preserved
No VCS "requires" rebase, or removing commits from history.
because sometimes they are useful. Most of the time you can ignore them which is exactly how it should be, IMHO.
This is the nub of the argument. bzr mandates a presentation of history that bzr fans like, and some folks don't. I'm not a big fan of bzr log -n# for any value of # AFAIK ;-), but I'm willing to try different things as they seem useful.
In a well-developed branch, that rationale should be included in the intermediate commit messages of the proposed branch (not to mention good comments in the code <wink>). Rebasing that away just seems *wrong* to me.
That is not the purpose of rebase, and I doubt any well-managed project permits it.
As far as the attributions go, I think the best place to be explicit is in the NEWS file. Folks getting Mailman via tarball or distro package won't have access to the VCS history anyway.
False. It's less convenient for them, but they can browse launchpad.
Anyway, the NEWS file is way too coarse for the purposes that Wacky and I have in mind. Eg, George may need some changes to the IArchiver interface, and send you a branch that makes them. But a crucial patch may have been suggested and supplied by a mentor. I trust that you'll mention George in NEWS, but will you even be aware of the contributions by third parties?