On Thu, Nov 24, 2016 at 01:03:32PM +0800, Christopher Li wrote: > 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. Rebasing a "next" branch, as long as you clearly document that, seems fine. > I assume I can do the similar thing. The question is that does it > need to be a separate repository? I don't think so, no. > 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. git will automatically discard any unreferenced objects when repacking. But even if you archive the old versions of "next" using branches or tags, it still won't take up that much space, compared to linux.git for instance. -- 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
