Hi, On Wed, 6 Dec 2006, Junio C Hamano wrote: > Here is a list of topics that are cooking; the commits marked > with '+' are in 'next', '-' are in 'pu'. Dates are when the > topic was last touched [*1*]. I like the combined pu/next "What's new". > * ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000) > [...] > I think it is sensible to merge to 'master' after that change. Me, too. I really would like this to go in. > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) > + git-merge: preserve and merge local changes when doing fast forward > [...] > It has been in next for some time and unless we hear somebody scream I > think it is Ok to merge to 'master'. This is something I am looking forward to to test. Maybe in "next" for while before putting it into "master"? > * jc/explain (Mon Dec 4 19:35:04 2006 -0800) > - git-explain I vote for putting this into "next" for a wider audience. It also would help people to submit patches (it is kind of a hassle to branch "pu", so I rarely do it myself, whereas my git is based on "next" at all times). > * js/merge (Wed Dec 6 16:45:42 2006 +0100) > > merge-recursive that does not rely on RCS "merge". I use this > exclusively these days. Perhaps cook a little further and > merge to 'master'. Yes, definitely cook it for at least a week; maybe I find the time to check the conflicted merges in git.git at least. > * js/shallow (Fri Nov 24 16:00:13 2006 +0100) > > Probably with a better documentation of its limitations and caveats, > this should be mergeable to 'master'. The more I see the missing reaction, the less sure I am this is a sensible thing to do. And it would need more safety valves, not just documentation. For example, I am not sure if a push from/to a shalow repo is safe. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html