On Thu, Nov 24, 2016 at 12:35 PM, Josh Triplett <josh@xxxxxxxxxx> wrote: > Probably doesn't need a separate integration repository; if you want to > stage changes that you don't know you want to ship yet, a "next" branch > in the main repository would be easier for people to find and use. If > you just want to give changes time to stabilize, you can probably put > them on "master" and just not release them yet. I want a branch I can publish for others to review and test. At the same time I want to be able to go back and modify the history of the patch, merge and squash fix for the already applied patch. That "next" branch will not be pull stable, is it acceptable? I saw linux-next has a separate repository and the master branch is not pull stable. At the same time there are tag like next-20161121 to reference old branch. I assume I can do the similar thing. The question is that does it need to be a separate repository? As long as people don't expect pull stable from that "next" branch, I am fine with putting it under the sparse main repository. I guess there is other implications on the git repository size. If the repository get rewind and modify very often, it might cause the git pack file contain a lot of useless head not part of the stable master branch. I don't think sparse next branch will rewind that often, but that is some thing to consider as a separate repository. 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
