[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-scm-interest
Subject:    Re: [Kde-scm-interest] Accountability, concrete suggestion
From:       "Boyd Stephen Smith Jr." <bss () iguanasuicide ! net>
Date:       2009-01-15 1:15:22
Message-ID: 200901141915.27050.bss () iguanasuicide ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Disclaimer:
I'm not the best guy to be answering these questions.  I followed the list 
through the last posting of the notes feature, but I only scanned the 
patches an am not currently testing them myself.

On Wednesday 14 January 2009, Robert Wohlrab <robert.wohlrab@gmx.de> wrote 
about 'Re: [Kde-scm-interest] Accountability, concrete suggestion':
>Ok, compiled the next branch now and tried to work with it

If this is the only feature from next you want to try out, it might 
be "safer" to just checkout master, merge that particular branch, and 
compile that.

>It seems that this stuff is only useful on servers... see the next
> comments

Well, fetch/push just haven't been modified to manage the additional refs 
namespace automatically.  I'm not sure this is a really good idea either 
until gc/prune have the desired behavior -- should objects only reachable 
through a note be kept?

>On Thursday 15 January 2009 00:45:44 Boyd Stephen Smith Jr. wrote:
>> 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.

Yeah, I saw only a little noise about that.  It was pretty quickly decided 
that reusing the existing mechanisms in interesting ways was better.  
There was particular interest in shared and mergable notes.

Also, it seems that the current implementation may indeed limit notes to 
commits but if there is real need for adding notes to other objects it 
should be possible.

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

Most likely it's just that fetch/push haven't been modified to handle the 
refs/notes namespace.  ISTR that they currently only fetch/push 
refs/heads "normally" and then refs/tags specially.

I may get around to testing a version of git with notes enabled tonight, so 
I can try it out but, you might experiment with explicitly naming the 
notes refs are part of your fetch/push.  Something like:

git push $remote refs/notes/commits
# Create a new checkout, clone $remote then...
git fetch $remote refs/notes/commits
# See if notes show up correctly.

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

Well, anyone can post to the list, so you might ask there to see if someone 
has or can make a summary.  You might also CC Johannes Schindelin 
<Johannes.Schindelin@gmx.de> since the implementation that is in next is 
his patch set and he's Ack-ing all the patches thereon.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

["signature.asc" (application/pgp-signature)]

_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest


[prev in list] [next in list] [prev in thread] [next in thread]