Hi Chris, On 10 August 2017 at 01:18, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On Wed, Aug 9, 2017 at 5:10 AM, Dibyendu Majumdar > <mobile@xxxxxxxxxxxxxxx> wrote: >> >> I think that compile error should not be possible? Because before you >> merge any patch presumably you build Sparse and run the tests? >> >> As for other changes that were later removed - in my view this is >> valuable history as it tells people what was tried and discarded and >> why. I still feel all history is good. >> > > OK. I think my obsession of "clean up the history" is wrong and not worthy > doing. Linus's criticism of sparse-next rebase is correct. I will just got back > to the master doing the normal git pull and merges. That actually simplify > my own work flow as we. > It will also help me if I can assume that a patch will not be re-done. At the moment I cannot apply any patch - because I do not know if a new version of the patch will be published soon. Instead if changes always go forward - i.e. you apply fixes to existing patches - then I can safely apply a patch, and when a fix is published, apply the fix. I learnt from database technology that it is better for changes to always go forward - trying to revert past changes by undoing them is troublesome as it means you may need to undo all changes that follow the one you want to undo. Progress can become very difficult in this approach. That is why in databases, often undo is just another forward change - there is no going back to remove a past change. A really good description of this approach is given in the ARIES approach to database recovery. Regards Dibyendu -- 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
