On Mon, Aug 07, 2017 at 07:32:37PM -0400, Christopher Li wrote:
> That being said, what is your recommended way to fix it instead
> of rebase?
>
> We can still fix up sparse-next as I haven't push to master.
There was something like:
.. rc4 - fix-crashes-v3 - some others patches - sparse-next
\ noipa = master
Where master must be stable and fix-crashes-v3 is the external branch.
The external branch is fast-forwardable to master but not always
based on the top of it (because it was developed & tested earlier).
So late in the release and with sparse-next having received
quite a bit testing I would expect to be stable (in the git meaning)
and master to be fast-forwardable to it.
So, IMO the thing to do in this case would have been to merge
the external branch with master and only rebase the others patches
on top of this merge point. So we would have something like this:
.. rc4 - fix-crashes-v3 - some others patches - sparse-next
\ noipa = master /
but instead, because of the rebasing, we have:
.. rc4 - fix-crashes-v3
\ master - rebased-fix-crashes-v3 - some others patches - sparse-next
and this create problems for development done on top of the external branch
(basically you force them to also rebase their work or to have duplicated
commits in the tree).
The correct workflow is to never rebase anything you pulled.
That said, I think that part of the problem is that things stay for too long
in this sparse-next. As soon as something is tested well enough, it should
move to master.
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
