Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Georg Baum wrote:
| | > Abdelrazak Younes wrote:
| | >
| | >> I will commit to my branch to let Lars the time to review this patch. I
| | >> hope he will not be upset to have multiple fix in the same branch.
| | > I fear he will, because this has nothing to do with the other stuff
| | > in your
| | > branch.
| |
| | It has because it is only triggered with my BufferView changes. But
| | really, I think it is a perfect illustration of the failure of the
| | current commit procedure.
You have to spell it out. I have the attention span of a gold fish,
and do not really know what part of the commit procedure you are
talking about now.
I am not going to explain it all for the tenth time so no I won't expand.
| |With a distributed SCM (git, mercurial, etc)
| | my current practice would be encouraged.
We are not using a distributed scm.
Thanks for clarifying the obvious.
| | I cannot at the same time do
| | very small patches so that everyone can understand and wait tomorrow
| | for committing to trunk and then merging trunk with my branch.
|
| Sure you can.
And to expand a bit:
Create a branch (under younes... you said you would change
that right?), a prisitine copy of trunk. Add small tuff there (if you
are not confident that you can commit to trunk without controversy),
Well I was confident (and so were other IMHO) that the fixes were not
controversial. But the point is that every single line of code change in
the kernel is controversy to you.
then point us either at the patch or the revision number.
Then patches can (as long as they are not dependent on eacy other) be
cherry picked and merged easily to trunk.
Talk about an easy procedure. It's too complicated for me, so no thanks.
Abdel.
