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: > >> On Thu, May 14, 2009 at 5:41 PM, Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > >> > So here's my second plan: > >> > 1. instead of doing the cherry-picking in a single repository, it might > >> > be helpful to do it in separate repositories: one repository for each > >> > direction. While there are still two remote svn repositories in each > >> > svn repository, there is no need for criss-cross anymore. The flow > >> > of the data is in one direction and it seems (at least at first glance) > >> > I can use git-svn-rebase to get a linear history. > >> > >> it's still criss-crossing, it's just less obvious that way. One > >> repository is exactly the same as two repositories in git; all that > >> matters is the branch histories. > > > > Yeah, I see... But this step is here _only_ to get the existing svn > > repositories in sync again. After cherry-picking and dcommitting, those > > cherry-pick repositories would be wiped. They have no real history. The > > steps I outlined in my previous mail wouldn't even create any files in > > the .git/refs subdirectory. > > Hmm, getting them in sync the first time seems to be "easy" > (relatively), in that you've already done it, right? No. I have a perl script to do the cherry-picking and to resolve conflicts. Because of this, I can try out different methods to do the sync. And of course, I'd like to do it in a way that produces the least problems in the future, since this is a one-shot thing. > >> 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). > > If someone has patches that they don't want to send back to Linus, and > those patches are intermixed with ones they *do* want to send back, > then they either have to cherry pick them over to a separate branch > (which Linus can then pull), or equivalently they email individual > patches to Linus, or they need to rebase a lot, or they need to just > put their "finished" patches onto a separate branch and keep the > unfinished ones somewhere else that Linus won't pull. Does any description exist how this process works in detail? > Rebasing is (I think) actually the most common solution to this > problem, but it doesn't help if you're using svn. svn has no concept > of rebasing. (git svn rebase uses git rebase, but it's not really for > the same purpose.) In the long term, I am willing to get rid of svn. But I have to create a migration path, so I need to keep git+svn in parallel for a couple of months. -- 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