Well, the need to amend single patches --- and folding the amendment in
before mainline submission to correct important problems of the first
shot --- is something which happens all the time.
(People will have different opinions about what is important enough to
redo a patch instead of keeping the amendment separate.)
In my experience, the submission branch cannot practically be the same
as the development branch (I mean, a true ancestor of the of the
development branch). That's simply because the order of submission is
different.
The only way to keep commits from the development branch identical in
the submission branch would be to work with a huge number of topic
branches, with the number of branches approaching the number of commits.
But then testers and developers would still work with merge commits
which will not appear in the mainline submission. And there would be
weird histories because of the need to merge from other trees, notably
from torvalds/linux-2.6.git when necessary to avoid conflicts.
(I for one rebuild the development branch of linux1394-2.6.git from
scratch after 2.6.x-rc1 came out, then keep its history until 2.6.x.
During that time I occasionally 'pollute' it with reverts and with
merges from torvalds/linux-2.6.git. These will not be carried over into
the submission branch.)
--
Stefan Richter
-=====-==--- -=-- ==-=-
http://arcgraph.de/sr/
--
