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

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

quoted

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