[gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input -> no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive load).

"testing git-cvsserver" proses "Clean cut" with the additional ability
to continue using cvs update/commit, - in best case - on the old
checkout w/o alteration on the developers side.

"Clean cut" forces us to clean up out dirty checkouts (I have some
added directories, added ebuilds i hesitated to `repoman commit`).
Plus we have to alter all our hot-wired portage mangling scripts from
cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
checkout + egencache for checkout) and have an automated google-chrome
bump script). But this can be accomplished on a per developer basis,
and slackers don't stall the process.

"testing git-cvsserver" forces us all to test these cvs'ish scripts
and behaviours against a git-cvsserver and report.
We all know that this test-runs will never happen, stalling this bug
till infinity.
Plus infra/"subset of devs marshalling the migration" get stuck
between fixing git issues and git-cvsserver.

*if you still read this* *wow*

Please discuss my arguments and come to the conclusions to
RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
this bug from the blockers of "[TRACKER] portage migration to git".

My lengthy 2 cents.

[1] https://bugs.gentoo.org/333531
[2] https://bugs.gentoo.org/333699
[3] https://bugs.gentoo.org/333705#c2
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
=jXLQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Johannes Huber]

[-- Attachment #1.1: Type: text/plain, Size: 2622 bytes --]

Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
> 
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
> 
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
> 
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
> 
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
> 
> *if you still read this* *wow*
> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
> 
> My lengthy 2 cents.
> 
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> - --
> Gentoo Dev
> http://xmw.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
> =jXLQ
> -----END PGP SIGNATURE-----

I support RESOLUTION WONTFIX, if nobody cares about the bug since it was 
opened it is obvious out of interest. There is no reason to support jurassic 
software. 

Clean cut++

Cheers
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

[-- Attachment #1.2: Type: text/html, Size: 13013 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ian Whyman]

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]

On May 23, 2012 1:55 PM, "Johannes Huber" <johu@gentoo.org> wrote:
>
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
>
> > Hash: SHA256
>
> >
>
> > Hi,
>
> >
>
> > i've looked at the blockers of "[TRACKER] portage migration to git"
>
> > [1] and want to discuss "testing git-cvsserver" [2].
>
> >
>
> > There are two proposed scenarios how to migrate the developers write
>
> > access to the portage tree.
>
> >
>
> > "Clean cut" turns of cvs access on a given and announced timestamp,
>
> > rsync-generation/updates is suspended (no input -> no changes), some
>
> > magic scripts prepare the git repo (according to [3], some hours
>
> > duration) and we all checkout the tree (might be some funny massive
load).
>
> >
>
> > "testing git-cvsserver" proses "Clean cut" with the additional ability
>
> > to continue using cvs update/commit, - in best case - on the old
>
> > checkout w/o alteration on the developers side.
>
> >
>
> > "Clean cut" forces us to clean up out dirty checkouts (I have some
>
> > added directories, added ebuilds i hesitated to `repoman commit`).
>
> > Plus we have to alter all our hot-wired portage mangling scripts from
>
> > cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
>
> > checkout + egencache for checkout) and have an automated google-chrome
>
> > bump script). But this can be accomplished on a per developer basis,
>
> > and slackers don't stall the process.
>
> >
>
> > "testing git-cvsserver" forces us all to test these cvs'ish scripts
>
> > and behaviours against a git-cvsserver and report.
>
> > We all know that this test-runs will never happen, stalling this bug
>
> > till infinity.
>
> > Plus infra/"subset of devs marshalling the migration" get stuck
>
> > between fixing git issues and git-cvsserver.
>
> >
>
> > *if you still read this* *wow*
>
> >
>
> > Please discuss my arguments and come to the conclusions to
>
> > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>
> > this bug from the blockers of "[TRACKER] portage migration to git".
>
> >
>
> > My lengthy 2 cents.
>
> >
>
> > [1] https://bugs.gentoo.org/333531
>
> > [2] https://bugs.gentoo.org/333699
>
> > [3] https://bugs.gentoo.org/333705#c2
>
> > - --
>
> > Gentoo Dev
>
> > http://xmw.de/
>
> > -----BEGIN PGP SIGNATURE-----
>
> > Version: GnuPG v2.0.17 (GNU/Linux)
>
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> >
>
> > iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
>
> > VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
>
> > =jXLQ
>
> > -----END PGP SIGNATURE-----
>
>
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it was
opened it is obvious out of interest. There is no reason to support
jurassic software.
>
>
>
> Clean cut++
>
>
>
> Cheers
>
> --
>
> Johannes Huber (johu)
>
> Gentoo Linux Developer / KDE Team
>
> GPG Key ID F3CFD2BD
>
>

Another vote for clean cut from me.

[-- Attachment #2: Type: text/html, Size: 4686 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

On 05/23/2012 07:54 AM, Johannes Huber wrote:
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
> Hi,
> 
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
> 
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
> 
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
> 
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
> 
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
> 
> *if you still read this* *wow*
> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
> 
> My lengthy 2 cents.
> 
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> 
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it was 
> opened it is obvious out of interest. There is no reason to support jurassic 
> software. 
> 
> Clean cut++
> 
> Cheers

clean-cut++

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

+1 for killing cvs


Johannes Huber писал 2012-05-23 15:54:
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>
>> Hash: SHA256
>
>>
>
>> Hi,
>
>>
>
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>
>> [1] and want to discuss "testing git-cvsserver" [2].
>
>>
>
>> There are two proposed scenarios how to migrate the developers write
>
>
>> access to the portage tree.
>
>>
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>
>> rsync-generation/updates is suspended (no input -> no changes), some
>
>
>> magic scripts prepare the git repo (according to [3], some hours
>
>> duration) and we all checkout the tree (might be some funny massive
> load).
>
>>
>
>> "testing git-cvsserver" proses "Clean cut" with the additional
> ability
>
>> to continue using cvs update/commit, - in best case - on the old
>
>> checkout w/o alteration on the developers side.
>
>>
>
>> "Clean cut" forces us to clean up out dirty checkouts (I have some
>
>> added directories, added ebuilds i hesitated to `repoman commit`).
>
>> Plus we have to alter all our hot-wired portage mangling scripts
> from
>
>> cvs'ish to git'ish (I use my read/write checkout as portage tree
> (cvs
>
>> checkout + egencache for checkout) and have an automated
> google-chrome
>
>> bump script). But this can be accomplished on a per developer basis,
>
>
>> and slackers don't stall the process.
>
>>
>
>> "testing git-cvsserver" forces us all to test these cvs'ish scripts
>
>> and behaviours against a git-cvsserver and report.
>
>> We all know that this test-runs will never happen, stalling this bug
>
>
>> till infinity.
>
>> Plus infra/"subset of devs marshalling the migration" get stuck
>
>> between fixing git issues and git-cvsserver.
>
>>
>
>> *if you still read this* *wow*
>
>>
>
>> Please discuss my arguments and come to the conclusions to
>
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>
>
>> this bug from the blockers of "[TRACKER] portage migration to git".
>
>>
>
>> My lengthy 2 cents.
>
>>
>
>> [1] https://bugs.gentoo.org/333531
>
>> [2] https://bugs.gentoo.org/333699
>
>> [3] https://bugs.gentoo.org/333705#c2
>
>> - --
>
>> Gentoo Dev
>
>> http://xmw.de/
>
>> -----BEGIN PGP SIGNATURE-----
>
>> Version: GnuPG v2.0.17 (GNU/Linux)
>
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>>
>
>> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
>
>> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
>
>> =jXLQ
>
>> -----END PGP SIGNATURE-----
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it
> was opened it is obvious out of interest. There is no reason to
> support jurassic software.
>
> Clean cut++
>
> Cheers

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Anthony G. Basile]

On 05/23/2012 10:39 AM, Alexey Shvetsov wrote:
> +1 for killing cvs
>
>

Looks like the bloodbath begins.  I too am in favor of killing cvs.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Wed, May 23, 2012 at 10:43 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>
> Looks like the bloodbath begins.  I too am in favor of killing cvs.

Please, let it die.  I'll miss my scripts, but I'll gladly deal with
that over whatever breakage comes along every time some cvs plugin
messes up the tree, or we can't use some useful git feature because
cvs amazingly enough behaves like an scm invented 20 years ago.

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]


> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
> 

+1

Please cut cvs support once and for all.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/23/2012 09:25 AM, Andreas K. Huettel wrote:
> 
>> 
>> Please discuss my arguments and come to the conclusions to 
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and
>> remove this bug from the blockers of "[TRACKER] portage migration
>> to git".
>> 
> 
> +1
> 
> Please cut cvs support once and for all.
> 
+1 for clean cut
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+85e4ACgkQVxOqA9G7/aDWpgD/SYfC3aOlOP2kAwK3qt81smH8
YWs60Kl77Xx+wIM1jx8A/0PkisxPTsLE5jR59GhaDmC+epoodW1GOak//pAvCmCG
=F8Rw
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Fabio Erculiani]

Please kill CVS with fire!
I've been waiting for this since 2009.

-- 
Fabio Erculiani

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michael Palimaka]

On 2012-05-23 22:42, Michael Weber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
>
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
>
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input ->  no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
>
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
>
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
>
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
>
> *if you still read this* *wow*
>
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
>
> My lengthy 2 cents.
>
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> - --
> Gentoo Dev
> http://xmw.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
> =jXLQ
> -----END PGP SIGNATURE-----
>
>
Another vote for clean cut.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[justin]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On 23/05/12 14:42, Michael Weber wrote:

> Hi,
> 
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
> 
> "Clean cut" turns of cvs access on a given and announced timestamp,


I want to see to it gone. +1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Sergei Trofimovich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 for git switch.

git-cvsserver would make sense if it would be completely transparent
for cvs client. and it's not. so why bother setuping fragile things?

- -- 

  Sergei
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk+9ETgACgkQcaHudmEf86pHTgCgh0lWhRz5VAf0N9xRPOE4gld3
IXIAn1Q9q7BSaIGZpiUHgATng2rBVBWZ
=vbwK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Wed, 23 May 2012 14:42:37 +0200
Michael Weber <xmw@gentoo.org> wrote:

> *if you still read this* *wow*
> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".

Kill it! And while we're at it, kill ChangeLogs as well!

/me hides...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 210 bytes --]

> On Wed, 23 May 2012 14:42:37 +0200
> 
> Kill it! And while we're at it, kill ChangeLogs as well!
> 
> /me hides...

+1
+1
+1
+1
...

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Michał Górny писал 2012-05-23 19:33:
> On Wed, 23 May 2012 14:42:37 +0200
> Michael Weber <xmw@gentoo.org> wrote:
>
>> *if you still read this* *wow*
>>
>> Please discuss my arguments and come to the conclusions to
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>> this bug from the blockers of "[TRACKER] portage migration to git".
>
> Kill it! And while we're at it, kill ChangeLogs as well!
>
> /me hides...

Well this can be done with *meaningfull* git commit messages =D

so +1

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Am Mittwoch, 23. Mai 2012, 18:33:41 schrieb Michał Górny:
> On Wed, 23 May 2012 14:42:37 +0200
> 
> Michael Weber <xmw@gentoo.org> wrote:
> > *if you still read this* *wow*
> > 
> > Please discuss my arguments and come to the conclusions to
> > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> > this bug from the blockers of "[TRACKER] portage migration to git".
> 
> Kill it! And while we're at it, kill ChangeLogs as well!
> 
> /me hides...

with "git log some-cat/foo" we will have it automagically.

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
The primary reasons to continue to support CVS-style access via
git-cvsserver:
1. Lightweight partial/subtree checkouts
   - Git has implemented subtree checkouts, but they still bring down a
	 fairly large packfile.
2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

If we can get rid of #2, we're willing to live with #1.

> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
1. You will be given git bundles instead of being allowed to do initial
   clone. That way it's just a resumable HTTP download.
2. rsync generation is NOT going away. Users will still be using it.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Robin H. Johnson писал 2012-05-23 19:47:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
>    - Git has implemented subtree checkouts, but they still bring down 
> a
> 	 fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

Isnt git works with shallow clone? like
# git clone --depth 1 <or any other desired value> 
git+ssh://gitrepo.uri::repo

So you can clone in this manner and push changes back

Also for depth = 1 pack size will be similar to gzipped rsync snapshot 
(~40M)


> If we can get rid of #2, we're willing to live with #1.
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive 
>> load).
> 1. You will be given git bundles instead of being allowed to do 
> initial
>    clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote:
> Isnt git works with shallow clone? like
> # git clone --depth 1 <or any other desired value> 
> git+ssh://gitrepo.uri::repo
> 
> So you can clone in this manner and push changes back
> 
> Also for depth = 1 pack size will be similar to gzipped rsync snapshot 
> (~40M)
The shallow clone is still a shallow clone of the entire repo, and you
get the subtree checkout as just part of that.

Shallow clones are also read-only last I checked.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Robin H. Johnson писал 2012-05-23 20:19:
> On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote:
>> Isnt git works with shallow clone? like
>> # git clone --depth 1 <or any other desired value>
>> git+ssh://gitrepo.uri::repo
>>
>> So you can clone in this manner and push changes back
>>
>> Also for depth = 1 pack size will be similar to gzipped rsync 
>> snapshot
>> (~40M)
> The shallow clone is still a shallow clone of the entire repo, and 
> you
> get the subtree checkout as just part of that.
>
> Shallow clones are also read-only last I checked.

That isnt true =) you can commit from shallow clone  if and only if 
original repo doesnt have a branching and merging points before and 
after shallow clone point respectively
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov <alexxy@gentoo.org> wrote:
>
> That isnt true =) you can commit from shallow clone  if and only if original
> repo doesnt have a branching and merging points before and after shallow
> clone point respectively
>

Is that going to be a practical condition to maintain?

And how big will the repository actually be?  Are we talking a GB or
two, or something orders of magnitude larger?

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Rich Freeman писал 2012-05-23 20:32:
> On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov <alexxy@gentoo.org> 
> wrote:
>>
>> That isnt true =) you can commit from shallow clone  if and only if 
>> original
>> repo doesnt have a branching and merging points before and after 
>> shallow
>> clone point respectively
>>
>
> Is that going to be a practical condition to maintain?
>
> And how big will the repository actually be?  Are we talking a GB or
> two, or something orders of magnitude larger?
>
> Rich


Full clone will be about 1G or so but no more then 2. If we will drop 
changelog it will be much smaller

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 24 May 2012 05:35, Alexey Shvetsov <alexxy@gentoo.org> wrote:
> Full clone will be about 1G or so but no more then 2. If we will drop
> changelog it will be much smaller
>

And if you use git commit signing instead of ebuild manifests,
intra-commit churn will almost be negligible. :D


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Kent Fredric писал 2012-05-24 13:02:
> On 24 May 2012 05:35, Alexey Shvetsov <alexxy@gentoo.org> wrote:
>> Full clone will be about 1G or so but no more then 2. If we will 
>> drop
>> changelog it will be much smaller
>>
>
> And if you use git commit signing instead of ebuild manifests,
> intra-commit churn will almost be negligible. :D

Yep. Each signature to manifest adds ~512B of echanged data. And this 
will be added every commit. Also Manifest contain checksumms for all 
filesincluding ebuild, patches, metadata and so on. thin-manifests will 
contain only DIST data so they will be much smaller
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Wed, May 23, 2012 at 01:32:45PM -0400, Rich Freeman wrote:
> On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov <alexxy@gentoo.org> wrote:
> >
> > That isnt true =) you can commit from shallow clone  if and only if original
> > repo doesnt have a branching and merging points before and after shallow
> > clone point respectively
> Is that going to be a practical condition to maintain?
We're going to have lots of branches and merges.

> And how big will the repository actually be?  Are we talking a GB or
> two, or something orders of magnitude larger?
In terms of repo size, we were going to be slicing the history into two
parts:
- fresh start
- historical

The 'fresh start' is what new commits will go on top of, and ranges
40-120MB depending on what git window compression is used.
The historical is ~1.2GB, and if you want a continuous history, you just
use graft to merge the two.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Chí-Thanh Christopher Nguyễn]

Alexey Shvetsov schrieb:
>> Shallow clones are also read-only last I checked.
> 
> That isnt true =) you can commit from shallow clone  if and only if
> original repo doesnt have a branching and merging points before and
> after shallow clone point respectively

There can also be breakage when someone reverts a commit that it is not
part of your shallow clone's history, and then you pull.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rafael Goncalves Martins]

-1


-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Arun Raghavan]

I, for one, think we should stay with CVS and leave all this git
Linusware to the new-fangled Fedora kids with their fancy init systems
and tight coupling. CVS was good enough for my grandfather, and it's
good enough for you.
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Nirbheek Chauhan]

On Thu, May 24, 2012 at 1:07 AM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.
>

+1

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Fabio Erculiani]

On Wed, May 23, 2012 at 9:37 PM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.

The difference is that while Git is much faster, comes with a very low
WTF/secs rate and really forces you to do things the right way, other
L*********e software is not and I agree with you on this.

my 0.02c ;-)

> --
> Arun Raghavan
> http://arunraghavan.net/
> (Ford_Prefect | Gentoo) & (arunsr | GNOME)
>



-- 
Fabio Erculiani

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 for git

I am more used to it, I find it easier to use regarding the utilities
as well as the gui and it is more consistent.
The fact alone that I can update a single directory in CVS without
updating all others can cause breakage, cause repoman checks may be
erroneous.


On 05/23/2012 09:37 PM, Arun Raghavan wrote:
> I, for one, think we should stay with CVS and leave all this git 
> Linusware to the new-fangled Fedora kids with their fancy init
> systems and tight coupling. CVS was good enough for my grandfather,
> and it's good enough for you.

This sounds rather emotional to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvT/OAAoJEFpvPKfnPDWzgPIH/38QflM4GNiUNo3bC5/8tock
FM03JE1Iln4ThvLl25opwGiO5R8akoD3koroUVPLoWV//QfYmcQIm7k7dJJCk4+m
WSQ6H21fL9v2m6QX7PuJwaENFSFBxu3UFy6BE+39iFJAPBiigH1hbE0rad/twYdr
xhnHZti1rGbaFBeXxlGmdhJYi7dtndyuZgTu0oQFfE0+sAAK2GPe5CGLoOFHdtxS
WCMY3C3cB0R7XPoJwUvvt2KmIEXNWfq6rDW3o6so89VdRSNykwMLdK1eZ+MZidIE
61CAJiuIsT4cKX5pbqo72GtU4tUOkQ6jjaJhofAcrSMYKA0IsxYvFAYnKqO4lh4=
=cdBk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ezequiel Garcia]

On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.


Perhaps it would be instructive if you could tell us one advantage of
cvs over git.

(This is me exposing me to your terrible dev-flames, I was feeling too cold ;)

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Wed, May 23, 2012 at 4:00 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> I, for one, think we should stay with CVS and leave all this git
>> Linusware to the new-fangled Fedora kids with their fancy init systems
>> and tight coupling. CVS was good enough for my grandfather, and it's
>> good enough for you.
>
> Perhaps it would be instructive if you could tell us one advantage of
> cvs over git.
>

Sure.  The slow commit rate encourages careful deliberation before
hitting the enter key, which therefore improves quality.

Then, if you do make a mistake the slow commit rate means that fixing
that mistake can take a long time, which increases the amount of pain
our end-users run into due to the mistake, which leads to lots of
flame wars on -dev.  That means that the guy who made the mistake is
subjected to more public ridicule, and is less likely to do it again,
That improves quality too.

Since cvs doesn't tie together tree-wide changes in a nice way or
allow them to be transactionally completed, individual package
maintainers don't need to be as concerned with the big picture view.
Now as the maintainer of libfoo the fact that somebody changed my
ebuild without making a corresponding change in some profile is
completely hidden from me, and I can go to sleep peacefully without
realizing that my users are all going to have horribly broken systems
in the morning.  Blissful ignorance of end-user suffering improves
developer morale, and helps get rid of pesky users at the same time.

cvs also makes more more aware of what is going on around me.  Anytime
I want to work on something in parallel with the main development
branch I get to manually merge changes in, which keeps me aware of my
place in the world.  That means that I'm less likely to build nice new
features, which means fewer bugs, which improves quality, and may even
drive away users as an added bonus!

See, cvs is really the wave of the future!

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 24 May 2012 08:32, Rich Freeman <rich0@gentoo.org> wrote:
>
> Sure.  The slow commit rate encourages careful deliberation before
> hitting the enter key, which therefore improves quality.
>
> Then, if you do make a mistake the slow commit rate means that fixing
> that mistake can take a long time, which increases the amount of pain
> our end-users run into due to the mistake, which leads to lots of
> flame wars on -dev.  That means that the guy who made the mistake is
> subjected to more public ridicule, and is less likely to do it again,
> That improves quality too.
>
> Since cvs doesn't tie together tree-wide changes in a nice way or
> allow them to be transactionally completed, individual package
> maintainers don't need to be as concerned with the big picture view.
> Now as the maintainer of libfoo the fact that somebody changed my
> ebuild without making a corresponding change in some profile is
> completely hidden from me, and I can go to sleep peacefully without
> realizing that my users are all going to have horribly broken systems
> in the morning.  Blissful ignorance of end-user suffering improves
> developer morale, and helps get rid of pesky users at the same time.
>
> cvs also makes more more aware of what is going on around me.  Anytime
> I want to work on something in parallel with the main development
> branch I get to manually merge changes in, which keeps me aware of my
> place in the world.  That means that I'm less likely to build nice new
> features, which means fewer bugs, which improves quality, and may even
> drive away users as an added bonus!
>
> See, cvs is really the wave of the future!
>
> Rich
>


<meta name="sarcasm" value="on" />

This CVS stuff sounds a bit too uppity and unstable to me, sounds like
we should go back to the tried and true code collaboration by
date-stamped tarballs of the tree which are centralised once a week to
a master tarball.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

El mié, 23-05-2012 a las 17:00 -0300, Ezequiel Garcia escribió:
> On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> > I, for one, think we should stay with CVS and leave all this git
> > Linusware to the new-fangled Fedora kids with their fancy init systems
> > and tight coupling. CVS was good enough for my grandfather, and it's
> > good enough for you.
> 
> 
> Perhaps it would be instructive if you could tell us one advantage of
> cvs over git.
> 
> (This is me exposing me to your terrible dev-flames, I was feeling too cold ;)
> 
> 

I think Arun's comment was sarcastic ;)

I guess that cvsserver bug can be dropped from blockers, no? Now, the
other pending blockers... :(

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Arun Raghavan писал 2012-05-23 22:37:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init 
> systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.

CVS is damn slow. On every cvs up it should stat *all* files and cvs 
entryes
in current state its ~212k files in gentoo-x86. It will be sloow on 
every machine unless you put all this files in ram

Actual number of usefull files is only about ~60k 
(ebuilds,eclasses,metadata.xml,patches)

Its comparable to linux kernel git tree ~42k files

And yes git is much more faster.

PS  if ibm s/360 was good for my grandfather why we all use modern 
intel pc? Lets stay under 1 MIPS machines like s/360


-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.

I hope this is sarcasm or a joke?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Wed, 23 May 2012 15:25:54 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> > I, for one, think we should stay with CVS and leave all this git
> > Linusware to the new-fangled Fedora kids with their fancy init
> > systems and tight coupling. CVS was good enough for my grandfather,
> > and it's good enough for you.
> 
> I hope this is sarcasm or a joke?

Obviously. His grandfather used SCCS.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Wed, May 23, 2012 at 10:37:55PM +0200, Michał Górny wrote:
> On Wed, 23 May 2012 15:25:54 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> > > I, for one, think we should stay with CVS and leave all this git
> > > Linusware to the new-fangled Fedora kids with their fancy init
> > > systems and tight coupling. CVS was good enough for my grandfather,
> > > and it's good enough for you.
> > 
> > I hope this is sarcasm or a joke?
> 
> Obviously. His grandfather used SCCS.

Heh, that's possible, or maybe he even used prodos [1], which was pretty
cool for its time.

William

[1] http://en.wikipedia.org/wiki/PRODOS

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Matt Turner]

On Wed, May 23, 2012 at 3:37 PM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.
> --
> Arun Raghavan
> http://arunraghavan.net/
> (Ford_Prefect | Gentoo) & (arunsr | GNOME)

I seriously cannot tell this is serious, trolling, or sarcasm. If it's
either of the latter two, can we please cut that out? Way too often
sarcasm and inside jokes are misunderstood and we waste a lot of
bandwidth figuring it out.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Justin]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On 23.05.2012 18:47, Robin H. Johnson wrote:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
>    - Git has implemented subtree checkouts, but they still bring down a
> 	 fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
> 
> If we can get rid of #2, we're willing to live with #1.
> 
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive load).
> 1. You will be given git bundles instead of being allowed to do initial
>    clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.
> 

Was this a vote for or against a quick proceeding towards git?
You are probably the one who can judge best if the infra side could be
made ready soonish.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/23/2012 06:58 PM, Justin wrote:
> Was this a vote for or against a quick proceeding towards git?
No, just to decide if git-cvsserver (providing cvs access) should be
part of an "git master tree" szenario.

In bugzie: Should https://bugs.gentoo.org/333699 stay a blocker of
https://bugs.gentoo.org/333531.

No flame about "git over cvs" in general, whether or not sparse
checkouts (i.e. w/o kde-*,gnome-* categories) make sense.

Michael
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+9SfMACgkQknrdDGLu8JCGtQEAiS3Wcsll94w2rqlMP2WpSypU
fLdxa2wjstJ5Y/2iXCcA+wX/p+OwBzjLAxiwKnSl98XlLSIT/Qsxm5H1TvEEJ71w
=k8j9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Matt Turner]

On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

Please don't go to this trouble for the ability to commit to portage
on *really* slow systems.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Matt Turner писал 2012-05-23 19:59:
> On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson
> <robbat2@gentoo.org> wrote:
>> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
>
> Please don't go to this trouble for the ability to commit to portage
> on *really* slow systems.

Isnt cvs too sloow on mips? git is much more faster. Same for arm.
About big repos, well why not use shallow cloned repo. It will work 
with plane history
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/23/2012 07:06 PM, Alexey Shvetsov wrote:

> Isnt cvs too sloow on mips? git is much more faster. Same for arm. 
> About big repos, well why not use shallow cloned repo. It will work
> with plane history

Can we please cut that out.
I do/did arch testing on arm5, ppc, sparc on rsync trees and committed
the changes from my shiny 2007s notebook.
I did hesitate to spread my commit credentials over all these machines.

Michael
- -- 
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+9Sv8ACgkQknrdDGLu8JBFLAEAghjKAQwckMndZfO/gGQyVI3N
butEASSJZYQetyNthUgA/3e5Sf9B93ED/wDSDflKP7YwTVwiFOe5c65Md4vdEsQs
=FW7S
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Robin H. Johnson писал 2012-05-23 19:47:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
>    - Git has implemented subtree checkouts, but they still bring down 
> a
> 	 fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
>
> If we can get rid of #2, we're willing to live with #1.
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive 
>> load).
> 1. You will be given git bundles instead of being allowed to do 
> initial
>    clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.


Another good point for repo size

https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_use_git_for_large_projects.2C_where_the_repository_is_large.2C_say_approaching_1_TB.2C_but_a_checkout_is_only_a_few_hundred_MB.3F_Will_every_developer_need_1_TB_of_local_disk_space.3F
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
> 2. rsync generation is NOT going away. Users will still be using it.
Would users have a way of gaining read-only access? This would be EXTREMELY 
helpful. If not I will be leaving Gentoo for Funtoo in the near future, though 
there are disadvantages to doing this I don't look forward to dealing with.
-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/23/2012 11:14 PM, Dan Douglas wrote:
> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>> 2. rsync generation is NOT going away. Users will still be using
>> it.

First, I'd stick with the current rsync to spread the tree (mirror
work and mirrors+regular rsync users shouldn't notice any backend
switch at all).


> Would users have a way of gaining read-only access? This would be
> EXTREMELY helpful.
Sure, this would be possible like any other git checkout
(layman-git-overlays, github.com, etc.).

Please compare (browsing source and access description)
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git


- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
=dvFZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 24 May 2012 09:48, Michael Weber <xmw@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/23/2012 11:14 PM, Dan Douglas wrote:
>> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>>> 2. rsync generation is NOT going away. Users will still be using
>>> it.
>
> First, I'd stick with the current rsync to spread the tree (mirror
> work and mirrors+regular rsync users shouldn't notice any backend
> switch at all).
>
>
>> Would users have a way of gaining read-only access? This would be
>> EXTREMELY helpful.
> Sure, this would be possible like any other git checkout
> (layman-git-overlays, github.com, etc.).
>
> Please compare (browsing source and access description)
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git
>
>
> - --
> Gentoo Dev
> http://xmw.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
> xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
> =dvFZ
> -----END PGP SIGNATURE-----
>


I think there should most definitely be an official github mirror of
the main tree, just a "read-only" mirror from githubs perspective.

Just how to best do the mirroring is the question

a) Replicate to github when a user does 'push' with a server-side push hook?
      ( Downside: if github goes down, gentoo devs will see it when
they push, and pushing takes longer because the output from the
replicated push is delivered to the original dev )

b) Daemonized hook that monitors for changes in the master repo, and
replicates commits to github after each push

c) Tie it with the rsync tree building system so every time the tree
is built for rsync clients, the master is replicated to github.


Also, this should obviously be force-pushed, so any branch rebases on
the master repo are replicated to the github mirror properly.
-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

On Thu, 24 May 2012 22:17:20 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> On 24 May 2012 09:48, Michael Weber <xmw@gentoo.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On 05/23/2012 11:14 PM, Dan Douglas wrote:
> >> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
> >>> 2. rsync generation is NOT going away. Users will still be using
> >>> it.
> >
> > First, I'd stick with the current rsync to spread the tree (mirror
> > work and mirrors+regular rsync users shouldn't notice any backend
> > switch at all).
> >
> >
> >> Would users have a way of gaining read-only access? This would be
> >> EXTREMELY helpful.
> > Sure, this would be possible like any other git checkout
> > (layman-git-overlays, github.com, etc.).
> >
> > Please compare (browsing source and access description)
> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
> > http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git
> >
> >
> > - --
> > Gentoo Dev
> > http://xmw.de/
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.17 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
> > xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
> > =dvFZ
> > -----END PGP SIGNATURE-----
> >
> 
> 
> I think there should most definitely be an official github mirror of
> the main tree, just a "read-only" mirror from githubs perspective.
> 
> Just how to best do the mirroring is the question
> 
> a) Replicate to github when a user does 'push' with a server-side
> push hook? ( Downside: if github goes down, gentoo devs will see it
> when they push, and pushing takes longer because the output from the
> replicated push is delivered to the original dev )
> 
> b) Daemonized hook that monitors for changes in the master repo, and
> replicates commits to github after each push
> 
> c) Tie it with the rsync tree building system so every time the tree
> is built for rsync clients, the master is replicated to github.

d) Talk with github folks to add our repo as 'mirror'.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ralph Sennhauser]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

On Thu, 24 May 2012 16:40:02 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> d) Talk with github folks to add our repo as 'mirror'.

Can we keep the master on Gentoo hardware please.

Also, there still should be a bug at b.g.o and git format-patch works
just fine for that. Maybe it's only github now but how many places is a
developer supposed to monitor?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser <sera@gentoo.org> wrote:
> Can we keep the master on Gentoo hardware please.
>
> Also, there still should be a bug at b.g.o and git format-patch works
> just fine for that. Maybe it's only github now but how many places is a
> developer supposed to monitor?

I'm actually a little torn on this one.  I'm fine with keeping the
"master" on Gentoo in the sense that this is where the rsync tree gets
generated.  However, gitbub has a lot of tools like pull requests that
could potentially improve workflow, especially for things like proxy
maintainers.  So, letting those teams work more outside of Gentoo and
just push their changes into Gentoo might make sense.

Perhaps github should be viewed as a widely-shared overlay that gets
automatic updates from the main tree in the master branch (or whatever
we call it).  You can work on a branch in github, get it where you
want it to be, and then push it to Gentoo pretty easily.  When I don't
have access to an upstream repository I often just push a copy to a
fork on Github just to make my own life easier.

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alec Warner]

On Thu, May 24, 2012 at 5:32 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser <sera@gentoo.org> wrote:
>> Can we keep the master on Gentoo hardware please.
>>
>> Also, there still should be a bug at b.g.o and git format-patch works
>> just fine for that. Maybe it's only github now but how many places is a
>> developer supposed to monitor?
>
> I'm actually a little torn on this one.  I'm fine with keeping the
> "master" on Gentoo in the sense that this is where the rsync tree gets
> generated.  However, gitbub has a lot of tools like pull requests that
> could potentially improve workflow, especially for things like proxy
> maintainers.  So, letting those teams work more outside of Gentoo and
> just push their changes into Gentoo might make sense.

So I'm a bit confused. Is GitHub open source?

>
> Perhaps github should be viewed as a widely-shared overlay that gets
> automatic updates from the main tree in the master branch (or whatever
> we call it).  You can work on a branch in github, get it where you
> want it to be, and then push it to Gentoo pretty easily.  When I don't
> have access to an upstream repository I often just push a copy to a
> fork on Github just to make my own life easier.
>
> Rich
>

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 13:21, Alec Warner <antarus@gentoo.org> wrote:
>
> So I'm a bit confused. Is GitHub open source?
>
Your confusion begets more confusion:

Whether or not Github is open-source seems orthogonal to whether or
not we use it, as github is a website, a service, and there are a few
such websites, of which, github appears to be the defacto most-popular
one.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ulrich Mueller]

>>>>> On Fri, 25 May 2012, Kent Fredric wrote:

> On 25 May 2012 13:21, Alec Warner <antarus@gentoo.org> wrote:
>> 
>> So I'm a bit confused. Is GitHub open source?

> Your confusion begets more confusion:

> Whether or not Github is open-source seems orthogonal to whether or
> not we use it, as github is a website, a service, and there are a
> few such websites, of which, github appears to be the defacto
> most-popular one.

Actually, Alec's question is not so far-fetched. The Gentoo Social
Contract says that Gentoo will never depend upon a piece of software
unless it is open source.

Ulrich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 18:12, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> Actually, Alec's question is not so far-fetched. The Gentoo Social
> Contract says that Gentoo will never depend upon a piece of software
> unless it is open source.
>

Though in the case of github, gentoo is not "depending upon it".
Github could die in a ball of fire, and it wouldn't change the core
development, it would only change the development for the people who
elected to use github.

Anyone can use any git platform that competes with github, be it
bitbucket, gitorious, or a private git server they created.

Github is just a convenient go-to service for many.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alec Warner]

On Fri, May 25, 2012 at 8:47 AM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 25 May 2012 18:12, Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>> Actually, Alec's question is not so far-fetched. The Gentoo Social
>> Contract says that Gentoo will never depend upon a piece of software
>> unless it is open source.
>>
>
> Though in the case of github, gentoo is not "depending upon it".
> Github could die in a ball of fire, and it wouldn't change the core
> development, it would only change the development for the people who
> elected to use github.

This thread has had many suggestions about how things might be laid
out. For instance I think it would be against our social contract to
host the master git tree on github as someone suggested earlier in the
thread. My intent was mostly to keep the contract in mind when coming
up with such solutions.

>
> Anyone can use any git platform that competes with github, be it
> bitbucket, gitorious, or a private git server they created.
>
> Github is just a convenient go-to service for many.
>
> --
> Kent
>
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
>
> http://kent-fredric.fox.geek.nz
>

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Thu, 24 May 2012 17:02:24 +0200
Ralph Sennhauser <sera@gentoo.org> wrote:

> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > d) Talk with github folks to add our repo as 'mirror'.
> 
> Can we keep the master on Gentoo hardware please.

Yes, that's the intent. I'm just saying that github seems to have
a hidden feature of mirroring external repos.

https://github.com/mirrors

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 03:02, Ralph Sennhauser <sera@gentoo.org> wrote:
> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
>> d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.

Definitely.  But having a mirror on github will increase forkability,
and will make it much faster for people to get started on
contribution.

When the user has their tree up to how they want it, they can either
send a pull request to another gentoo dev who also has a fork on
github, or send a link to the commit via some medium ( bug tracker ? )
, and some dev can just add that as a remote, and merge/cherry-pick
the commits they want..

In my books, github is mostly a marketing and ease of access platform
that streamlines the ability for people to get started contributing
and facilitate easy distribution of changes back to upstream.

But this is mostly side topic.

CLEAN CUT++

If there are problems with it, we can address those when we know what
they are, not when we're inventing problems that might not actually
exist due to conjecture.

I haven't encountered any "real" problems yet in size or performance
constraints with perl-experimental  . Sure, its not portage, its only
~800 packages vs portages 15000 , but it should be a somewhat
reasonable synthetic workload.

Side note: I assume, that there is, a way, if you *really* need it, to
copy all the new git commits back to the cvs tree if something
critically broken in git turns up so bad it has to be dropped. I think
it unlikely, but knowing there is a way to "go back" would give much
reassurance.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/05/12 01:13 PM, Kent Fredric wrote:
> On 25 May 2012 03:02, Ralph Sennhauser <sera@gentoo.org> wrote:
>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
>> <mgorny@gentoo.org> wrote:
>> 
>>> d) Talk with github folks to add our repo as 'mirror'.
>> 
>> Can we keep the master on Gentoo hardware please.
> 
> Definitely.  But having a mirror on github will increase
> forkability, and will make it much faster for people to get started
> on contribution.
> 
> When the user has their tree up to how they want it, they can
> either send a pull request to another gentoo dev who also has a
> fork on github, or send a link to the commit via some medium ( bug
> tracker ? ) , and some dev can just add that as a remote, and
> merge/cherry-pick the commits they want..
> 


...is this something we (as the developer base) WANT non-dev's to be
able to do??  I would expect we'd want the tree to still be treated as
read-only-not-modifyable by the rest of the gentoo/linux community,
otherwise we're going to have a rather large mess on our hands
(multiple forks of the main tree != a uniform main tree + overlays,
the way it does now)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk++dWAACgkQ2ugaI38ACPBBpAD9EaJsSNXMS6bDbttJStVqghlO
Q46xkgPIgunriOLJhDoA/06HH/kgXd/Qrq/Ex0X3kV9nDmYqE0OmiFM1kVTfdVCD
=dcOs
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 24 May 2012 13:52:32 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> > When the user has their tree up to how they want it, they can
> > either send a pull request to another gentoo dev who also has a
> > fork on github, or send a link to the commit via some medium ( bug
> > tracker ? ) , and some dev can just add that as a remote, and
> > merge/cherry-pick the commits they want..
> 
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do??  I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

That's only a problem if you don't merge things quickly. Encouraging
users to submit git format-patches or merge requests is a great way of
reducing developer workload.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk++eQMACgkQ96zL6DUtXhF4kgCfZkdR7RTvUUlFdTgdNkyDHwGK
NlgAoKgSUKEWN6WnrihawHkhhrPbJlv2
=8RdD
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

>
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do??  I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

Yes, we want them to.

There is still going to be a "master" authoritative tree, forks of
that tree will exist for the purpose of adding new ebuilds to the
master tree / bumping existing packages.

If your worry is "There are copies of gentoo /usr/portage out there
that aren't GIT HEAD" , then stop worrying, as thats already the case.

As soon as somebody modifies a file in their local /usr/portage, that
happens, and as soon as a users portage tree gets older than 1 hour,
that happens.

And if your worry is "But they could be replicating it in that form",
then don't worry, they could already be doing that,  nothing is
stopping people from re-providing  their full (tweaked) /usr/portage
via rsync to others.  In fact, if you're running in a network with a
network master, you're doing that to an extent.

But those sources are not official, and have no utility outside
development/private use scenarios, and thus, don't compete with
overlays directly.

Sure, you *could* make something like an overlay by forking gentoo
master and then maintaining that, but it would be impractical, and
you'd be better off using a plain overlay ( less noise ), or using
that fork for the purpose of getting things in master.

You /could/ do a long-lived public maintained fork, and then you'd be
Sabyon / Funtoo.

Doing this has its own difficulties, but I think long term, enabling
this is good:

Sabyon/Funtoo can fork gentoo on github, and then any improvements
made on their forks, gentoo can easily steal back, and its easier to
track the differences between them.  Win/Win in my books.

Summarised:

Yes, its a good idea.
No, we shouldn't try stopping them.
Actually, really can't stop them, its already happening, Git will just
make the workflow better on top of it.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/24/2012 06:52 PM, Ian Stakenvicius wrote:
> On 24/05/12 01:13 PM, Kent Fredric wrote:
>> On 25 May 2012 03:02, Ralph Sennhauser <sera@gentoo.org> wrote:
>>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny 
>>> <mgorny@gentoo.org> wrote:
>>> 
>>>> d) Talk with github folks to add our repo as 'mirror'.
>>> 
>>> Can we keep the master on Gentoo hardware please.
> 
>> Definitely.  But having a mirror on github will increase 
>> forkability, and will make it much faster for people to get
>> started on contribution.
> 
>> When the user has their tree up to how they want it, they can 
>> either send a pull request to another gentoo dev who also has a 
>> fork on github, or send a link to the commit via some medium (
>> bug tracker ? ) , and some dev can just add that as a remote,
>> and merge/cherry-pick the commits they want..
> 
> 
> 
> ...is this something we (as the developer base) WANT non-dev's to
> be able to do??  I would expect we'd want the tree to still be
> treated as read-only-not-modifyable by the rest of the gentoo/linux
> community, otherwise we're going to have a rather large mess on our
> hands (multiple forks of the main tree != a uniform main tree +
> overlays, the way it does now)
> 
> 
Why do you care? If someone uses a forked tree then he and his users
are on their own. However, I would like to have the ability to accept
pull requests from users and then push my local tree back to the
"official" one.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPvn8KAAoJEPqDWhW0r/LCjVMP/jdZ+f96hx3zF25XIfn5xKdg
jsPO1kQ7KLMLFg+ZxhDMYo/ORbbOuuqtyBA9pnoDYgSB9xSQ5ETIemsyoL6MHMmj
7DGyUkd0HUFIROjaEDCD0BipPyY5Cpj/D2Ep9br0o4mfXTi2qVg5sE8qVsjguVf5
3tZ1GEm8w4k8UIj39pICX5o9X35nTlG6gkQh2cy6ZO3+MHBmyt3WOzmRczrW4bgX
kcMprYYdqoHd/VcC4LJoKMO8ALlX7UdsU2Yoe68ImKvdSdhxdqla9qPqUmf2kqqE
DYZoYnu1+NI5CtN2d30Ut0ewUqP/9/kKb0Gx/QKZkD9DR+jAv75O0M/PM3MpVP/P
wxUVRzmv48WNXJmahqiv1fiBbWR4Al5KXIfk8g49oPxNjDFb00ij0G0YSxfbvbih
kEZl24hiqumO+oLdJOGhQTbeFDDDtnJuT8Ft9914FW77dWt9M/B61udlaS5B4E41
rgP5kHVb3wmbPcS8uc8YklceJfog3FVUzghTzH9swz9umSSmO1B6JGOVKFBuyTCY
MNGn9Oz+n/Vklbg63br4AIsyokpTbGx3coeTJzQ3Jry97l5L3+TlJFqk9I644cIs
cqsh575aAlHyakvZfWdIgbBschcsRWTRuzaZAeTW4qnMMVhMn19nTkgoSCyu2PEp
Qq32ezdYxEpv4a3X40M6
=m1ok
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:
> On 24/05/12 01:13 PM, Kent Fredric wrote:
> > On 25 May 2012 03:02, Ralph Sennhauser <sera@gentoo.org> wrote:
> >> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
> >> 
> >> <mgorny@gentoo.org> wrote:
> >>> d) Talk with github folks to add our repo as 'mirror'.
> >> 
> >> Can we keep the master on Gentoo hardware please.
> > 
> > Definitely.  But having a mirror on github will increase
> > forkability, and will make it much faster for people to get started
> > on contribution.
> > 
> > When the user has their tree up to how they want it, they can
> > either send a pull request to another gentoo dev who also has a
> > fork on github, or send a link to the commit via some medium ( bug
> > tracker ? ) , and some dev can just add that as a remote, and
> > merge/cherry-pick the commits they want..
> 
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do??  I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,

Of course it's read only - just like all other public repositories. You don't 
want to accept improvments? I don't understand this.

> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

Forking happens when it's hard to contribute. You even want to make overlays 
difficult? The only real mechanism Gentoo provides for user extensibility?
-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

> On 24/05/12 02:37 PM, Dan Douglas wrote:
> > On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:

> > 
> > Of course it's read only - just like all other public
> > repositories. You don't want to accept improvments? I don't
> > understand this.
> 
> I have no problem with accepting improvements, i'm just leary of
> semi-official copies of the tree that could be checked out and checked
> into by non-dev's (this said, I don't know that much about git but I
> assume that github users could commit to the github copy yes?  that
> being the way users would contribute?)

> >> otherwise we're going to have a rather large mess on our hands
> >> (multiple forks of the main tree != a uniform main tree +
> >> overlays, the way it does now)
> > 
> > Forking happens when it's hard to contribute. You even want to
> > make overlays difficult? The only real mechanism Gentoo provides
> > for user extensibility?
> 
> Nono, I was comparing the (from my perspective) mess of multiple forks
> of the main tree that hosting on github/other services could
> potentially enable, with a single uniform source of the main tree plus
> overlays for extended contribution (which is the system we have now).

Git is about decentralized version control. When you clone a repo, you have 
your own "fork". When everyone has their own branch, everyone is effectively 
equal.  So yes you can expect much much more forking. In Git land, forks are 
good. There's no way to enforce that people only pull from some "official" 
source.

It works out in practice so that 99% of the time people only care about a 
couple branches of one repository. Counterintuitively, this comes as a side-
effect of git actually doing distribution properly and making it easier for 
everybody's workflow. The overlay model by contrast is quite broken on its own 
and virtually forces creation of new overlays in order to make changes without 
the benifits of version control (with regards to the rsync tree at least). 

What Github does is facilitate making it easy to fork/branch and provide a 
central way to push changes back into a remote through pull requests. Pull 
requests and other web services around git hosting are pretty much the thing 
that makes github worth using. From the standpoint of accepting patches, the 
differenc e to you is rather than (or in addition to) accepting patches through 
bugzilla, you can choose to accept a push directly from someone else's copy of 
the repo. It isn't like a wiki - everybody commits to their own repositories 
and pushing to a remote is on a whitelist basis just like in centralized 
version control.

Anyway, others are better at "selling" Git than I and there are no shortage of 
resources out there describing distributed development models. I think this 
thread is supposed to be about the technical hurdles and it looks like whether 
or not it's feasible to support github. I can't really comment on the 
latter. Aside from whatever hoops the Gentoo devs have to jump through in 
trying to maintain multiple repos, it's hard to see the downsides to using 
github in and of itself.

Talk to the Gentoo Haskell guys, they've been using Github for some time. And 
if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o

-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2012 03:57 PM, Dan Douglas wrote:
> Git is about decentralized version control. When you clone a repo,
> you have your own "fork". When everyone has their own branch,
> everyone is effectively equal.  So yes you can expect much much
> more forking. In Git land, forks are good. There's no way to
> enforce that people only pull from some "official" source.
> 
> It works out in practice so that 99% of the time people only care
> about a couple branches of one repository. Counterintuitively, this
> comes as a side- effect of git actually doing distribution properly
> and making it easier for everybody's workflow. The overlay model by
> contrast is quite broken on its own and virtually forces creation
> of new overlays in order to make changes without the benifits of
> version control (with regards to the rsync tree at least).
> 
> What Github does is facilitate making it easy to fork/branch and
> provide a central way to push changes back into a remote through
> pull requests. Pull requests and other web services around git
> hosting are pretty much the thing that makes github worth using.
> From the standpoint of accepting patches, the differenc e to you is
> rather than (or in addition to) accepting patches through bugzilla,
> you can choose to accept a push directly from someone else's copy
> of the repo. It isn't like a wiki - everybody commits to their own
> repositories and pushing to a remote is on a whitelist basis just
> like in centralized version control.

This gets us into another topic altogether.

I do believe git pull-requests should go through Bugzilla. A
pull-request is the equivalent to bump requests, patch fixes, and all
sorts of stuff that we already handle through Bugzilla. Bugzilla also
contains our history.

If they happen to be needing to be pulled from github, that's fine.
Definitely convenient for the contributor.

We'll also need to clearly document how the pull-request is to be
generated. (I vote for requiring signed pull-requests. [1])

github should not be our central point of contact. We have b.g.o for
that. github should be on the fringes as a tool that we can use if we
want to.

[1]
http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
=MVyV
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Alexey Shvetsov]

In gentoo git tree all git commits will be signed by commiter gpg keys 
(and this will be requerd!)

Aaron W. Swenson писал 2012-05-25 00:00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/24/2012 03:57 PM, Dan Douglas wrote:
>> Git is about decentralized version control. When you clone a repo,
>> you have your own "fork". When everyone has their own branch,
>> everyone is effectively equal.  So yes you can expect much much
>> more forking. In Git land, forks are good. There's no way to
>> enforce that people only pull from some "official" source.
>>
>> It works out in practice so that 99% of the time people only care
>> about a couple branches of one repository. Counterintuitively, this
>> comes as a side- effect of git actually doing distribution properly
>> and making it easier for everybody's workflow. The overlay model by
>> contrast is quite broken on its own and virtually forces creation
>> of new overlays in order to make changes without the benifits of
>> version control (with regards to the rsync tree at least).
>>
>> What Github does is facilitate making it easy to fork/branch and
>> provide a central way to push changes back into a remote through
>> pull requests. Pull requests and other web services around git
>> hosting are pretty much the thing that makes github worth using.
>> From the standpoint of accepting patches, the differenc e to you is
>> rather than (or in addition to) accepting patches through bugzilla,
>> you can choose to accept a push directly from someone else's copy
>> of the repo. It isn't like a wiki - everybody commits to their own
>> repositories and pushing to a remote is on a whitelist basis just
>> like in centralized version control.
>
> This gets us into another topic altogether.
>
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.
>
> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
>
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
>
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.
>
> [1]
> 
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html
>
> - - Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
> IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
> =MVyV
> -----END PGP SIGNATURE-----

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Kent Fredric]

On 25 May 2012 09:14, Alexey Shvetsov <alexxy@gentoo.org> wrote:
> In gentoo git tree all git commits will be signed by commiter gpg keys (and
> this will be requerd!)
>
> Aaron W. Swenson писал 2012-05-25 00:00:

Something that still confuses me about commit signing that I haven't
seen answered: How does a signed commit work with rebasing? I don't
see any flag to allow rebase to sign commits rebased, and rebasing
*does* change the commit fundementally in ways I'd expect to void any
signature.

Sure, you may not want rebasing in the master, but I sure as hell want
to use it in a branch. People who maintain a long-parallel-merge
history instead of rebasing their branches are on my personal shitlist
=p.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Alexey Shvetsov]

Kent Fredric писал 2012-05-25 01:20:
> On 25 May 2012 09:14, Alexey Shvetsov <alexxy@gentoo.org> wrote:
>> In gentoo git tree all git commits will be signed by commiter gpg 
>> keys (and
>> this will be requerd!)
>>
>> Aaron W. Swenson писал 2012-05-25 00:00:
>
> Something that still confuses me about commit signing that I haven't
> seen answered: How does a signed commit work with rebasing? I don't
> see any flag to allow rebase to sign commits rebased, and rebasing
> *does* change the commit fundementally in ways I'd expect to void any
> signature.
>
> Sure, you may not want rebasing in the master, but I sure as hell 
> want
> to use it in a branch. People who maintain a long-parallel-merge
> history instead of rebasing their branches are on my personal 
> shitlist
> =p.

You can rebase signed commit untill you dont push it to master
But yes i'm not sure how it works with signed commits
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Kent Fredric]

On 25 May 2012 09:00, Aaron W. Swenson <titanofold@gentoo.org> wrote:

> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.

+1

>
> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
>
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
>
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.
>

+/-1 : Not sure, for new people, it should definitely be the go-to way
to do things.

But people who are regular contributors ( which we want to encourage )
will feel slowed down if they have to open a bug report for every
change.

And I can see github facilitating "proxy maintainers" much better.

If a proxy maintainer has another gentoo person who all their changes
get proxied through, the proxy maintainer and the gentoo dev could
both have forks on github, and the proxy maintainer could send their
pull requests to their proxy to vet and merge, somewhat like Linus'es
Generals model.

> [1]
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html
>
> - - Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
> IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
> =MVyV
> -----END PGP SIGNATURE-----
>



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On Thursday, May 24, 2012 05:00:49 PM Aaron W. Swenson wrote:
> This gets us into another topic altogether.
> 
> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.

This discussion was sort of in the context of proxy-maintainers. A pull 
request isn't equivalent to a bump request or entirely overlapping with most 
bugs that go through bugzilla. A pull request is  just "here take my code", or 
is useful for code revewing just because it integrates with the git workflow. I 
suppose you would  have to define the sorts of things that should go through 
Bugzilla. I can't imagine it being reasonable to use github for most types of 
bump requests.

> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
> 
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
> 
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.

This reminds me of Linus' old Google talk on Git in which He said something 
along the lines of: "Many companies using Git internally don't know they're 
using git - they're using it whether they like it or not". There are ALREADY 
Gentoo projects using github and even pull requests. It doesn't really matter 
because everything more or less comes back to one point in the end. It's the 
repo that's the history of the project, not bugzilla. I've "filed" more bugs 
over IRC and had them fixed in the tree within 60 seconds than I have gone 
through bugzilla formalisms. FWIW, I think having the entire tree in one big 
repo is a bad idea to begin with.

But ok it's a good point. Github isn't a good central point of contact. People 
have to use their discression. It's just uncommon these days for a project as 
big as Gentoo to have ultra-centralized corporate-style procedures where 
everything happens exclusively though official channels. And anyway you couldn't 
"enforce" that sort of thing if you tried.

> [1]
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.h
> tml

-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Rich Freeman]

On Thu, May 24, 2012 at 6:01 PM, Dan Douglas <ormaaj@gmail.com> wrote:
> But ok it's a good point. Github isn't a good central point of contact. People
> have to use their discression. It's just uncommon these days for a project as
> big as Gentoo to have ultra-centralized corporate-style procedures where
> everything happens exclusively though official channels. And anyway you couldn't
> "enforce" that sort of thing if you tried.
>

++

There is no policy that every commit in cvs needs to be referenced to
a bug, and I doubt we're going to change that.  So, if I call up
another dev on the phone and tell them they have a typo in an ebuild,
and they fix it and commit it, nothing has gone wrong.  That isn't the
most efficient way to work usually, but there is no policy against it.
 In general users should file bugs and not contact devs directly, but
if somebody has a private arrangement otherwise, no harm no foul.

Github is just another overlay.  If in the course of working on the
next kde release the kde team makes 385 changes to their overlay, we
don't make them log and close 385 bugs on b.g.o before they merge in
the files from the overlay.

So, if a team wants to use non-official tools, by all means go ahead.
The QA standards apply to anything hitting the main tree, and must be
followed at that point in time.  We should keep our tools working
well, but if in some case there is a better way of working, or a small
team has some other preference, well, have at it!

Rich

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Maxim Kammerer]

On Fri, May 25, 2012 at 1:01 AM, Dan Douglas <ormaaj@gmail.com> wrote:
> This reminds me of Linus' old Google talk on Git in which He said something

I have to ask: was the pronoun capitalization intentional?

> along the lines of: "Many companies using Git internally don't know they're
> using git - they're using it whether they like it or not".

IIRC, it was about git-svn specifically, although I think you are
right: developers will use git and GitHub because they fulfill a need,
regardless of policies.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Wed, 23 May 2012 16:14:53 -0500
Dan Douglas <ormaaj@gmail.com> wrote:

> If not I will be leaving Gentoo for Funtoo in the near future, though
> there are disadvantages to doing this I don't look forward to dealing
> with.

Most of us will probably be doing that :P.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
> On Wed, 23 May 2012 16:14:53 -0500
> 
> Dan Douglas <ormaaj@gmail.com> wrote:
> > If not I will be leaving Gentoo for Funtoo in the near future, though
> > there are disadvantages to doing this I don't look forward to dealing
> > with.
> 
> Most of us will probably be doing that :P.

Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo boxen to 
deal with. I just need to be able to use git on the tree (even without the 
full history is perfectly fine) to ease the difficulty of local overlay 
management. Glad to hear that will be possible, or at least somewhat easier.
-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Duncan]

Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:

> On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
>> On Wed, 23 May 2012 16:14:53 -0500
>> 
>> Dan Douglas <ormaaj@gmail.com> wrote:
>> > If not I will be leaving Gentoo for Funtoo in the near future, though
>> > there are disadvantages to doing this I don't look forward to dealing
>> > with.
>> 
>> Most of us will probably be doing that :P.
> 
> Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo
> boxen to deal with. I just need to be able to use git on the tree (even
> without the full history is perfectly fine) to ease the difficulty of
> local overlay management. Glad to hear that will be possible, or at
> least somewhat easier.

FWIW, I as a user would sure like a git-based tree.  Doing git whatchanged 
searches on individual files and being able to track my last checkout and 
roll back to it, or to a point between it and current HEAD, are extremely 
useful.  I haven't thought of it much until now, but I think maintaining 
overlays as simple branches would be great, as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

On Thursday, May 24, 2012 06:33:53 AM Duncan wrote:
> Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:
> > On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
> >> On Wed, 23 May 2012 16:14:53 -0500
> >> 
> >> Dan Douglas <ormaaj@gmail.com> wrote:
> >> > If not I will be leaving Gentoo for Funtoo in the near future, though
> >> > there are disadvantages to doing this I don't look forward to dealing
> >> > with.
> >> 
> >> Most of us will probably be doing that :P.
> > 
> > Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo
> > boxen to deal with. I just need to be able to use git on the tree (even
> > without the full history is perfectly fine) to ease the difficulty of
> > local overlay management. Glad to hear that will be possible, or at
> > least somewhat easier.
> 
> FWIW, I as a user would sure like a git-based tree.  Doing git whatchanged
> searches on individual files and being able to track my last checkout and
> roll back to it, or to a point between it and current HEAD, are extremely
> useful.  I haven't thought of it much until now, but I think maintaining
> overlays as simple branches would be great, as well.

I don't think doing a branch of the entire tree is a good idea (well 
maybe...). I was thinking more along the lines of subtree merges into a local 
overlay, or perhaps submodules. To do that currently (I think) would require 
taking the rsync tree and putting that into a repo, and trying to keep it 
synchronized. Plus in the process you lose all correspondance with upstream 
commits so that logs and diffs become meaningless.
-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Vítor Brandão]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

2012/5/24 Dan Douglas <ormaaj@gmail.com>

> On Thursday, May 24, 2012 06:33:53 AM Duncan wrote:
> > Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:
> > > On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
> > >> On Wed, 23 May 2012 16:14:53 -0500
> > >>
> > >> Dan Douglas <ormaaj@gmail.com> wrote:
> > >> > If not I will be leaving Gentoo for Funtoo in the near future,
> though
> > >> > there are disadvantages to doing this I don't look forward to
> dealing
> > >> > with.
> > >>
> > >> Most of us will probably be doing that :P.
> > >
> > > Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo
> > > boxen to deal with. I just need to be able to use git on the tree (even
> > > without the full history is perfectly fine) to ease the difficulty of
> > > local overlay management. Glad to hear that will be possible, or at
> > > least somewhat easier.
> >
> > FWIW, I as a user would sure like a git-based tree.  Doing git
> whatchanged
> > searches on individual files and being able to track my last checkout and
> > roll back to it, or to a point between it and current HEAD, are extremely
> > useful.  I haven't thought of it much until now, but I think maintaining
> > overlays as simple branches would be great, as well.
>
> I don't think doing a branch of the entire tree is a good idea (well
> maybe...). I was thinking more along the lines of subtree merges into a
> local
> overlay, or perhaps submodules. To do that currently (I think) would
> require
> taking the rsync tree and putting that into a repo, and trying to keep it
> synchronized. Plus in the process you lose all correspondance with upstream
> commits so that logs and diffs become meaningless.
> --
> Dan Douglas


git++

-- 
Vítor Brandão  (noisebleed)

[-- Attachment #2: Type: text/html, Size: 2436 bytes --]

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Duncan]

Dan Douglas posted on Thu, 24 May 2012 01:51:28 -0500 as excerpted:

> I don't think doing a branch of the entire tree is a good idea (well
> maybe...). I was thinking more along the lines of subtree merges into a
> local overlay, or perhaps submodules. To do that currently (I think)
> would require taking the rsync tree and putting that into a repo, and
> trying to keep it synchronized. Plus in the process you lose all
> correspondance with upstream commits so that logs and diffs become
> meaningless.

The thing about git branches is that they cost almost nothing.  If the 
whole main tree is a single git tree, and you already have that 
available, maintaining a branch consisting of what we now call an overlay 
is trivial, compared to simply maintaining the separate files, as is 
normally done now.

In that regard, git is nothing like for instance svn, where branches come 
at a much higher cost, as does merging between them.  (CVS... I don't 
actually know enough about to make an informed comparison.

It'd be a real shame not to expose the read-only git tree to the users 
who want it.  Git was /designed/ to be distributed in that manner.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> In that regard, git is nothing like for instance svn, where branches come
> at a much higher cost, as does merging between them.

That's wrong. SVN branches are just about as cheap as git branches,
although merges used to be much more painful. I'm not sure how good
merging in recent SVN is.

Let's please stay a little on-topic? The migration will get there much
faster if we don't succumb to feature creep.

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Thu, 24 May 2012 14:05:50 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > In that regard, git is nothing like for instance svn, where
> > branches come at a much higher cost, as does merging between them.
> 
> That's wrong. SVN branches are just about as cheap as git branches,

[citation needed]

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 00:05, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> In that regard, git is nothing like for instance svn, where branches come
>> at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches are just about as cheap as git branches,
> although merges used to be much more painful. I'm not sure how good
> merging in recent SVN is.

Cheapness ... maybe in binary disk utilization ( need an actual
comparison here I think ), but in cognitive overheads, I'd argue git's
branching system is definitely cheaper.  Going from Git back to SVN,
the mentality of "copy a directory and you have a new branch!!!" seems
a bit crazy.

And switching between branches in-place at a fixed disk location is
definitely cheaper ( mentally at least ) than SVN.

I hope I never have to use svn switch again :/
-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/24/2012 03:37 PM, Kent Fredric wrote:

Kent, this is of topic, stop it.

- -- 
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk++PO8ACgkQknrdDGLu8JC2cAD/WknV6DJEzYEsuXJD0TuDU99I
arDTkrBHNXydYVdaxGoBAJmmVm3o7YWlMAvFBz2Eu4ma/VXEHdqocFwl0NK+FEAh
=Esu3
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Mark Wright]

Michael Weber <xmw@gentoo.org> writes:
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).

+1 for clean cut to git

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ultrabug]

On 24/05/2012 03:19, Mark Wright wrote:
> Michael Weber <xmw@gentoo.org> writes:
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive load).
> 
> +1 for clean cut to git
> 

clean cut +1

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Ok.

Since most of us want "clean cut" solution so i will close bug #333699 
as WONTFIX
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Sat, May 26, 2012 at 12:18 PM, Alexey Shvetsov <alexxy@gentoo.org> wrote:
> Since most of us want "clean cut" solution so i will close bug #333699 as
> WONTFIX

Along these lines, I'm looking at 333531 (the git migration tracker),
and it seems like there isn't actually much to do:

333685 - Seems like no action, and not sure how critical
333687 - while the bug is still open, as far as I can tell it seems
good enough to me to move forward
333697 - ditto
333701 - paused since there are other tasks to do first, though it
seems to me that little remains

333705 - not sure how critical this actually is - do we care if in
some obscure case history is lost?  Nothing says that we have to
completely destroy the old cvs repo.  Maybe we should just do a mock
migration now and post copies of the before/after somewhere public and
let people have at them.

333709 - seems like there is legitimate work to be done here, but
again nothing that big

So, what is the big issue?  Is there something not being tracked, or
is one of those items a lot harder than it looks?

Rich

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Duncan]

Rich Freeman posted on Tue, 29 May 2012 21:55:04 -0400 as excerpted:

> So, what is the big issue?  Is there something not being tracked, or is
> one of those items a lot harder than it looks?

I'd suggest that it's like openrc stabilization.  The biggest problem 
with it is that it's a BIG job, and the simplest solution is to simply 
have someone commit to it, with full council *priority* backing, and push 
and push until it's done.

There *is* one huge don't-do-it-that-way lesson to take from the openrc 
stabilization, tho:  Get the documentation in place BEFORE "throwing the 
switch".  I'm still not sure what happened with openrc.  The 
documentation bug was a blocker... until it was the last one and then 
suddenly it went live without proper upgrade documentation, or that's the 
way it seemed from here, anyway.  The fact that we had essentially no doc-
project to work on the documentation was unfortunately a problem, the one 
guy still trying to hang on in docs so backlogged and burnt out that it 
was about hopeless, action time stretching toward infinity, but swift 
coming back on board dramatically improved that situation so at least it 
shouldn't be an infinity blocker, now.

But really what that means is that whoever ends up taking charge of that 
final push, needs to be prepared to learn gentoo's docs CSS definitions 
and do it themself, if it comes to that.

Meanwhile, the positive takeaway from the openrc stabilization is that 
someone suitably determined, along with council backing and everyone else 
rowing the same way where their little part of gentoo comes into contact 
with the job at hand, goes a long way!

Of course, there's a much larger infra component to the git migration, so 
either having that someone being an infra person, or at least having 
someone from infra have the time and be willing to work closely with 
them, is going to be critical.  But again, given a council "*priority*, 
let's move on it!" decision, I'd at least /hope/ that's not a blocker.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Wed, May 30, 2012 at 11:38 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Of course, there's a much larger infra component to the git migration, so
> either having that someone being an infra person, or at least having
> someone from infra have the time and be willing to work closely with
> them, is going to be critical.  But again, given a council "*priority*,
> let's move on it!" decision, I'd at least /hope/ that's not a blocker.

Yeah... this is why I was asking about access to infra to test the
conversion; so far, I haven't had any replies, though.

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> Yeah... this is why I was asking about access to infra to test the
> conversion; so far, I haven't had any replies, though.
>

A mock conversion would probably help with creating
procedures/docs/etc as well.  It is nice to say that we're "just going
to use git" but I think everybody has a slightly different picture of
how that is going to work.

If we could set up an "official unofficial" portage tree in git based
on a one-time migration (maybe refreshing it from time to time) that
could be a sandbox used to work things out, and it would then be
replaced with the official tree.  When the official migration comes
along we'd already be experts in doing it.

All we need to do is execute the migration, and just not point the
rsync generation process at it.  Maybe it won't be perfectly right at
first, and that would basically be the point of doing it.  Devs could
update tools to work against it, and the docs could be written
alongside.

Rich

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Duncan]

Rich Freeman posted on Wed, 30 May 2012 07:32:49 -0400 as excerpted:

> On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> Yeah... this is why I was asking about access to infra to test the
>> conversion; so far, I haven't had any replies, though.
>>
>>
> A mock conversion would probably help with creating procedures/docs/etc
> as well.  It is nice to say that we're "just going to use git" but I
> think everybody has a slightly different picture of how that is going to
> work.

I /believe/ such mock conversions had been done, based on previous 
threads here, tho NOT on the SCM-migration list, which would certainly 
have the greater detail.  AFAIK the previous sticking points were all 
those still-open bugs, not the general conversion.  But the bugs, other 
than documentation, either seem mostly fixed or not so important, any 
more.

Of course, those previous trial runs are probably similarly dated, now, 
so a new one's probably in order with the new perspective on those bug 
priorities, etc, but at least getting the input of someone that was 
involved with them should speed progress over some already covered 
ground, in any case.

(I've considered following scmm myself, but there's apparently some sort 
of issue between gmane, pan, and lists commonly crossposted between, that 
has already killed project for me, header-fetch does nothing, and scmm 
would almost certainly be similarly dead to me.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Wed, May 30, 2012 at 01:06:45PM +0000, Duncan wrote:
> Of course, those previous trial runs are probably similarly dated, now, 
> so a new one's probably in order with the new perspective on those bug 
> priorities, etc, but at least getting the input of someone that was 
> involved with them should speed progress over some already covered 
> ground, in any case.
No, the last mock conversion is still live and updating fairly often:
http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> No, the last mock conversion is still live and updating fairly often:
> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary

Since you seem to know most about this project, can you give a short
summary on what *you* think are hard blockers for the migration?

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/30/2012 04:31 PM, Dirkjan Ochtman wrote:
> On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson
> <robbat2@gentoo.org> wrote:
>> No, the last mock conversion is still live and updating fairly
>> often: 
>> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
>
>> 
> Since you seem to know most about this project, can you give a
> short summary on what *you* think are hard blockers for the
> migration?
> 
> Cheers,
> 
> Dirkjan
> 

The 6 hours it takes to clone the repo.

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/HXjoACgkQVxOqA9G7/aB2DwD+JqdcMJDIfu30Oht8rB6H/pMY
Wr1RjhujZvVGIDQG55QA/jPlsWh3c8El7HjxzhjoCNIPkV1Vj3b7VZVc/D6y6oq9
=FxGY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Peter Stuge]

Aaron W. Swenson wrote:
> > what *you* think are hard blockers for the migration?
> 
> The 6 hours it takes to clone the repo.

Maybe clone on server and distribute the initial repo as tarball.


//Peter

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Thu, May 31, 2012 at 2:04 PM, Aaron W. Swenson <titanofold@gentoo.org> wrote:
> The 6 hours it takes to clone the repo.

IIRC someone already proposed that the packed repo could be offered
via normal download (or even BitTorrent).

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Thu, May 31, 2012 at 08:04:10AM -0400, Aaron W. Swenson wrote:
> On 05/30/2012 04:31 PM, Dirkjan Ochtman wrote:
> > On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson
> > <robbat2@gentoo.org> wrote:
> >> No, the last mock conversion is still live and updating fairly
> >> often: 
> >> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
> The 6 hours it takes to clone the repo.
To directly clone that repo yes.

Which you should NEVER be doing in reality.

The final conversion repo we have already stated will only be 40MB, with
no history. History will be available separately to graft on if you need
it, just like the Linux kernel did with historical data.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/31/2012 02:04 PM, Aaron W. Swenson wrote:
> The 6 hours it takes to clone the repo.
afaik it's 6 hours to transform the whole cvs history into a git repo.

Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
22 minutes of 3.4GHz cpus).

[1] git clone git://git-exp.overlays.gentoo.org/exp/gentoo-x86.git
[2] http://lore.xmw.de/gentoo/gentoo-exp/notes

Michael
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/JKucACgkQknrdDGLu8JAIxAEAhLZ4Tk6rXy1qAUbDDHS4UYiL
gGUPj5PKUKSS1YJp6hkA/R9aEqjSNr/8iZ2novNFGjvbJ5CtDkvI+PsvMTUNDoDo
=3t+7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 4:49 PM, Michael Weber <xmw@gentoo.org> wrote:
>
> Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
> 22 minutes of 3.4GHz cpus).
>

As others have pointed out, probably the best way to bootstrap this is
to offer tarballs of a shallow repository and a full repository.
Perhaps we'd offer the latter as a torrent.  The shallow repository
should be light on the CPU too.

This would be a lot easier on the server than having everybody and
their uncle doing a full 2GB clone.

Devs could then do a pull to get the latest and greatest, and that
would only transfer the delta.

I imagine our mirror network can handle the bandwidth compared to what
we're already doing with distfiles.  Worst case we could take a
one-time hit and use S3 or whatever to do the distribution (they even
support bittorrent to cut down on the bill).

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Fri, Jun 01, 2012 at 08:52:42PM -0400, Rich Freeman wrote:
> On Fri, Jun 1, 2012 at 4:49 PM, Michael Weber <xmw@gentoo.org> wrote:
> > Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
> > 22 minutes of 3.4GHz cpus).
> As others have pointed out, probably the best way to bootstrap this is
> to offer tarballs of a shallow repository and a full repository.
> Perhaps we'd offer the latter as a torrent.  The shallow repository
> should be light on the CPU too.
no.

i explicitly said before, there would be two repos:
1. main working repo, starts with ONLY initial commit. 40MB pack.
2. historical. read-only, you graft it to history to use.

BOTH of these would have preferred download via git-bundle over
HTTP/rsync. historical would NOT be available via clone due to cputime
hit.

please look up git-bundle before suggesting things like tarballs of
repos/checkouts.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Sat, Jun 2, 2012 at 12:04 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> please look up git-bundle before suggesting things like tarballs of
> repos/checkouts.
>

Looks useful.  Wasn't aware that a bundle was something other than a tarball.

We'll probably need to spell out the preferred process in the docs,
and reference it frequently in communications.  Otherwise you'll get
quite a few clones instead.

It appears that devs will have to add the remote for the live
repository after they've cloned the bundle - otherwise they'll just
keep pulling from the bundle which isn't all that convenient.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Sat, Jun 2, 2012 at 12:59 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Looks useful.  Wasn't aware that a bundle was something other than a tarball.
>
> We'll probably need to spell out the preferred process in the docs,
> and reference it frequently in communications.  Otherwise you'll get
> quite a few clones instead.
>
> It appears that devs will have to add the remote for the live
> repository after they've cloned the bundle - otherwise they'll just
> keep pulling from the bundle which isn't all that convenient.

I think you still misunderstand. As I understand Robin, we wouldn't
even offer up a clone of the full-history bundle, it would only be
offered as a normal download. The default workflow is cloning from the
shallow version, which will obviously give you the desired remote.

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Sat, Jun 2, 2012 at 8:03 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Sat, Jun 2, 2012 at 12:59 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> It appears that devs will have to add the remote for the live
>> repository after they've cloned the bundle - otherwise they'll just
>> keep pulling from the bundle which isn't all that convenient.
>
> I think you still misunderstand. As I understand Robin, we wouldn't
> even offer up a clone of the full-history bundle, it would only be
> offered as a normal download. The default workflow is cloning from the
> shallow version, which will obviously give you the desired remote.

I wasn't talking about full-history.

I was talking about the fact that we're distributing a bundle.  If you
clone a bundle, you won't have a remote for the live repository.  You
would need to add it, unless you plan to never push a commit back to
the gentoo repository, and you plan to manually download bundles
anytime you want to update your local repository.

I'm not sure how exactly Robin was planning on making the full history
available, but it sounded like it would also be distributed as a
bundle.  That means that you can certainly clone it - just type git
clone path-to-locally-saved-bundle-file .  If it is in some other
format like a pack file then you would import it into a repository via
a different command.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Wed, May 30, 2012 at 10:31:06PM +0200, Dirkjan Ochtman wrote:
> On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> > No, the last mock conversion is still live and updating fairly often:
> > http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
> Since you seem to know most about this project, can you give a short
> summary on what *you* think are hard blockers for the migration?
There are only two items from my perspective.
1. 
Discussion on merge policy. Originally I thought we would disallow merge
commits, so that we would get a cleaner history. However, it turns out that if
the repo ends up being pushed to different places with slightly different
histories, merges are absolutely going to be required to prevent somebody from
having to rebase at least one of their sets of commits that are already pushed.

2. 
Git-SVN breakage. Why does this matter you're wondering?
We need the newer Git for the commit signing, but it comes with a
price, the git-svn binary has some major failures with SVN 1.7.
Git since 1.7.8 has been broken this way.

You can see them best with the testsuite. I haven't keyworded those ebuilds for
git at all, because git-svn in some of my tests ended up being destructive of
the repository - it actually lost data.

The error sometimes turns up like this.

Initialized empty Git repository in /dev/shm/portage/dev-vcs/git-9999/work/git-9999/t/t d.t9155/git_project/.git/
svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 2291: assertion failed (svn_uri_is_canonical(url, pool))

This is seemingly due to a change in SVN 1.7 that is stricter about all paths
(both URIs and to files/directories) being properly escaped.

Upstream Git has made no progress on it in more than 6 months.
Both ferringb and I put several weeks of work into it without succeeding.

If you want to reproduce it:
- Upgrade your SVN to 1.7
- Build & run the git testsuite
- Most of the t91xx tests will fail, because the working dir is 'trash directory'.
- If you patch the working dir to be 'trash_directory', you'll be left with
  failures in at least: t9100 t9118 t9120
  Because those are the tests that have whitespace or other characters that
  need escaping.

The last version of my patch is files/git-1.7.8-git-svn-1.7-canonical-path.patch
but it caused more problems than it fixed.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> 1.
> Discussion on merge policy. Originally I thought we would disallow merge
> commits, so that we would get a cleaner history. However, it turns out that if
> the repo ends up being pushed to different places with slightly different
> histories, merges are absolutely going to be required to prevent somebody from
> having to rebase at least one of their sets of commits that are already pushed.

Not sure I'm following, but I will be the first to admit that I'm a
git novice.  Would this be aided by a convention, like only committing
to master on the gentoo official repository, and any on-the-side work
on places like github/etc stays in branches?  Those repositories would
just keep getting fed commits on master from the official repository.

>
> 2.
> Git-SVN breakage. Why does this matter you're wondering?
> We need the newer Git for the commit signing, but it comes with a
> price, the git-svn binary has some major failures with SVN 1.7.
> Git since 1.7.8 has been broken this way.

To clarify - these won't be issues for gentoo per se, but there is a
sense that we can't stabilize the latest git because it will break it
for people using git-svn on non-gentoo work?

I think the general conclusion was that we would not be supporting any
mixed git+cvs/svn/etc workflows for gentoo itself.

If that is the case, what is our sense of how important this feature
even is to gentoo developers?  They're the only ones who really have
to have the latest git to commit to the official tree.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
> On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> > 1.
> > Discussion on merge policy. Originally I thought we would disallow merge
> > commits, so that we would get a cleaner history. However, it turns out that if
> > the repo ends up being pushed to different places with slightly different
> > histories, merges are absolutely going to be required to prevent somebody from
> > having to rebase at least one of their sets of commits that are already pushed.
> Not sure I'm following, but I will be the first to admit that I'm a
> git novice.  Would this be aided by a convention, like only committing
> to master on the gentoo official repository, and any on-the-side work
> on places like github/etc stays in branches?  Those repositories would
> just keep getting fed commits on master from the official repository.
Ok, let me try and reword my statement.

- 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.

> > 2.
> > Git-SVN breakage. Why does this matter you're wondering?
> > We need the newer Git for the commit signing, but it comes with a
> > price, the git-svn binary has some major failures with SVN 1.7.
> > Git since 1.7.8 has been broken this way.
> To clarify - these won't be issues for gentoo per se, but there is a
> sense that we can't stabilize the latest git because it will break it
> for people using git-svn on non-gentoo work?
As the Git maintainer, I will not keyword it for anybody until I know
it's not going to lose/corrupt data, regardless of what they are using
it for.

I don't think there are many SVN repos left in Gentoo that haven't
converted to using Git directly, so it's probably not a problem from
that side.

> If that is the case, what is our sense of how important this feature
> even is to gentoo developers?  They're the only ones who really have
> to have the latest git to commit to the official tree.
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).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Thu, May 31, 2012 at 3:13 PM, Robin H. Johnson <robbat2@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

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On Thu, May 31, 2012 at 07:13:42PM +0000, Robin H. Johnson wrote:
> - You have a commit, that you want to put into the Gentoo tree.
> - You have already pushed it to your github, signed

If I have a github tree, that would probably be because I didn't have
push access to the official tree, so signing the commit probably
isn'tgoing to matter; I would expect that a gentoo dev who has push
access to the tree would sign the commit when it is put into the gentoo
tree.

> - 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.

If you do this:

git rebase master mybranch
git checkout master
git merge mybranch <-- this is a fast-forward merge
git pull --rebase
git push

I think that covers this concern doesn't it?

> > > 2.
> > > Git-SVN breakage. Why does this matter you're wondering?
> > > We need the newer Git for the commit signing, but it comes with a
> > > price, the git-svn binary has some major failures with SVN 1.7.
> > > Git since 1.7.8 has been broken this way.
> > To clarify - these won't be issues for gentoo per se, but there is a
> > sense that we can't stabilize the latest git because it will break it
> > for people using git-svn on non-gentoo work?
> As the Git maintainer, I will not keyword it for anybody until I know
> it's not going to lose/corrupt data, regardless of what they are using
> it for.

Why not keyword it and use package.use.mask for the git-svn flag?

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Duncan]

William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:

> On Thu, May 31, 2012 at 07:13:42PM +0000, Robin H. Johnson wrote:
>> - You have a commit, that you want to put into the Gentoo tree.
>> - You have already pushed it to your github, signed
> 
> If I have a github tree, that would probably be because I didn't have
> push access to the official tree, so signing the commit probably
> isn'tgoing to matter; I would expect that a gentoo dev who has push
> access to the tree would sign the commit when it is put into the gentoo
> tree.

I don't know what's going to happen to all the overlays with the main 
tree switch to git, but won't that break various "overlay first" 
policies, say for the kde overlay?

Of course, if all the official overlays are converted to git branches of 
the main tree... but won't they still require rebasing as they've already 
been pushed?  (This assumes your workaround idea doesn't work.  If it 
does, great!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Thu, May 31, 2012 at 08:26:58PM +0000, Duncan wrote:
> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
> 
> I don't know what's going to happen to all the overlays with the main 
> tree switch to git, but won't that break various "overlay first" 
> policies, say for the kde overlay?
> 
> Of course, if all the official overlays are converted to git branches of 
> the main tree... but won't they still require rebasing as they've already 
> been pushed?  (This assumes your workaround idea doesn't work.  If it 
> does, great!)

Overlays aren't really part of this discussion; those are independent
trees which we have no control over, so commiting changes from overlays
to the main tree is the responsibility of the overlay maintainers.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Duncan]

William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:

> On Thu, May 31, 2012 at 08:26:58PM +0000, Duncan wrote:
>> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
>> 
>> I don't know what's going to happen to all the overlays with the main
>> tree switch to git, but won't that break various "overlay first"
>> policies, say for the kde overlay?
>> 
>> Of course, if all the official overlays are converted to git branches
>> of the main tree... but won't they still require rebasing as they've
>> already been pushed?  (This assumes your workaround idea doesn't work. 
>> If it does, great!)
> 
> Overlays aren't really part of this discussion; those are independent
> trees which we have no control over, so commiting changes from overlays
> to the main tree is the responsibility of the overlay maintainers.

But it seems to me that overlays are the primary use case for commits to 
public trees other than gentoo first.  Otherwise, the whole rebase-vs-
merge problem goes away, because the first public commit is to the gentoo 
tree.  But especially with overlays (like kde) that have an overlay-
first, test, then gentoo-tree, policy, that public overlay tree (which is 
already in git) is part of the process.  Commits MUST go thru the overlay 
to get to the tree, and that overlay is public, so constant rebasing is a 
definite no-no.

Which unless your workaround idea works, pretty much leaves us with merge-
commits as a necessity.  (Which of course, as Ciaran pointed out, are 
part of the point of git, such that running git without merge-commits 
defeats part of the purpose of the whole exercise.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Nicolas Sebrecht]

The 01/06/12, Duncan wrote:

> But it seems to me that overlays are the primary use case for commits to 
> public trees other than gentoo first.  Otherwise, the whole rebase-vs-
> merge problem goes away, because the first public commit is to the gentoo 
> tree.  But especially with overlays (like kde) that have an overlay-
> first, test, then gentoo-tree, policy, that public overlay tree (which is 
> already in git) is part of the process.  Commits MUST go thru the overlay 
> to get to the tree, and that overlay is public, so constant rebasing is a 
> definite no-no.

The purpose of overlays is to have ebuilds maintained outside of the
official Gentoo portage. Importing a ebuild from an overlay whether it
uses Git or not means importing the ebuild(s). In the Git context, it
means the Gentoo maintainer has to make an import commit the same way
it would be done to start a project with somthing like:

  cp 'files to be commited' .
  git add .
  git commit -m 'initial import'

So, like explained before your concern is clearly out of the current
discussion. Importing commit history from Overlays is not supported and
will probably never be. Gentoo doesn't forces (and doesn't want to)
overlays maintainers to use Git.

-- 
Nicolas Sebrecht

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

> The purpose of overlays is to have ebuilds maintained outside of the
> official Gentoo portage. Importing a ebuild from an overlay whether it
> uses Git or not means importing the ebuild(s). In the Git context, it
> means the Gentoo maintainer has to make an import commit the same way
> it would be done to start a project with somthing like:
> 
>   cp 'files to be commited' .
>   git add .
>   git commit -m 'initial import'
> 
> So, like explained before your concern is clearly out of the current
> discussion. Importing commit history from Overlays is not supported and
> will probably never be. 

Which does not mean that it's not desirable. 

The KDE ebuilds are mainly evolving inside the KDE overlay, where KDE betas 
and live ebuilds live. Being able (in the future) to see the history of an 
ebuild before it was imported into the main tree would certainly help in some 
cases.


-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> So, like explained before your concern is clearly out of the current
> discussion. Importing commit history from Overlays is not supported and
> will probably never be. Gentoo doesn't forces (and doesn't want to)
> overlays maintainers to use Git.

I'm not sure that git even supports this, unless the overlay is a
complete clone of the entire gentoo-x86.git repository.

I think the way git operations work is by finding common parents in
the history of two heads, and then moving forward from there.  If you
have two completely different repositories then they never will have a
common parent.

Plus, even if it did work, to rebase the overlay on the gentoo-x86
repository you'd have to import the full gentoo-x86 tree into it.
Then you'd have to push EVERYTHING in your overlay into gentoo-x86.  I
don't think you can just push individual files from one tree to
another.

From what I've seen the various methods out there which do involve
moving only part of one branch into another basically involve a LOT of
history manipulation or are really no different than just copying the
files into the branch and adding them, losing all history in the
process.

I'm not sure how important all that history preservation actually is -
the overlay would still possess it.  If we did want to preserve it
then the only practical option I see is to have the overlay start out
as a clone of gentoo-x86 and keep around all the non-overlay packages,
which then means that anybody using the overlay will get all those old
gentoo-x86 packages as part of their portage tree.  Plus you still
have the rebase+gpg-signatures=fail issue.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 03:39, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
>> So, like explained before your concern is clearly out of the current
>> discussion. Importing commit history from Overlays is not supported and
>> will probably never be. Gentoo doesn't forces (and doesn't want to)
>> overlays maintainers to use Git.
>
> I'm not sure that git even supports this, unless the overlay is a
> complete clone of the entire gentoo-x86.git repository.
>
> I think the way git operations work is by finding common parents in
> the history of two heads, and then moving forward from there.  If you
> have two completely different repositories then they never will have a
> common parent.

You can however merge dissimilar histories with no common parents if
you know what you're doing. It does warn you, but it still lets you do
it.

> Plus, even if it did work, to rebase the overlay on the gentoo-x86
> repository you'd have to import the full gentoo-x86 tree into it.
> Then you'd have to push EVERYTHING in your overlay into gentoo-x86.  I
> don't think you can just push individual files from one tree to
> another.

Yeah, selectively pulling in files with histories however is hard,
I've occasionally been fussed enough to create temporary copies of
branches, and then iterate over their history so the history is
reduced to changes only for a small selection of files, but its
largely lots of work, and I can't remember how to do it every time I
go to do it -_-

Its reasonably straight forward to cherry-pick commits in though.

> From what I've seen the various methods out there which do involve
> moving only part of one branch into another basically involve a LOT of
> history manipulation or are really no different than just copying the
> files into the branch and adding them, losing all history in the
> process.
>
> I'm not sure how important all that history preservation actually is -
> the overlay would still possess it.  If we did want to preserve it
> then the only practical option I see is to have the overlay start out
> as a clone of gentoo-x86 and keep around all the non-overlay packages,
> which then means that anybody using the overlay will get all those old
> gentoo-x86 packages as part of their portage tree.  Plus you still
> have the rebase+gpg-signatures=fail issue.
>
> Rich
>

Myself, I'd be inclined to do something like this:

1. Have an integration branch on gx86
2. Select a package or packages to migrate to gx86 from an overlay
3. create a branch in the overlay that only contains the history with
regard to those packages.
4. copy the branch to a local checkout of gx86, and then rebase it on
top of the integration branch
5. then delete it from the overlay.

But the exact part of "Create a branch that contains only the history
of those packages" is the part I need to get down to an art .

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Sat, Jun 02, 2012 at 03:56:43AM +1200, Kent Fredric wrote:
> You can however merge dissimilar histories with no common parents if
> you know what you're doing. It does warn you, but it still lets you do
> it.
> 
> …
> 
> Yeah, selectively pulling in files with histories however is hard,
> I've occasionally been fussed enough to create temporary copies of
> branches, and then iterate over their history so the history is
> reduced to changes only for a small selection of files, but its
> largely lots of work, and I can't remember how to do it every time I
> go to do it -_-

I have to look it up every time I need it too, but the procedure
involves `git filter-branch` [1,2], and actually is pretty easy to
wrap your head around, even though the paricular commands are not so
easy to remember.

Trevor

[1]: http://stackoverflow.com/questions/7375528/
[2]: http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Fri, Jun 01, 2012 at 12:57:10PM +0000, Duncan wrote:
> William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:
> > Overlays aren't really part of this discussion; those are independent
> > trees which we have no control over, so commiting changes from overlays
> > to the main tree is the responsibility of the overlay maintainers.
> 
> But it seems to me that overlays are the primary use case for commits to 
> public trees other than gentoo first.  Otherwise, the whole rebase-vs-
> merge problem goes away, because the first public commit is to the gentoo 
> tree.  But especially with overlays (like kde) that have an overlay-
> first, test, then gentoo-tree, policy, that public overlay tree (which is 
> already in git) is part of the process.  Commits MUST go thru the overlay 
> to get to the tree, and that overlay is public, so constant rebasing is a 
> definite no-no.
> 
> Which unless your workaround idea works, pretty much leaves us with merge-
> commits as a necessity.  (Which of course, as Ciaran pointed out, are 
> part of the point of git, such that running git without merge-commits 
> defeats part of the purpose of the whole exercise.)

Overlays are completely separate repositories. There is nothing stopping
an overlay from using git right now even if the main tree isn't using
git. They just work in their git repositories until they are ready to
commit something to the main tree, then they move the changes to the
main tree.

What the main tree on git would give them is the ability to create a
branch from the main tree for their changes, but that would not be pushed
to the main repository.

All they would have to do when they are ready for their code to be
merged back into the main repository is make sure that they are creating
a fast-forward merge so that there is no merge commit on the master
branch.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
> Overlays are completely separate repositories. There is nothing stopping
> an overlay from using git right now even if the main tree isn't using
> git. They just work in their git repositories until they are ready to
> commit something to the main tree, then they move the changes to the
> main tree.
What about overlay repositories that elect to be a branch of the main
tree via git?

Do we call that forbidden usage?

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 04:33, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
>> Overlays are completely separate repositories. There is nothing stopping
>> an overlay from using git right now even if the main tree isn't using
>> git. They just work in their git repositories until they are ready to
>> commit something to the main tree, then they move the changes to the
>> main tree.
> What about overlay repositories that elect to be a branch of the main
> tree via git?
>
> Do we call that forbidden usage?

You can't practically use any overlay foolish enough to publish these
repositories for end user consumption.

Its just a silly idea. There's no problem with having overlays cloned
into a branch as a step towards it hitting mainline, but overlays
being distributed to users as main tree branches is just a silly idea.

 Mostly, because end-users will still have ::gentoo via rsync, and the
load of cloning a git repo of ::gentoo will be too much for the
average user, doing that just to get an overlay is exhaustively
execessive vs the current mechanism we have for overlays, and it comes
at a penalty at being not as good as overlays in that you can't easily
have >1 of them.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 12:33 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> What about overlay repositories that elect to be a branch of the main
> tree via git?
>
> Do we call that forbidden usage?

I think that branches off of the main tree are mainly going to be
useful for more eclass/profile/etc-related work.  Work on a package or
small group of packages will almost always go better in a completely
independent overlay.  If you try to do that kind of work in a branch
then if you create an rsync tree from that branch it will contain all
the other packages that you aren't working on, and they'll get stale
very quickly.  Anybody using that as an overlay will get a bunch of
old ebuilds for who-knows-what in their tree.

Now, branches in the main tree are going to be really useful for stuff
like package moves, new virtuals, eclass api changes, or other messy
changes that have big tree-wide impacts.  You can stage the change and
fix the 300 impacted ebuilds in a branch, get lots of people to test
them, and then merge those in with a single transaction, pulling in
updates from master all the while.  That is more about portage tree
maintenance than package maintenance per-se.

All that said, having the tree in git is still a big help to proxy
maintainers and others even with all these issues.  I've worked as an
outside contributor to other projects and it is a lot easier with git.
 I can easily work in my own PM, rebase against their master, and then
easily submit a nice clean diff as a patch, even without doing any
pushing at all.  I don't have to have push rights to anything official
to be more efficient in my contributions.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Fri, Jun 01, 2012 at 04:33:35PM +0000, Robin H. Johnson wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
> > Overlays are completely separate repositories. There is nothing stopping
> > an overlay from using git right now even if the main tree isn't using
> > git. They just work in their git repositories until they are ready to
> > commit something to the main tree, then they move the changes to the
> > main tree.
> What about overlay repositories that elect to be a branch of the main
> tree via git?
> 
> Do we call that forbidden usage?

No, it just would mean that they have to know how to rebase their
changes on master before they commit.

They would clone the main tree to their overlay location, then make a
kde branch in their location. That branch would be where they did their
work and they would keep master in sync with the main tree (upstream) by
running git pull.

To merge the overlay changes into the master, a developer would use a
git remote to add the kde overlay to his tree, add a kde branch that
tracked the remote kde branch, rebase that on current master, merge it
into master to create a fast-forward merge then push.

I think that probably sounds more complicated than it is, so let me know
if you need clarification.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 08:26, Duncan <1i5t5.duncan@cox.net> wrote:
> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
> Of course, if all the official overlays are converted to git branches of
> the main tree... but won't they still require rebasing as they've already
> been pushed?  (This assumes your workaround idea doesn't work.  If it
> does, great!)
>

End users will still want to work with overlays that are not merged
with the main tree, not merely git branches.

Its foreseeable that there will be git branches that /track/ overlays
and exist as an integration pipeline for content from the overlays
joining core gentoo, but end users will not want to use that.

For the simple reason of course, that as soon as you want >1 overlay,
portage's way of doing it with separate repositories is far more
effective.

You don't want each user to have to maintain an octopus merge between
all the branches they want to have commits from ;)

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
> On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> > 1.
> > Discussion on merge policy. Originally I thought we would disallow merge
> > commits, so that we would get a cleaner history. However, it turns out that if
> > the repo ends up being pushed to different places with slightly different
> > histories, merges are absolutely going to be required to prevent somebody from
> > having to rebase at least one of their sets of commits that are already pushed.
> 
> Not sure I'm following, but I will be the first to admit that I'm a
> git novice.  Would this be aided by a convention, like only committing
> to master on the gentoo official repository, and any on-the-side work
> on places like github/etc stays in branches?  Those repositories would
> just keep getting fed commits on master from the official repository.

 Iagree with this; I think we should ban merge commits on master. That
 would force everyone to rebase their work on current master before they
 commit to master which would make the history clean.

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Thu, 31 May 2012 14:18:04 -0500
William Hubbs <williamh@gentoo.org> wrote:
> > Not sure I'm following, but I will be the first to admit that I'm a
> > git novice.  Would this be aided by a convention, like only
> > committing to master on the gentoo official repository, and any
> > on-the-side work on places like github/etc stays in branches?
> > Those repositories would just keep getting fed commits on master
> > from the official repository.
> 
>  Iagree with this; I think we should ban merge commits on master. That
>  would force everyone to rebase their work on current master before
> they commit to master which would make the history clean.

So what's the point of switching to git if you want to ban the main
reason git exists?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Thu, May 31, 2012 at 08:23:31PM +0100, Ciaran McCreesh wrote:
> On Thu, 31 May 2012 14:18:04 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> > > Not sure I'm following, but I will be the first to admit that I'm a
> > > git novice.  Would this be aided by a convention, like only
> > > committing to master on the gentoo official repository, and any
> > > on-the-side work on places like github/etc stays in branches?
> > > Those repositories would just keep getting fed commits on master
> > > from the official repository.
> > 
> >  Iagree with this; I think we should ban merge commits on master. That
> >  would force everyone to rebase their work on current master before
> > they commit to master which would make the history clean.
> 
> So what's the point of switching to git if you want to ban the main
> reason git exists?

To clarify: we should only allow fast-forward merges on master.

My big complaint about merge commits is if you do a git show <hash> on
a merge commit, you get nothing, so there is no way to see what actually
changed in that commit.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

William Hubbs wrote:
> To clarify: we should only allow fast-forward merges on master.

Not a dev yet, but +1

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Thu, 31 May 2012 17:04:30 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Thu, May 31, 2012 at 08:23:31PM +0100, Ciaran McCreesh wrote:
> > On Thu, 31 May 2012 14:18:04 -0500
> > William Hubbs <williamh@gentoo.org> wrote:
> > > > Not sure I'm following, but I will be the first to admit that
> > > > I'm a git novice.  Would this be aided by a convention, like
> > > > only committing to master on the gentoo official repository,
> > > > and any on-the-side work on places like github/etc stays in
> > > > branches? Those repositories would just keep getting fed
> > > > commits on master from the official repository.
> > > 
> > >  Iagree with this; I think we should ban merge commits on master.
> > > That would force everyone to rebase their work on current master
> > > before they commit to master which would make the history clean.
> > 
> > So what's the point of switching to git if you want to ban the main
> > reason git exists?
> 
> To clarify: we should only allow fast-forward merges on master.
> 
> My big complaint about merge commits is if you do a git show <hash> on
> a merge commit, you get nothing, so there is no way to see what
> actually changed in that commit.

Or you use a graphical tool which shows the whole merge history and you
see the exact changes happening rather than some blob with 'do foo, do
bar, and some baz too'.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[James Cloos]

>>>>> "WH" == William Hubbs <williamh@gentoo.org> writes:

WH> My big complaint about merge commits is if you do a git show <hash> on
WH> a merge commit, you get nothing,

With current git and proper merge logs you get useful info.

   The headers contain the hashes, so you can get the list of
   commits pulled by that merge.

   The signed tag log is show.

   And merge conflicts also are shown.

Based on the hashes in the Merge: header, you can use git log to see the
individual commits or git diff to see the whole picture at once.

Linus’ current tip is a good example:

     cd .../linux
     git show 1193755ac632

So, Gentoo shouldn't prohibit merges.  Instead, it should demand that
all merges be of signed tags.

The plan includes signed commits anyway, so signed tags for pulls will be
fully supported by any version of git which might be used.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On Thu, 31 May 2012 14:18:04 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
> > On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson
> > <robbat2@gentoo.org> wrote:
> > > 1.
> > > Discussion on merge policy. Originally I thought we would
> > > disallow merge commits, so that we would get a cleaner history.
> > > However, it turns out that if the repo ends up being pushed to
> > > different places with slightly different histories, merges are
> > > absolutely going to be required to prevent somebody from having
> > > to rebase at least one of their sets of commits that are already
> > > pushed.
> > 
> > Not sure I'm following, but I will be the first to admit that I'm a
> > git novice.  Would this be aided by a convention, like only
> > committing to master on the gentoo official repository, and any
> > on-the-side work on places like github/etc stays in branches?
> > Those repositories would just keep getting fed commits on master
> > from the official repository.
> 
>  Iagree with this; I think we should ban merge commits on master. That
>  would force everyone to rebase their work on current master before
> they commit to master which would make the history clean.

What would git signing work with rebased commits? Would all of them
have to be signed once again?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Michał Górny писал 2012-05-31 23:33:
> On Thu, 31 May 2012 14:18:04 -0500
> William Hubbs <williamh@gentoo.org> wrote:
>
>> On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
>> > On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson
>> > <robbat2@gentoo.org> wrote:
>> > > 1.
>> > > Discussion on merge policy. Originally I thought we would
>> > > disallow merge commits, so that we would get a cleaner history.
>> > > However, it turns out that if the repo ends up being pushed to
>> > > different places with slightly different histories, merges are
>> > > absolutely going to be required to prevent somebody from having
>> > > to rebase at least one of their sets of commits that are already
>> > > pushed.
>> >
>> > Not sure I'm following, but I will be the first to admit that I'm 
>> a
>> > git novice.  Would this be aided by a convention, like only
>> > committing to master on the gentoo official repository, and any
>> > on-the-side work on places like github/etc stays in branches?
>> > Those repositories would just keep getting fed commits on master
>> > from the official repository.
>>
>>  Iagree with this; I think we should ban merge commits on master. 
>> That
>>  would force everyone to rebase their work on current master before
>> they commit to master which would make the history clean.
>
> What would git signing work with rebased commits? Would all of them
> have to be signed once again?

Commits itsels still will be signed
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 07:52, Alexey Shvetsov <alexxy@gentoo.org> wrote:
>>
>> What would git signing work with rebased commits? Would all of them
>> have to be signed once again?
>
>
> Commits itsels still will be signed


Do you know how git does this? Do you have experience/information you
can cite as to that this works?

Commit signing seems poorly documented at present, and I've been
looking at the git internals, and it would *APPEAR* that the content
that is signed is the blob of text you normally get when you

   git cat-file -p $SHA1

And indeed, if you  git cat-file -p $SHA1 > file, extract the
SIGNATURE part into its own file (removing the leading spaces), and
remove the "gnupg" section from the commit headers,   gpg --verify
$sigfile $file   # tells me I have a good signature.

Just I haven't worked out what happens when the SHA1 of the 'parent'
header changes, which *will* change if the rebase is anything other
than a fast-forward.

If that SHA1 changes, the gpg signature will surely fail?


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfredric@gmail.com> wrote:
> Just I haven't worked out what happens when the SHA1 of the 'parent'
> header changes, which *will* change if the rebase is anything other
> than a fast-forward.
>
> If that SHA1 changes, the gpg signature will surely fail?

Rebasing doesn't modify past commits - it creates new ones and the
past ones are no longer in the history of the current head.  So, it
doesn't break the old signatures so much as discard them.  You would
need to create new signatures in their place, presumably from whoever
performed the rebase.

I'm trying to glean what I can from the little info out there about
how the new commit signatures work, but I don't think that you can use
signatures to convey authorship if later authors are going to rebase
the branch.  The situation is not unlike what we have now with
manifests.

As far as I can tell if you want to do work outside of master, and
then get those commits into master but preserve all the past
signatures in the history of master, then you'd need to do a merge
commit, so that all the deltas to do the merge are in a separate
commit which is then signed by the person doing the merge.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 14:49, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfredric@gmail.com> wrote:
>> Just I haven't worked out what happens when the SHA1 of the 'parent'
>> header changes, which *will* change if the rebase is anything other
>> than a fast-forward.
>>
>> If that SHA1 changes, the gpg signature will surely fail?
>
> Rebasing doesn't modify past commits - it creates new ones and the
> past ones are no longer in the history of the current head.  So, it
> doesn't break the old signatures so much as discard them.  You would
> need to create new signatures in their place, presumably from whoever
> performed the rebase.


Hmm, thats annoying. Almost makes me wish it was the trees that were
signed, not the commits.

Although, I probably could brew up a prototype resigning tool ( based
on Git::PurePerl ,... when they accept and publish my changes ) , just
would be problematic because simply the act of signing a past commit
means the SHA1 of the commit itself is different, so all successive
commits after a re-signed commit will change and also need to be
rebased and re-signed.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>
> Hmm, thats annoying. Almost makes me wish it was the trees that were
> signed, not the commits.

I think it is the tree that is signed, but that changes too.

Rebasing re-applies the same diff to the new head to give you a new
set of commits.  When you apply the same diff to a different parent
you end up with a different tree, so the tree signature won't be the
same either.

Keep in mind that git does not store a long train of diffs.  It stores
a long chain of complete trees, and the diffs get calculated if you
ask for them.  Since it is COW you only re-store files that actually
change, and incorporate others by reference.  However, if you have a
1MB file that you change 1 line on 100x, you'll end up with 100MB of
files.  Of course, when they get packed I'd hope that they'd compress
well.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 22:54, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>>
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
>
> I think it is the tree that is signed, but that changes too.

Nope, at least not as far as I can tell, and I just implemented commit
signature verification >_>

> Rebasing re-applies the same diff to the new head to give you a new
> set of commits.  When you apply the same diff to a different parent
> you end up with a different tree, so the tree signature won't be the
> same either.

Not nessecarily. Given that :

 a file with a given content has a fixed SHA
A tree is just a list of these SHA's , and that in turn is referenced
by SHA, so if 2 commits have identical file content, their 'tree' sha
will be the same ( in theory ).

So that means, if you perform a rebase, assuming the filesystem looks
the same as it did before the rebase, it will have the same SHA1 for
the tree, regardless of the process of how it got to be that way.

The only SHA that has to change is the 'parent',

( Demonstration here: https://gist.github.com/2851330 , note I have 2
commits with the same tree sha, and the tree sha only really refers to
one file 3 times as all the empty files have same sha  )

But unfortunately, with a rebase, even if the trees don't change, if
the history order changes, the commits themselves have to change due
to the "parent" sha needing to change ( yes, I know commits are
immutable in reality, and they don't change, but are duplicated and
the duplicate is given the new sha , but the effect is still the same
, because those unreferenced commits will eventually get reaped )


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Fri, 1 Jun 2012 23:23:34 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> On 1 June 2012 22:54, Rich Freeman <rich0@gentoo.org> wrote:
> > Rebasing re-applies the same diff to the new head to give you a new
> > set of commits.  When you apply the same diff to a different parent
> > you end up with a different tree, so the tree signature won't be the
> > same either.
> 
> Not nessecarily. Given that :
> 
>  a file with a given content has a fixed SHA
> A tree is just a list of these SHA's , and that in turn is referenced
> by SHA, so if 2 commits have identical file content, their 'tree' sha
> will be the same ( in theory ).
> 
> So that means, if you perform a rebase, assuming the filesystem looks
> the same as it did before the rebase, it will have the same SHA1 for
> the tree, regardless of the process of how it got to be that way.

I don't think that 'not necessarily' makes any difference here. Maybe
in our particular case this is not as likely as with regular source
code tree but while rebasing you can hit conflicts. And then files
start to change...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>
> Nope, at least not as far as I can tell, and I just implemented commit
> signature verification >_>

I've been trying to find an example of a signed commit, but can't find
one anywhere, so it is hard to tell what it is doing without going
through the git source carefully.  If you have an example of a signed
commit feel free to send it to me.

Note that I am NOT interested in the output of any git operation (such
as git log --show-signature, git show, etc) - these are all processed
and do not reveal what is actually going on.  I want a copy of the
actual file containing the signature.  If the signature is embedded in
the commit then I want the file in the objects directory tree that
contains the commit.  They're just compressed text files (though it is
a bit of a pain to decompress them).

> Not nessecarily. Given that :
>
>  a file with a given content has a fixed SHA
> A tree is just a list of these SHA's , and that in turn is referenced
> by SHA, so if 2 commits have identical file content, their 'tree' sha
> will be the same ( in theory ).
>
> So that means, if you perform a rebase, assuming the filesystem looks
> the same as it did before the rebase, it will have the same SHA1 for
> the tree, regardless of the process of how it got to be that way.

The filesystem WON'T look the same after a rebase.

quick example (operations done in this order):

file in commit A in master:
1
2
3
4
5

file in commit B in a branch off of master:
1
2a
3
4
5

file in commit C in master:
1
2
3
4a
5

if you merge master into the branch you'll end up with a new commit D
whose parent is B that looks like:
1
2a
3
4a
5

if instead you rebase master into the branch you'll end up with a new
commit D whose parent is C that looks like:
1
2a
3
4a
5

The history for the branch will no longer contain B.  If there were 14
commits B1..14 you'd end up with 14 commits D1.14 that each contain
the line 4a.  None of them would use the same trees as B1..14, and
they can't use the same signatures as a result, even if only the tree
was signed.   As far as the new history was concerned, line 4a was
there before the branch was started.

At least, that is my understanding of rebasing.  Again, I'm a bit of a
git novice, but I never really grokked git until I saw a presentation
that didn't start with commands, but instead started out with just
walking through the actual structure of the repository.  Once you grok
the COW model I find it all clicks into place.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Alexey Shvetsov]

Hi!

Check kde overlay ;) we used signed commits here

Rich Freeman писал 2012-06-01 16:42:
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfredric@gmail.com> 
> wrote:
>>
>> Nope, at least not as far as I can tell, and I just implemented 
>> commit
>> signature verification >_>
>
> I've been trying to find an example of a signed commit, but can't 
> find
> one anywhere, so it is hard to tell what it is doing without going
> through the git source carefully.  If you have an example of a signed
> commit feel free to send it to me.
>
> Note that I am NOT interested in the output of any git operation 
> (such
> as git log --show-signature, git show, etc) - these are all processed
> and do not reveal what is actually going on.  I want a copy of the
> actual file containing the signature.  If the signature is embedded 
> in
> the commit then I want the file in the objects directory tree that
> contains the commit.  They're just compressed text files (though it 
> is
> a bit of a pain to decompress them).
>
>> Not nessecarily. Given that :
>>
>>  a file with a given content has a fixed SHA
>> A tree is just a list of these SHA's , and that in turn is 
>> referenced
>> by SHA, so if 2 commits have identical file content, their 'tree' 
>> sha
>> will be the same ( in theory ).
>>
>> So that means, if you perform a rebase, assuming the filesystem 
>> looks
>> the same as it did before the rebase, it will have the same SHA1 for
>> the tree, regardless of the process of how it got to be that way.
>
> The filesystem WON'T look the same after a rebase.
>
> quick example (operations done in this order):
>
> file in commit A in master:
> 1
> 2
> 3
> 4
> 5
>
> file in commit B in a branch off of master:
> 1
> 2a
> 3
> 4
> 5
>
> file in commit C in master:
> 1
> 2
> 3
> 4a
> 5
>
> if you merge master into the branch you'll end up with a new commit D
> whose parent is B that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> if instead you rebase master into the branch you'll end up with a new
> commit D whose parent is C that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> The history for the branch will no longer contain B.  If there were 
> 14
> commits B1..14 you'd end up with 14 commits D1.14 that each contain
> the line 4a.  None of them would use the same trees as B1..14, and
> they can't use the same signatures as a result, even if only the tree
> was signed.   As far as the new history was concerned, line 4a was
> there before the branch was started.
>
> At least, that is my understanding of rebasing.  Again, I'm a bit of 
> a
> git novice, but I never really grokked git until I saw a presentation
> that didn't start with commands, but instead started out with just
> walking through the actual structure of the repository.  Once you 
> grok
> the COW model I find it all clicks into place.
>
> Rich

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 00:42, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfredric@gmail.com> wrote:
>>
>> Nope, at least not as far as I can tell, and I just implemented commit
>> signature verification >_>
>
> I've been trying to find an example of a signed commit, but can't find
> one anywhere, so it is hard to tell what it is doing without going
> through the git source carefully.  If you have an example of a signed
> commit feel free to send it to me.
>
> Note that I am NOT interested in the output of any git operation (such
> as git log --show-signature, git show, etc) - these are all processed
> and do not reveal what is actually going on.  I want a copy of the
> actual file containing the signature.  If the signature is embedded in
> the commit then I want the file in the objects directory tree that
> contains the commit.  They're just compressed text files (though it is
> a bit of a pain to decompress them).

"git cat-file -p $sha" is as close as you can get to commit objects
without needing to write your own decompressing wrapper.  But it gives
the same results.

Here is a sample signed git commit ( sans compression ) :

https://gist.github.com/2852363

Line 5 to 21 are where the GPG signature is stored. ( Git uses the
leading space on all the lines of the GPG sig to indicate that its
part of the signature, line 22 does not lead with a space, so that
line is after the GPG signature.  Line 22 also is empty, which ends
the "header" section of the commit, and there starts the "comment"
section.

If you don't believe me that "git cat-file -p $sha" is reliable, here
is a simple script that has no git internals in it , its just Zlib
decompression : https://gist.github.com/2852411

perl /tmp/deflate.pl .git/objects/66/50c09ad7b2a62e28476e639654443015ac5945

And that re-emits exactly the same thing : https://gist.github.com/2852363

And if you want to do that yourself, here's that object in compressed
form base64 encoded https://gist.github.com/2852436


> The filesystem WON'T look the same after a rebase.
>
> quick example (operations done in this order):
>
> file in commit A in master:
> 1
> 2
> 3
> 4
> 5
>
> file in commit B in a branch off of master:
> 1
> 2a
> 3
> 4
> 5
>
> file in commit C in master:
> 1
> 2
> 3
> 4a
> 5
>
> if you merge master into the branch you'll end up with a new commit D
> whose parent is B that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> if instead you rebase master into the branch you'll end up with a new
> commit D whose parent is C that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> The history for the branch will no longer contain B.  If there were 14
> commits B1..14 you'd end up with 14 commits D1.14 that each contain
> the line 4a.  None of them would use the same trees as B1..14, and
> they can't use the same signatures as a result, even if only the tree
> was signed.   As far as the new history was concerned, line 4a was
> there before the branch was started.

It all depends really on how you do the rebase, if the changes in the
rebase shadow all the competing changes , or the changes are shadowed
out before the rebase, the rebase will be the same afterwards, just
with a different history.

ie:

  root -> a -> b -> c -> d( backout of c )

If you had started a branch off "b", and then rebased that branch on
top of d, the tree would be in the exact same state, but the history
would have changed.

And likewise, if the change was :

  root -> a -> b -> c -> d -> e

And you started a branch at b, with commits m, n, o, p , changing the
same lines c, d and e changed,
and when you rebased, you opted to let the changes in m, n, and o
replace the changes in c, d and e,
( which has the same effect as if you had deleted c , d and e, except
they're still there in the history ), when you move the branch from b
to e, the last commit of that branch (p) will still be the same.

The rebased commits m, n, and o will be different to what they were
when they were on "b", because now they're not only making changes vs
"b", but they're also replacing code added in c, d, and e.

Sure, this only happens in certain circumstances, and usually when it
happens, its because you want it to happen , but it does happen, and
its quite useful sometimes.

( essentially, x + y + z == x can be true, as long as z = -y  )


> At least, that is my understanding of rebasing.  Again, I'm a bit of a
> git novice, but I never really grokked git until I saw a presentation
> that didn't start with commands, but instead started out with just
> walking through the actual structure of the repository.  Once you grok
> the COW model I find it all clicks into place.

Yeah, chapter 9 of the Pro Git book is where I recommend everyone with
even a sliver of comp-sci knowledge to start.
http://www.git-scm.com/book/en/Git-Internals

Once you see its basically a bunch of text files, that refer to each
other via sha1 , and are stored in files named after their sha1, (
after a bit of compression ), all that graph theory just clicks and
you wonder how they managed to make the UI so complicated =p




-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

> "git cat-file -p $sha" is as close as you can get to commit objects
> without needing to write your own decompressing wrapper.  But it gives
> the same results.

Now, does the "signed data" also contain the parent sha?

If yes, our discussion about rebasing is moot, because a rebase will in every 
case destroy previous signatures.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> "git cat-file -p $sha" is as close as you can get to commit objects
>> without needing to write your own decompressing wrapper.  But it gives
>> the same results.
>
> Now, does the "signed data" also contain the parent sha?
>
> If yes, our discussion about rebasing is moot, because a rebase will in every
> case destroy previous signatures.
>

Yes. Which basically means, you *cannot* have both

a) rebase only merges
and
b) every commit must be signed

as policies.

At very best, I think either
a) a future git might support signed rebases ( ie: replacing existing
signatures with new signatures in the name of the person performing
the rebase )
or
b) somebody could write a wrapper that provides signed-rebase support
until git get around to implementing it natively.

and even then, you're going to lose original signing info ( Though,
thats no worse than the signer of the manifest file changing every
sign )


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

> On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> >> "git cat-file -p $sha" is as close as you can get to commit objects
> >> without needing to write your own decompressing wrapper.  But it gives
> >> the same results.
> > 
> > Now, does the "signed data" also contain the parent sha?
> > 
> > If yes, our discussion about rebasing is moot, because a rebase will in
> > every case destroy previous signatures.
> 
> Yes. Which basically means, you *cannot* have both
> 
> a) rebase only merges
> and
> b) every commit must be signed
> 
> as policies.
> 

I would say that this is a very strong argument in favour of allowing merge 
commits.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>> On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> Yes. Which basically means, you *cannot* have both
>>
>> a) rebase only merges
>> and
>> b) every commit must be signed
>>
>> as policies.
>>
>
> I would say that this is a very strong argument in favour of allowing merge
> commits.

One advantage of merge commits with signatures is that the history
really does reflect who signed what.

Proxy maintainer signs a bunch of ebuilds.  I merge them in.  The
commits show that the proxy maintainer signed a bunch of work done
against an old tree, and I signed a bunch of merge diffs that
basically synced them up to the new tree.

However, this is missing another issue.  What is the value of
preserving all those original signatures in the first place?  I'd
think that they'd mainly be used as some kind of web-of-trust.  Well,
would such a web-of-trust include proxy maintainers in the first
place?

If you want the tree to be traceable to Gentoo devs, then rewriting
the signatures is probably a good thing.

However, Kent did point out the rebase function doesn't actually apply
new signatures to the "new old" commits anyway, so you'd end up with
unsigned commits in the history.

git-rebase is just a shell script, that ultimately just calls
git-commit as far as I can see, which means that implementing
re-signing is just a matter of adding the appropriate parameters, or
use default configuration (assuming it doesn't already do this).

Rich

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Fri, Jun 1, 2012 at 5:53 PM, Rich Freeman <rich0@gentoo.org> wrote:
> If you want the tree to be traceable to Gentoo devs, then rewriting
> the signatures is probably a good thing.

I'd say that signing the merge commit is good enough. It says the
Gentoo dev who merged it has reviewed the changes and can be held
responsible for them. One could even say that he mediates a
web-of-trust to the more casual contributor who signed the original
csets.

Cheers,

Dirkjan

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 03:53, Rich Freeman <rich0@gentoo.org> wrote:

> git-rebase is just a shell script, that ultimately just calls
> git-commit as far as I can see, which means that implementing
> re-signing is just a matter of adding the appropriate parameters, or
> use default configuration (assuming it doesn't already do this).
>
> Rich
>

Oh that makes it slightly easier, I didn't realise it was just a blob
of bash doing all that O.o

grep -nR 'git commit' git-rebase*
git-rebase--interactive.sh:152:	warn "	git commit --amend"
git-rebase--interactive.sh:441:		git commit --amend --no-post-rewrite || {
git-rebase--interactive.sh:484:			do_with_author output git commit
--no-verify -F "$squash_msg" ||
git-rebase--interactive.sh:491:				do_with_author git commit
--no-verify -F "$fixup_msg" ||
git-rebase--interactive.sh:496:				do_with_author git commit --no-verify -e ||
git-rebase--interactive.sh:699:  git commit --amend
git-rebase--interactive.sh:703:  git commit
git-rebase--interactive.sh:723:		do_with_author git commit --no-verify
-F "$msg" -e || {
git-rebase--merge.sh:30:		if ! git commit --no-verify -C "$cmt"
git-rebase--merge.sh:32:			echo "Commit failed, please do not call
\"git commit\""


Throwing '-S' in there liberally aught to do the trick.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Fri, Jun 01, 2012 at 11:53:52AM -0400, Rich Freeman wrote:
> However, Kent did point out the rebase function doesn't actually apply
> new signatures to the "new old" commits anyway, so you'd end up with
> unsigned commits in the history.
Only in your local history. The push to the central repo would only send
the commits in the active chain to your branch HEAD.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

> Only in your local history. The push to the central repo would only send
> the commits in the active chain to your branch HEAD.

Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their signatures by the rebase process.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Robin H. Johnson]

On Sat, Jun 02, 2012 at 04:56:33AM +1200, Kent Fredric wrote:
> > Only in your local history. The push to the central repo would only send
> > the commits in the active chain to your branch HEAD.
> Any commits that are rebased, and then replicated somewhere after that
> rebase, will be stripped of their signatures by the rebase process.
I'm saying the old signatures will not be pushed out for verification,
only the new signatures will.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On Sat, 2 Jun 2012 03:25:43 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> >> "git cat-file -p $sha" is as close as you can get to commit objects
> >> without needing to write your own decompressing wrapper.  But it
> >> gives the same results.
> >
> > Now, does the "signed data" also contain the parent sha?
> >
> > If yes, our discussion about rebasing is moot, because a rebase
> > will in every case destroy previous signatures.
> >
> 
> Yes. Which basically means, you *cannot* have both
> 
> a) rebase only merges
> and
> b) every commit must be signed
> 
> as policies.
> 
> At very best, I think either
> a) a future git might support signed rebases ( ie: replacing existing
> signatures with new signatures in the name of the person performing
> the rebase )
> or
> b) somebody could write a wrapper that provides signed-rebase support
> until git get around to implementing it natively.
> 
> and even then, you're going to lose original signing info ( Though,
> thats no worse than the signer of the manifest file changing every
> sign )

Yes, it's no worse so we're practically considering implementing a very
complex mechanism for no real benefit.

As I see it, as good would be only requiring some kind of 'top-level'
commits to be signed. For example, if one does merge a branch
to the tree, a signed merge commit should already be good enough for
us. Not sure if git is able to do that, however...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 11:12 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Now, does the "signed data" also contain the parent sha?
>

So, I was working on a lengthy email which now would be fairly
repetitive of what Kent posted.

Suffice it to say I managed to rip out a commit from the kde overlay,
deflate it, and compared that the signature:

-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)

 iQEcBAABCgAGBQJPx+mcAAoJEO+t9ga+3I3aqLoH/0OrRA1+NPRHGfbbLoQrqMwl
 sB+2It2Pb9LfPjEme+lrQu5WgFY4j7k0qd2ZYdnXM7JdQjsqmpfAMloHh5JN4TAS
 4vk8+u2GJCYgzL/SY5XlPl2l8dT91PhQJSN0yVt4Q9TsoN3nzVpFBjACJCy9R6j2
 HrXvz/g3+MqY/9VesV8IiVgvQUTVgCdh8zBJ2rVyWAVH0bErsn518aiwEyfzNOxA
 1qJxxgGJLMpXp+nI8rnmhqTAAKiNA+byAKAsTEl3LS7OvQZ51aOCwa4A2GLOn2ef
 5JmuYQG5/FsS0RfXrqk72PiStTBWa3TakHYrgNXOXlslIR5AIB2tYnXqZcdEqYQ=
 =fucY
 -----END PGP SIGNATURE-----

does in fact verify for the payload:
--start--
tree 7d7f97cded40158d0f580ca6fbe97398d5c867f8
parent 14d7d9cb2219f64c7a715d8da0bbe48a32c9dad8
author Johannes Huber <johu@gentoo.org> 1338501525 +0200
committer Johannes Huber <johu@gentoo.org> 1338501525 +0200

[kde-base/kdelibs] Sync with live.

(Portage version: 2.2.0_alpha108/git/Linux i686, unsigned Manifest commit)
--end--

Dump those into a text file and run gpg for yourself...  The full
commit contains the gpg signature in a field as already posted by
Kent.

And while I appreciate the performance boost and space savings
provided by all the compression/packing/etc, I've learned to almost
hate those features with a passion this morning...  Getting a cloned
repo unpacked, and the commit decompressed was a bit pita.  The other
issue is that the header in the commit file is stripped before it is
signed, the actual start of the commit is "commit 830tree..."

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@gentoo.org> wrote:
> What would git signing work with rebased commits? Would all of them
> have to be signed once again?
>

The whole point of rebasing is to throw away history (which is either
good or bad based on your perspective).

So, if 14 devs spend 3 years and 2000 commits working on something in
a branch, and I commit it to master using a rebase, then all you'll
see in the master history is that rich0 committed 20k lines of code to
master on May 31st, and that would be signed by me.

I think that rebasing before merging is a pretty typical workflow
anyway - when you submit a patch to Linus, he doesn't really care that
you spent six months tweaking it - he just is getting a big blob of
code that either works or doesn't.  Does all that sub-history really
matter?  You could always push the branch to the repository if you
wanted to keep it on the side.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Thu, 31 May 2012 15:58:43 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > What would git signing work with rebased commits? Would all of them
> > have to be signed once again?
> >
> 
> The whole point of rebasing is to throw away history (which is either
> good or bad based on your perspective).
> 
> So, if 14 devs spend 3 years and 2000 commits working on something in
> a branch, and I commit it to master using a rebase, then all you'll
> see in the master history is that rich0 committed 20k lines of code to
> master on May 31st, and that would be signed by me.
> 
> I think that rebasing before merging is a pretty typical workflow
> anyway - when you submit a patch to Linus, he doesn't really care that
> you spent six months tweaking it - he just is getting a big blob of
> code that either works or doesn't.  Does all that sub-history really
> matter?  You could always push the branch to the repository if you
> wanted to keep it on the side.

That sounds like a pretty poor workflow to me. If I tweak something for
3 years, I'm likely to have a larger set of logically organized commits.
I'm not saying it's unlikely I'm going to rebase fixes for obvious
mistakes but putting everything onto one blob just makes the changes
harder to read and less maintainable.

For example, if I first create a basic function and then add additional
options to it, I'm likely to keep those as separate commits. If one of
the changes was a really bad idea, I'd like to revert the appropriate
commit rather than removing all traces of it by hand and mistakenly
introducing even worse breakage.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michael Orlitzky]

On 05/31/12 16:09, Michał Górny wrote:
> On Thu, 31 May 2012 15:58:43 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>> What would git signing work with rebased commits? Would all of them
>>> have to be signed once again?
>>>
>>
>> The whole point of rebasing is to throw away history (which is either
>> good or bad based on your perspective).
>>
>> So, if 14 devs spend 3 years and 2000 commits working on something in
>> a branch, and I commit it to master using a rebase, then all you'll
>> see in the master history is that rich0 committed 20k lines of code to
>> master on May 31st, and that would be signed by me.
>>
>> I think that rebasing before merging is a pretty typical workflow
>> anyway - when you submit a patch to Linus, he doesn't really care that
>> you spent six months tweaking it - he just is getting a big blob of
>> code that either works or doesn't.  Does all that sub-history really
>> matter?  You could always push the branch to the repository if you
>> wanted to keep it on the side.
> 
> That sounds like a pretty poor workflow to me. If I tweak something for
> 3 years, I'm likely to have a larger set of logically organized commits.
> I'm not saying it's unlikely I'm going to rebase fixes for obvious
> mistakes but putting everything onto one blob just makes the changes
> harder to read and less maintainable.
> 
> For example, if I first create a basic function and then add additional
> options to it, I'm likely to keep those as separate commits. If one of
> the changes was a really bad idea, I'd like to revert the appropriate
> commit rather than removing all traces of it by hand and mistakenly
> introducing even worse breakage.
> 

That isn't what rebasing does, unless you do an interactive rebase and
decide to squash the commits.

The usual use case for a rebase is just to avoid the ugly merge commit.
For example,

  1. I clone your portage tree
  2. I start making commits locally
  3. You add a new package
  4. I try to push my changes to you

Step 4 doesn't work because your repo has changed. I can either,

  a) pull from you again (merge)
  b) pull with a rebase

And then I should be able to push to you, assuming there were no conflicts.

The merge option works fine but generates an ugly merge commit. The
rebase takes our two histories and combines them into a nice linear
history. In this case, a rebase would (essentially) take all of my
commits and stick them on top of your "new package" commit. Afterwards,
it looks like there's a nice linear history: you added a package, and
then I did a bunch of other stuff. All of the commits are there.

Since that history is linear and it looks like just a bunch of stuff on
top of your existing tree, I can push it to you without problems.

The only downside to the rebase is that it modifies my local history.
So, if somebody cloned *my* repo in the middle of that, they could get
screwed up.

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 05/31/12 16:09, Michał Górny wrote:
> > On Thu, 31 May 2012 15:58:43 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> > 
> >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@gentoo.org>
> >> wrote:
> >>> What would git signing work with rebased commits? Would all of
> >>> them have to be signed once again?
> >>>
> >>
> >> The whole point of rebasing is to throw away history (which is
> >> either good or bad based on your perspective).
> >>
> >> So, if 14 devs spend 3 years and 2000 commits working on something
> >> in a branch, and I commit it to master using a rebase, then all
> >> you'll see in the master history is that rich0 committed 20k lines
> >> of code to master on May 31st, and that would be signed by me.
> >>
> >> I think that rebasing before merging is a pretty typical workflow
> >> anyway - when you submit a patch to Linus, he doesn't really care
> >> that you spent six months tweaking it - he just is getting a big
> >> blob of code that either works or doesn't.  Does all that
> >> sub-history really matter?  You could always push the branch to
> >> the repository if you wanted to keep it on the side.
> > 
> > That sounds like a pretty poor workflow to me. If I tweak something
> > for 3 years, I'm likely to have a larger set of logically organized
> > commits. I'm not saying it's unlikely I'm going to rebase fixes for
> > obvious mistakes but putting everything onto one blob just makes
> > the changes harder to read and less maintainable.
> > 
> > For example, if I first create a basic function and then add
> > additional options to it, I'm likely to keep those as separate
> > commits. If one of the changes was a really bad idea, I'd like to
> > revert the appropriate commit rather than removing all traces of it
> > by hand and mistakenly introducing even worse breakage.
> > 
> 
> That isn't what rebasing does, unless you do an interactive rebase and
> decide to squash the commits.

Yes, it isn't but such kind of work flow was presented in the message I
replied to.

> The usual use case for a rebase is just to avoid the ugly merge
> commit.

Which devs should simply do whenever they use the scenario you
mentioned. I agree we could block 'auto-merges' when pushing to
a modified repo but not disallow a valid merges from devs who know what
they're doing.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Fri, Jun 1, 2012 at 12:05 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Yes, it isn't but such kind of work flow was presented in the message I
> replied to.

Yup, I wasn't aware that when rebasing you have the option to squash
commits or not.  They all get rewritten as if they were applied to the
current head in the first place, but apparently unless you squash them
you still get all the individual commits.

Rich

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

On Thu, May 31, 2012 at 03:58:43PM -0400, Rich Freeman wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > What would git signing work with rebased commits? Would all of them
> > have to be signed once again?
> >
> 
> The whole point of rebasing is to throw away history (which is either
> good or bad based on your perspective).
> 
> So, if 14 devs spend 3 years and 2000 commits working on something in
> a branch, and I commit it to master using a rebase, then all you'll
> see in the master history is that rich0 committed 20k lines of code to
> master on May 31st, and that would be signed by me.

You don't commit to master with a rebase,; it is always a merge. The
type of merge is what controls what you see in the logs.

If you rebase your branch on master, merge to master then run "git pull
--rebase" then push, you will get a fast forward merge, which shows the
individual commits.

If you don't include the rebasing, you get another type of merge which
just shows up in the logs as one commit afaik.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 07:58, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> What would git signing work with rebased commits? Would all of them
>> have to be signed once again?
>>
>
> The whole point of rebasing is to throw away history (which is either
> good or bad based on your perspective).
>
> So, if 14 devs spend 3 years and 2000 commits working on something in
> a branch, and I commit it to master using a rebase, then all you'll
> see in the master history is that rich0 committed 20k lines of code to
> master on May 31st, and that would be signed by me.
>
> I think that rebasing before merging is a pretty typical workflow
> anyway - when you submit a patch to Linus, he doesn't really care that
> you spent six months tweaking it - he just is getting a big blob of
> code that either works or doesn't.  Does all that sub-history really
> matter?  You could always push the branch to the repository if you
> wanted to keep it on the side.
>
> Rich
>

I think you're conflating "rebasing" and "squashing commits".

You should rebase a long commit sequence and squash pointless fixup
commits, and to make the commit sequence logical and ordered, possibly
divided by logical changes that one may wish to later revert. ( That
way, backing out a problem is simply reversing that commit and
applying the reversal patch )

You should not rebase for the purpose of squashing an entire history
of changes into a single scattered commit.

Rebasing is more to make the history itself linear and non-complex,
as when walking backwards through history, there being 2 parallel
histories that generated a merged commit can be confusing for humans,
so eliminating the parallel histories is one of the primary purposes I
advocate use of rebase for.

Squashed commits are a handy feature of rebase, but I wouldn't want to
see an entire overlay squashed into the main tree as a single squashed
commit.

Another bad reason for squashed commits: if you're getting rid of the
Changes files, you'll have no history on anything if you just group
long histories into a single commit. None.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Dirkjan Ochtman]

On Thu, May 31, 2012 at 6:49 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> Discussion on merge policy. Originally I thought we would disallow merge
> commits, so that we would get a cleaner history. However, it turns out that if
> the repo ends up being pushed to different places with slightly different
> histories, merges are absolutely going to be required to prevent somebody from
> having to rebase at least one of their sets of commits that are already pushed.

Can you elaborate on why the cleaner history a no-merge policy
enforces is a good thing? I actually think that seeing merge commits
might clarify the history; it can be valuable to see that some mistake
was made in a merge instead, but you can only see that if there's an
explicit merge commit.

I should note that I come at this from the Mercurial side, where the
immutability of (public) history has historically carried more value
than on the git side (and related to that, rebase-like tools were less
integrated until relatively recently).

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 20:16, Dirkjan Ochtman <djc@gentoo.org> wrote:
> Can you elaborate on why the cleaner history a no-merge policy
> enforces is a good thing? I actually think that seeing merge commits
> might clarify the history; it can be valuable to see that some mistake
> was made in a merge instead, but you can only see that if there's an
> explicit merge commit.
>
> I should note that I come at this from the Mercurial side, where the
> immutability of (public) history has historically carried more value
> than on the git side (and related to that, rebase-like tools were less
> integrated until relatively recently).
>
> Cheers,
>
> Dirkjan
>

One of the perk of fast-forward only histories is merge problems don't happen.

If a commit sequence isn't fast-fowardable, then the submitter has to
rebase it, and a rebased history is a guaranteed clean merge.

It also puts the onus on making the patch sequence mergable on the
contributor of that patch sequence, by forcing them to resolve
conflicts before they can submit their branch for inclusion, and this
is good, because they understand their own changes best, and are the
best person to decide how to deal with conflicts.

The best example of this is 2 people contribute behaviourally
identical code, with different syntax .

In the case of a merge, the person performing the merge has to decide
which one to take, and they might not be the best person to do so. (
And historically, it can be confusing if you look at the parents of
the merge, and find the 2 competing implementations, of which only 1
is relevant )

If you request that a branch is rebased before it is integrated, then
this problem solves itself in a way.

Whoevers implementation gets in the tree first gets in, and then the
second person rebases their branch on top of that.

In the process of performing the rebase, the second person will
discover the precise commit on their side that introduces a conflict,
and be able to decide if they need to replace the existing code
anyway, or if they need to destroy their own code.

And when they're done, their entire commit series should be sane and
logical as if the first persons code was there in the first place
before the second person even started coding.

a--->b--->c---->d--->e--->f
                |                      \|/
                \--->x--->y---->z

Essentially, in this diagram, if d and y are different, but
equivalent, they will cause a collision when merge Z is performed.

By performing a rebase of  the second branch, the logical order becomes

a--->b--->c---->d--->e--->f--->x--->y--->z

And when the rebaser is applying "y", they will notice it is likely
redundant, and the history will become

a--->b--->c---->d--->e--->f--->x--->z

And in both the merge and rebase examples, z will be the same, just
the cognitive overhead of understanding "what the hell happened" in
the latter case is simpler, as the biggest delta between any 2 commits
will be 1 commit worth, whereas in the merge case,  there will be a
huge delta  between the commit before the merge, and the commit after
the merge, and looking at the merge itself diff-wise, you'll be
comparing the aggregate result of 2 entire branches worth of commits,
as opposed to only comparing one small and simple commit with another.


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Tobias Klausmann]

Hi! 

On Wed, 30 May 2012, Rich Freeman wrote:
> On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> > Yeah... this is why I was asking about access to infra to test the
> > conversion; so far, I haven't had any replies, though.
> 
> A mock conversion would probably help with creating
> procedures/docs/etc as well.  It is nice to say that we're "just going
> to use git" but I think everybody has a slightly different picture of
> how that is going to work.

I recommend having a smallish set of willing alpha/beta testers for
this. This usually helps with some of the near-edge cases. You'll
still find a thousand other bugs once things go live for
everybody. Still, it turns a million into a thousand. It also
gives you slightly more realistic load test.

> If we could set up an "official unofficial" portage tree in git based
> on a one-time migration (maybe refreshing it from time to time) that
> could be a sandbox used to work things out, and it would then be
> replaced with the official tree.  When the official migration comes
> along we'd already be experts in doing it.

This is a good idea that goes nicely with what I wrote above.

> All we need to do is execute the migration, and just not point the
> rsync generation process at it.  Maybe it won't be perfectly right at
> first, and that would basically be the point of doing it.  Devs could
> update tools to work against it, and the docs could be written
> alongside.

The scientist in me wonders how big the dent in productivity
will be, actually. After all, there's going to be a lot of people
that will hammer the new setup just because of the New! Shiny!
appeal.

Regards,
Tobias

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/30/2012 12:53 PM, Tobias Klausmann wrote:
> Hi!
> 
> On Wed, 30 May 2012, Rich Freeman wrote:
>> On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman <djc@gentoo.org>
>> wrote:
>>> Yeah... this is why I was asking about access to infra to test
>>> the conversion; so far, I haven't had any replies, though.
>> 
>> A mock conversion would probably help with creating 
>> procedures/docs/etc as well.  It is nice to say that we're "just
>> going to use git" but I think everybody has a slightly different
>> picture of how that is going to work.
> 
> I recommend having a smallish set of willing alpha/beta testers
> for this. This usually helps with some of the near-edge cases.
> You'll still find a thousand other bugs once things go live for 
> everybody. Still, it turns a million into a thousand. It also gives
> you slightly more realistic load test. .... Regards, Tobias
> 

As one that's relatively new to Git, I'm a perfect candidate for
testing. If we go this way, I volunteer.

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/GUZkACgkQVxOqA9G7/aDxogEAjEsS6k0M9TejvCAoYISvuk1u
odo5ecLsyshwvwRlk3sA+wUeVAfGrafgH1gKpSrEedk1OT5x7HfsMquK0owq0/Np
=mzDU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Justin]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On 30.05.2012 18:58, Aaron W. Swenson wrote:
> On 05/30/2012 12:53 PM, Tobias Klausmann wrote:
>> Hi!
> 
>> On Wed, 30 May 2012, Rich Freeman wrote:
>>> On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman <djc@gentoo.org>
>>> wrote:
>>>> Yeah... this is why I was asking about access to infra to test
>>>> the conversion; so far, I haven't had any replies, though.
>>>
>>> A mock conversion would probably help with creating 
>>> procedures/docs/etc as well.  It is nice to say that we're "just
>>> going to use git" but I think everybody has a slightly different
>>> picture of how that is going to work.
> 
>> I recommend having a smallish set of willing alpha/beta testers
>> for this. This usually helps with some of the near-edge cases.
>> You'll still find a thousand other bugs once things go live for 
>> everybody. Still, it turns a million into a thousand. It also gives
>> you slightly more realistic load test. .... Regards, Tobias
> 
> 
> As one that's relatively new to Git, I'm a perfect candidate for
> testing. If we go this way, I volunteer.
> 
> - Aaron
> 

As I am a hater of CVS and my current checkout is repeatability spiting
weird errors, I would join as a tester here.

justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]