On 31 March 2017 at 13:19, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Fri, Mar 31, 2017 at 12:04 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote: >> On Fri, Mar 31, 2017 at 5:25 PM, Luc Van Oostenryck >> <luc.vanoostenryck@xxxxxxxxx> wrote: >>> I understand perfectly that you're comfortable with your tools but I >>> think you're >>> overestimating them (remember how we had some patches that have been >>> wrongly and silently been merged? It's scary as hell!) and hugely >>> underestimating >> >> Well, I can try the git merge. On that case you bring up, it is a conflict >> resolving. Even if I am using git merge I could still resolve the >> conflict in the >> wrong line order, because at that point and time, I don't think it matters. >> Now I will not try to resolve it that way. > > Merge conflicts are fine, not a problem at all. The problem is if they are not > detected or if, in the case we're talking about, the tools try to be too smart, > use a too small context and apply a patch where it should never have been. > >>> Also, you must understand how unpractical your workflow is for others. >>> Especially the fact that everything is always rebased, make things much >>> more complicated than needed for my topics branches. The fact that often >> >> It is not always rebase. I don't do rebase for no reason. > > Of course, it's not what I meant. > What I wanted to say is that since the patches are applied from email > (via patchwork, quilt, git am, ... ) they necessarily have a different parent > that they had on the developer side, thus a different history. > While this is not really a problem for a few isolated patches, > it becomes a problem when you're developing several series: > the newer ones depending on the old ones. > And the longer it takes for patches to reach the upstream tree, > the more the dev tree and the official tree (can) diverge and when it > accumulate, it create problems. > >> The often situation >> is that, I applied a patch series. Then there is an update of the series which >> change some patch in that series. > > IMO, the whole series need to be throwed away, awaiting for a new version > of it. > >> I can totally using the git merge as interface to operate and make patch series >> as my internal tool to review git commits. But that is not going to >> get rid of rebase. >> Rebase is because we want clean history. > > I'm not sure what you mean by "clean history" and what is the advantage. > If you hate revert, and patches to correct others patches, I wholly understand > I hate this also. It's why a serie would reach upstream when really finished, > well tested and so one. > >> e.g. If you send me a git merge request for V4, then I merge it on spase-next. >> Then you release V5 branch with clean up history. Then I drop V4 and merge >> V5 on sparse-next. Is that more acceptable to you? >> >> We can try the merge with feature branch model and see how it goes. >> >>> you take patches in an order different that the submitted one doesn't help. >>> And things like the mis-merge force me to rebase my branches to compare >>> with what you have taken just to see if there wasn't another problem. >>> >>> Very inefficient for me and ultimately for you too, believe me. But well ... >> >> Let's try that. We can start with merge request. > > OK, I can resent everything properly for a pull request. > Let me know exactly what you need/want. > >>> >>> At least one thing that would already help a lot would be to limit the time >>> between a patch is submitted and the one where it is in a stable tree >>> (and sparse-next is not, certainly not its tip). >> >> The reason to have sparse-next for me is allow to have clean history >> for master branch. >> >>> Also, I think that implicitly in Linus' message was that a maintainer, with >>> limited time, should not have to play a bit with a patch and then move on >>> to the next one. >> >> The actual time spend is on review and testing the patch. Simple apply >> takes no time for me all. As I said, I can make the patch thing as internal >> tool to help me review commits. > > Sure, I understand that. > > -- 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 -- 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
