On Mon, Apr 07, 2008 at 05:19:15PM -0400, Joey Hess wrote: > > and introduces a Key-Info: section to make it easier to find a changeset > > just by grepping. > Some overlap with d-m keycheck info, though I don't think I've ever > grepped that.
Opaque files just bother me.
> If you have a use case that involves grepping them all, wouldn't it be
> better (though perhaps not easy to implement) for jetring-accept to add
> the field, so it's consistently added to all changesets?
Hrm. We'd get that behaviour if jetring-accept worked something like:
jetring-build -I $KEYRING $DIR
jetring-review $KEYRING $CHANGESET >>$CHANGESET
jetring-accept $DIR $CHANGESET
I think.
> OTOH, jetring-accept will already suffix a changeset with
> .$x if necessary to make it unique.
Oh, that sounds sufficient then.
> > (I wonder a bit why we went with a signed index instead of having patches
> > applied in filename order, and all prefixed by a date.)
> Mostly, I think, so that it can be signed.
Hrm, we could equally well have just signed the output of
find $DIR -maxdepth 1 -mindepth 1 |
sed 's,^.*/,,' |
grep '^[a-zA-Z0-9-.]*$' |
sort
too, though the only thing that buys us is having the index implicit in
the directory.
Heh, maybe what we really should be doing is treating the changesets as a
linked list:
add-foo:
-----BEGIN PGP SIGNED MESSAGE-----
Action: import
Data:
blah
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
add-bar:
-----BEGIN PGP SIGNED MESSAGE-----
Previous-Changeset: add-foo
Action: import
Data:
blahblah
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----
LAST-CHANGESET
add-bar
then you have ordering implied by the changesets themselves, so you get
direct tracability for every changeset, and an authenticated ordering
just falls out.
Which means you don't have to sign two files when adding a changeset, and
you never have to reconstruct anything from the VCS history -- so rather than
having to find the commit that included the "add-evilcracker" changeset,
and then see who signed index.gpg, you just have too look at who signed
that changeset in the current tree.
Which is to say you could implement "jetring-blame" without having to
integrate it with a VCS.
Inserting at the end is trivial (add a new signed changeset, and update
LAST-CHANGESET), removing from the middle is easy-ish (replace the old
changeset with a new, empty one), and changing stuff in the middle is
possible but annoying, which seems entirely reasonable.
You don't strictly need LAST-CHANGESET, you could just do a tsort on all
the changesets, and check for:
loops (x Prev-Changeset: y, y Prev-Changeset: x)
branches (x Prev-Changeset: z, y Prev-Changeset: z)
multiple heads (nothing has Prev-Changeset: x _or_ Prev-Changeset: y)
Actually, that's trivial -- you just need to check:
- the number of files referenced as prev-changesets is
one less than the number of files you have
- no file is referenced twice
- all referenced files exist
FWIW, attached is something that'll take a directory of changesets
(".") and either die with an error if there's a problem, or print out
the order they should be applied in.
OTOH, for jetring-gen, you'd have to sign every changeset individually,
rather than just do one signature. Maybe in that case it'd make sense
to give it an option to dump a single changeset for all the updates
(though keeping additions/removals in distinct changesets, I guess).
Hrm, that might not be entirely as whacky as I first thought...
Cheers,
aj
signature.asc
Description: Digital signature
