On 10/11/06, Grant Likely grant.likely@secretlab.ca wrote:
On 10/11/06, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0610102309j6fcf7ed4n74e6af179d21f42b@mail.gmail.com you wrote:
This assumes that the "other" repository is kept in a clean state, but this is usually not the case. What happens is this: somebody starts working in his own repo, and does so for a long time without review on the list. Over time, a lot of problems in his code sneak in. When he finally announces his repo and ask to have it merged into the public tree he says: Ummm, now it's too late, it would be too much work to fix all these issues and to re-do all the checkins
True, but that's not your issue. Flame away when someone posts out of date patches. The holder of the non-mainline tree is responsible to make sure his submissions to mainline are clean.
I think it's common practice to have a separate branch for stuff to merge into mainline. Such a branch (called "for-wolfgang", for example) should be based off the latest mainline head and contain one commit for each logical change, i.e. the same rules apply here as for regular patches. After it has been either merged or NAK'ed by Wolfgang, it can be discarded and re-built, possibly with a different set of changes and based off a later mainline head.
This way, the master branch in the non-mainline tree can be kept linear without all the noise from pulling, reverting and fixing being visible in the mainline repository.
[remember the case of the missing CHANGELOG entries in Jon's tree - this cannot be fixed afterwards as these have to be done for each checkin].
With a non-linear merge branch, it's easy to alter existing commit messages, including CHANGELOG entries.
Haavard