--===============0778709672== Content-Type: multipart/signed; boundary="nextPart2493666.YOcDKWpc74"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2493666.YOcDKWpc74 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Disclaimer: I'm not the best guy to be answering these questions. I followed the list= =20 through the last posting of the notes feature, but I only scanned the=20 patches an am not currently testing them myself. On Wednesday 14 January 2009, Robert Wohlrab wrote= =20 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=20 be "safer" to just checkout master, merge that particular branch, and=20 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=20 namespace automatically. I'm not sure this is a really good idea either=20 until gc/prune have the desired behavior -- should objects only reachable=20 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= =20 that reusing the existing mechanisms in interesting ways was better. =20 There was particular interest in shared and mergable notes. Also, it seems that the current implementation may indeed limit notes to=20 commits but if there is real need for adding notes to other objects it=20 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=20 refs/notes namespace. ISTR that they currently only fetch/push=20 refs/heads "normally" and then refs/tags specially. I may get around to testing a version of git with notes enabled tonight, so= =20 I can try it out but, you might experiment with explicitly naming the=20 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= =20 has or can make a summary. You might also CC Johannes Schindelin=20 since the implementation that is in next is=20 his patch set and he's Ack-ing all the patches thereon. =2D-=20 Boyd Stephen Smith Jr. ,=3D ,-_-. =3D.=20 bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'=20 http://iguanasuicide.net/ \_/ =20 --nextPart2493666.YOcDKWpc74 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklujioACgkQ55pqL7G1QFlCtACdFnxaLY5I/vfKstr1GbBPzYpK ZdQAmwY+ymNcOc6w7nFTe0U6RSdsXk38 =GOyP -----END PGP SIGNATURE----- --nextPart2493666.YOcDKWpc74-- --===============0778709672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest --===============0778709672==--