On Fri, May 15, 2009 at 03:05:14PM -0400, Avery Pennarun wrote: > On Fri, May 15, 2009 at 1:52 PM, Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > > On Thu, May 14, 2009 at 05:57:00PM -0400, Avery Pennarun wrote: > >> I'd say that basically none of your problems have anything to do with > >> svn's lack of merge support, and everything to do with the fact that > >> you aren't doing all your changes first on a 'public' branch and then > >> merging from there into the private branches. (That's really not so > >> hard to do in svn either, and would save a ton of confusion.) > > > > The problem here is that it does not match the work flow. IMHO, my work > > flow is very similar to the work flow of the kernel, so I fail to see why > > it can not work. See the analogies: > > > > kernel: Submodule maintainers are committing into private repositories > > me: People are committing into private repositories > > > > kernel: Those commits are forwarded to Linus's repository > > me: Those commits are forwarded to the public repository > > > > kernel: Maintainers receive commits for other submodules from linus > > me: Commits are distributed from public to private repositories > > There is one critical difference here: if someone merges from Linus > and then Linus merges back from them, then the two resulting > repositories will be *identical* (at least, the trees will be; if the > second merge uses --no-ff, the histories will be very slightly > different, but not importantly so). Hmm, maybe submodules could be of some help here? If I put the generic content into a submodule, and the localized content into (multiple) superprojects, the kernel work flow should be easy to adopt, or am I missing something? -- 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