Re: Weird shallow-tree conversion state, and branches of shallow trees

From: Robin H. Johnson <robbat2@gentoo.org>
Date: Apr 15, 2007, 09:44 UTC
Message-ID: <20070415094438.GD2689@curie-int.orbis-terrarum.net>
In-Reply-To: <20070415043146.GB2229@spearce.org>

On Sun, Apr 15, 2007 at 12:31:46AM -0400, Shawn O. Pearce wrote:

> Mail them a DVD of the Git import, have them load it locally,
> and use --reference for all future clones.  With Git its possible
> to build fast throwaway trees from any random URL, so long as you
> keep at least one repository available locally to act as a reference.

Ok, that makes it even more worthwhile for them to keep one tree locally, I didn't think of that :-).

Show 13 quoted lines

> > the commit is accepted. The 'update' hook documentation suggests that
> > ACLs should be possible and implemented via that.
> Yes.  I run probably the most paranoid update hook in existance.
> If you want a copy let me know, I'll send it to you.  Its a Perl
> script that verifies the 'committer ' line matches the UNIX uid (by
> doing a table lookup) for every new commit or tag being introduced
> to the repository.  It also verifies that the user can update that
> branch, create it, delete it, or rewind it.
> 
> It sounds like you would need to add some additional rules about
> specific paths being modified only by certain people in certain
> branches (for the SELinux stuff), and running other validations in
> the documentation (whatever that is).

Yes please, it would be greatly appreciated. I'll hack path ACLs into it, and feed it back to contrib/? (CVS and SVN ship ACL stuff in their contrib/, so we could probably follow suite safely).

> What you could do is create a program that mangles the files before
> delivery.  You would probably want to do something like:
> 
>   $Id: 7fbf239:path/to/file$

There's one core problem with mangled after the fact there:
It's going to break checksum/gpg verification later.
Here's the existing CVS process as a comparison.
1. Developer creates/changes foo-1.2.ebuild. (cvs add, but not cvs ci).
2. Runs the local verify+commit tool (repoman).
(these steps are done by repoman now)
3. Generates the initial Manifest (contains SHA256/MD5/RIPEMD160 etc.).
4. Commits the initial Manifest AND the files from the developer.
5. Gegenerated Manifest because of any keywords in the files.
6. Manifest is clear-signed with gpg.
7. Signed Manifest is committed.

We can't require the re-processing of the files before they can be verified, as that removes the ability for users to easily verify them with standard tools (md5sum,sha256sum).

The direct conversion of such a process to insert the $Id$ and then re-commit that $Id$ runs into chicken-and-egg problems as well, so either git needs to insert the keyword, or the file can't be changed.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85