There is git-notes... http://git-scm.com/docs/git-notes
but it seems a little complicated to manage... "Git notes are annotations for existing commits. They don’t change the history, so you are free to add notes to any existing commits. Your notes are stored only in your repo, but it’s possible to share notes. " http://mislav.net/2010/07/git-tips/ http://lists-archives.com/git/714256-git-notes-usage.html cheers -ben On Mon, Nov 30, 2015 at 2:41 PM, EuanM <euan...@gmail.com> wrote: > Does git not allow additional attribute objects that it benignly > stores and ignores? (I suspect I can guess the answer, but...) > > On 30 November 2015 at 05:55, Thierry Goubier <thierry.goub...@gmail.com> > wrote: >> >> Le 30 nov. 2015 5:24 AM, "EuanM" <euan...@gmail.com> a écrit : >>> >>> Is there anything stopping us adding one more dictionary to each >>> Monticello commit? >>> >>> A key of commit ids and values of author name? >> >> This dictionary is already there in the version metadata... The file that >> generates conflicts in git. >> >> Thierry >> >>> On 24 November 2015 at 06:55, stepharo <steph...@free.fr> wrote: >>> > +1 >>> > >>> > And so far Monticello is much better that having delta because you can >>> > still >>> > get a complete project without having to reconstruct the complete >>> > snapshot from deltas. I could not imagine the amount of code we would >>> > have >>> > lost else. >>> > Veronica in her PhD built a crawler that reconstructs all the deltas >>> > based >>> > on MC files. Now this is work. >>> > Stef >>> > >>> > Le 23/11/15 17:02, Nicolas Cellier a écrit : >>> > >>> > It's not Monticello per se. It's the backend (the server) which is too >>> > naive. >>> > The .mcz must be considered as a unit of exchange between the server >>> > (the >>> > repository) and the client (the working copy). And please note that in >>> > Monticello, it's not the only way to exchange data, it can also be a >>> > .mcd (a >>> > diff). >>> > >>> > Nothing forces the server to store the .mcz as is. That's just a naive >>> > implementation. Chris Muller demonstrated how to use a database (magma) >>> > as >>> > backend... >>> > >>> > 2015-11-23 12:12 GMT+01:00 Marcus Denker <marcus.den...@inria.fr>: >>> >> >>> >> >>> >> > On 22 Nov 2015, at 20:12, EuanM <euan...@gmail.com> wrote: >>> >> > >>> >> > Is there any reason against amending Monticello to store and save all >>> >> > author's names? >>> >> >>> >> It does. *If* you have all the versions… but doing anything with “all >>> >> the >>> >> versions” >>> >> is so slow (you need to download them, unpack them…) that we do not >>> >> even >>> >> have >>> >> a tool to show the history of a method. >>> >> (getting the oldest should be simpler, if you have complete >>> >> history+this >>> >> .mcz is >>> >> there). >>> >> >>> >> Monticello is meant to be a system to save the complete history of a >>> >> project >>> >> (if you keep all the MCZ available), but the idea to save every tiny >>> >> revision as >>> >> a complete snapshot, zip compresses, makes it near impossible to do >>> >> anything >>> >> with the history in practice. >>> >> >>> >> With today disks, a practical SCM would allow anyone to have the >>> >> *complete* >>> >> history on the local disk. Monticello does now allow that in any >>> >> practical >>> >> way. >>> >> >>> >> > >>> >> > Presumably, we'd also want a tool that could extract amnders' names >>> >> > all the way back to the first commit of a package? >>> >> > >>> >> > How many on-line Monticello repositories are in common use? >>> >> > >>> >> > (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) >>> >> > >>> >> > Are there active administrators for each of those repositories that >>> >> > would allow us to update the repositories to use the updated >>> >> > Monticello? >>> >> > >>> >> > On 22 November 2015 at 15:42, Marcus Denker <marcus.den...@inria.fr> >>> >> > wrote: >>> >> >> >>> >> >> On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisi...@gmail.com> >>> >> >> wrote: >>> >> >> >>> >> >> >>> >> >> 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.den...@inria.fr>: >>> >> >>> >>> >> >>> epicea data is not stored forever. It is seasion based and the >>> >> >>> shipped >>> >> >>> image is >>> >> >>> clean. >>> >> >> >>> >> >> >>> >> >> But current source of this info is changes file (maybe sources). And >>> >> >> I >>> >> >> remember you planned to store current sources in image. And such >>> >> >> information >>> >> >> can be there too. >>> >> >> Maybe I miss something? >>> >> >> >>> >> >> >>> >> >> The original author is not really that much of information. And >>> >> >> storing >>> >> >> it >>> >> >> for every method in the image would take space. >>> >> >> >>> >> >> As I said: the whole idea of using a source revision control system >>> >> >> is >>> >> >> that >>> >> >> you have the *complete* history available, but >>> >> >> not wasting RAM. >>> >> >> >>> >> >> Marcus >>> >> > >>> >> >>> >> >>> > >>> > >>> >
