Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Rich Freeman <rich0@g.o>
Subject: Re: Re: Portage Git migration - clean cut or git-cvsserver
Date: Thu, 31 May 2012 15:29:46 -0400
On Thu, May 31, 2012 at 3:13 PM, Robin H. Johnson <robbat2@g.o> 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


References:
Re: Portage Git migration - clean cut or git-cvsserver
-- Alexey Shvetsov
Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Previous by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.