On Tue, Aug 8, 2017 at 12:10 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > I am not sure why you consider some history "dirty". I think all > history is good as it tells people how the change evolved, If you > apply a patch and a bug is found, or you want to amend the patch For example, there is some internal version of patches has some compile error. That definitely don't want to be part of the history. It will hurt the binary search. Some patch in the early version might be totally wrong, that does not need to go into history. e.g. the revert of the change and revert of the revert later on. I consider a patch will take some time and experiment to mature. We don't have to submit every generation of the patch into history. > somehow, in my view there should simply be another patch or change > done following the original rather than trying to backout history and > redo the patch. I am not a git expert so I cannot comment on the git > processes but conceptually I am saying that all history is good. If follow the process I suggested, that ultimately give Luc the flexibility to use the linear incremental history or the clean up version of the history. He has the most pending changes. I prefer the clean up histories, but I can do the all detail dirty history as well if that is we all agree to do. Chris -- 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
