[Kde-scm-interest] Accountability, concrete suggestion

[Robert Wohlrab]

Ok, compiled the next branch now and tried to work with it

On Thursday 15 January 2009 00:45:44 Boyd Stephen Smith Jr. wrote:
> It does need some more testing. :)
>
> >Just for clarification:
> >- We must write our own tool create annotations which signs the commits in
> >some way?
>
> Yes.  The notes stuff in git is generic, but it should be useful enough for
> our goals.
It seems that this stuff is only useful on servers... see the next comments

> >- a note is only a tag object which points to a commit and no else first
> > class git object (commit, tag, tree, blob) points to the note?
>
> Not exactly.  There is a "notes reference", which points to a commit
> object. The tree of this commit object is expected to use SHAs as
> filenames, and the notes are in the blobs attached to the tree.  The
> filename-SHAs indicate to which object the note applies.  (It could be a
> commit, tree, or blob [which might be another note!]).
Ok, I've read another design specification where it was designed to be a kind 
of tag. The new way sounds more logical to me.

> >- the only reference to the note is stored in refs/* or packed-refs (so it
> > is only referenced by a ref)?
>
> The notes themselves are stored as normal blobs.  That is, just like the
> tracked content of files.
>
> >- we will get an extrem big packed-refs when we really add a note to every
> >commit?
>
> Git's delta-compression should keep this down.  But, yes, the full text of
> every note AND it's history is stored.
Sounds fine to me and good.

[...]
>
> >- An update for a note will automatically downloaded by a pull?
>
> Not sure about this.  Since there is currently only one "notes ref", it's
> unlikely to be overwritten by pull in the default setup.
No, I wasnt able to pull or push anything from the notes ref. A clone also 
doesnt clone that ref. So it seems pretty useless when we try to check commits 
on the client side. For the server it wouldn't be a big problem to write into 
his notes when someone commits it and verify it on demand.

> >And can a commit have multiple notes?
>
> No, I don't believe so, but I could be wrong.
It can multiple lines but not multiple notes. It isnt a shared information so 
their mustn't be more then one note.

> >Is their a good design document with use cases available somewhere?
>
> Not that I know of, although the patches went through a lot of discussion
> on the git list.
Yes, to much to find the correct ones. Their were different ideas how to 
implement it and it is hard to know what were the results without reading 
everything.
-- 
Robert Wohlrab