On Tue, Aug 8, 2017 at 8:02 AM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Tue, Aug 8, 2017 at 4:38 AM, Christopher Li <sparse@xxxxxxxxxxx> wrote: >> >> You need to make "for-chris" fast forwardable from master. >> > > It's possible to work like this too if you wish so. > It means that this 'for-chris' becomes the integration tree and > all patches need to go through this tree first. More precisely, the "for-chris" will be come the proposal of the integration tree. If I am happy with "for-chris" and Luc don't intend to rebase "for-chris" any more. The master can just sync up to the "for-chris". Everybody is happy. If I have some feed back for "for-chris" V3 and Luc decide to incorporate the feed back and come back with "for-chris" V4. Notice the "for-chris" V4 does not need to be fast forwardable from V3. If Luc wants the V4 contain a "clean" history, he is free to do so. Of course he want to have incremental change from V3 -> V4, V3 will show up in master history. That is of fine too. It is Luc's call. That effective make Luc control what become the master branch. It does mean that patch in sparse-next will go through Luc's "for-chris" to become part of master. The net effect is that, if Luc and I want to clean up the experimental history, we can do so. Those V1...V3 internal version don't have to show up on master. >From my point of view, I think that is the model Luc and I already agree on about two month back, when we have the discussion how to do git pull properly for sparse using pull request. I kind of see Luc doing that for sparse up to RC3, He is already integrating the static assert patches etc. Luc's is not using a "for-chris" branch though, I did not insist either. I did not realized that there is an understand gap how this git pull request will work on Luc's side. I did not see the proper git pull request I assume those patch on mailing list are for discussion/experimental only. I have send email to clarify those are for git pull or not. I hope that clear up the git pull situations on sparse-next. If it helps, I can also rename spase-next to "unstable". I am also open to suggestion for how this integration should be done. The original intend for having this complex model is to get rid of the dirty history. If that turn out to be the bigger evil. We can do the other way around as well. 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
