Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Thu, 31 May 2012 19:30:49
Message-Id: CAGfcS_nePh15jraTk+kQdyxakvgiqXcounWUU4muH6PPGWhqkg@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by "Robin H. Johnson"
1 On Thu, May 31, 2012 at 3:13 PM, Robin H. Johnson <robbat2@g.o> wrote:
2 > - You have a commit, that you want to put into the Gentoo tree.
3 > - You have already pushed it to your github, signed
4 > - It needs to be merged/rebased so that it applies on the Gentoo tree.
5 > - If you force it to be a rebase so it applies on the tip, then you may
6 >  have changed the history of your github tree, and broken any further
7 >  forks.
8 > - If you permit a merge instead, nobody gets broken.
9
10 Maybe the best compromise is to tell people that if you push to
11 "master" on other repositories, you get to deal with the mess. If we
12 try to keep side overlays/etc working on branches and not on master
13 then there will be no history to rewrite, as the merge will be rebased
14 when it hits the official master, and from there it will get pulled by
15 other repositories.
16
17 We can perhaps allow merge commits on other branches, where the
18 continuity of history is less important.
19
20 Does that make sense?
21
22 > You'd be excluding me entirely, I need to use git-svn for other work
23 > projects, and emerging between two different versions of git would be
24 > very annoying (I switch constantly between the sides of work as they
25 > overlap).
26
27 I'm a big proponent of letting the people doing the work scratch their
28 own itches first! However, this does make us dependent on upstream -
29 is there any sense of when they'll be ready, or what their own
30 priority is for this issue. If this is becoming a deprecated feature
31 then I'm not sure we can tie our future to it.
32
33 I wasn't sure if any of the existing git-svn bugs pertained to this
34 issue. Either way we should add this as a blocker to the git
35 migration tracker.
36
37 I think that even if we made a big push it would still take us a month
38 or two to be ready with docs/infra/etc, and that might be optimistic.
39 So, this might not be rate-limiting if upstream is actively working on
40 it.
41
42 Rich