On Thu, May 31, 2012 at 3:13 PM, Robin H. Johnson <robb...@gentoo.org> wrote: > - You have a commit, that you want to put into the Gentoo tree. > - You have already pushed it to your github, signed > - It needs to be merged/rebased so that it applies on the Gentoo tree. > - If you force it to be a rebase so it applies on the tip, then you may > have changed the history of your github tree, and broken any further > forks. > - If you permit a merge instead, nobody gets broken.
Maybe the best compromise is to tell people that if you push to "master" on other repositories, you get to deal with the mess. If we try to keep side overlays/etc working on branches and not on master then there will be no history to rewrite, as the merge will be rebased when it hits the official master, and from there it will get pulled by other repositories. We can perhaps allow merge commits on other branches, where the continuity of history is less important. Does that make sense? > You'd be excluding me entirely, I need to use git-svn for other work > projects, and emerging between two different versions of git would be > very annoying (I switch constantly between the sides of work as they > overlap). I'm a big proponent of letting the people doing the work scratch their own itches first! However, this does make us dependent on upstream - is there any sense of when they'll be ready, or what their own priority is for this issue. If this is becoming a deprecated feature then I'm not sure we can tie our future to it. I wasn't sure if any of the existing git-svn bugs pertained to this issue. Either way we should add this as a blocker to the git migration tracker. I think that even if we made a big push it would still take us a month or two to be ready with docs/infra/etc, and that might be optimistic. So, this might not be rate-limiting if upstream is actively working on it. Rich
