{"thread":{"id":"4206","subject":"[PATCH 0/5] More ref logging","startedAt":"2006-05-19T09:14:56Z","lastAt":"2006-05-21T05:09:44Z","messageCount":6,"participants":["Shawn Pearce","Sean"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"20280","messageId":"20060519091456.GH22257@spearce.org","threadId":"4206","inReplyTo":null,"subject":"[PATCH 0/5] More ref logging","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-19T09:14:56Z","receivedAt":"2006-05-19T09:14:56Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"These are on top of the other five I just sent:\n\n* [PATCH 1/5] Correct force_write bug in refs.c\n\n\tYea there was a bug in the last bug fix. Now we\n\treally don't write the ref unless we need to.\n\n* [PATCH 2/5] Change order of -m option to update-ref.\n\n\tMinor documentation nit noticed by Junio.\n\n* [PATCH 3/5] Include ref log detail in commit, reset, etc.\n\n\tEnhance some core tools to use the new '-m' switch with\n\tupdate-ref. Trivial but requires the new update-ref.\n\n* [PATCH 4/5] Create/delete branch ref logs.\n\n\tThis was discussed on #git earlier this morning.\n\tAutomatically create the ref log if -l is given when creating\n\ta branch and delete the log when deleting the branch.\n\n* [PATCH 5/5] Enable ref log creation in git checkout -b.\n\n\tFix git checkout -b to behave like git branch.\n\n-- \nShawn.\n"},{"id":"20289","messageId":"BAYC1-PASMTP04D6ED73408969450597A9AEA70@CEZ.ICE","threadId":"4206","inReplyTo":"20060519091456.GH22257@spearce.org","subject":"Re: [PATCH 0/5] More ref logging","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-19T11:16:03Z","receivedAt":"2006-05-19T11:16:03Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 19 May 2006 05:14:56 -0400\nShawn Pearce wrote:\n\n> * [PATCH 5/5] Enable ref log creation in git checkout -b.\n> \n> \tFix git checkout -b to behave like git branch.\n\nIt seems that the ref log is a new way of tagging commits with some\nextra meta data. Conceptually this seems very close to what git tags \nalready do. So... what about using regular git tags rather than\ncreating a ref log? All the regular git-rev-list tools could be\nused to query the tags and prune would delete them automatically etc.\n\nJust a thought, feel free to ignore it :o)\n\nSean\n"},{"id":"20356","messageId":"20060521005009.GA7179@spearce.org","threadId":"4206","inReplyTo":"20060519071603.11d3be5d.seanlkml@sympatico.ca","subject":"Re: [PATCH 0/5] More ref logging","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-21T00:50:09Z","receivedAt":"2006-05-21T00:50:09Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean wrote:\n> On Fri, 19 May 2006 05:14:56 -0400\n> Shawn Pearce wrote:\n> \n> > * [PATCH 5/5] Enable ref log creation in git checkout -b.\n> > \n> > \tFix git checkout -b to behave like git branch.\n> \n> It seems that the ref log is a new way of tagging commits with some\n> extra meta data. Conceptually this seems very close to what git tags \n> already do. So... what about using regular git tags rather than\n> creating a ref log? All the regular git-rev-list tools could be\n> used to query the tags and prune would delete them automatically etc.\n\nIt sort of is a new way of tagging commits with extra data. But its\nalso sort of a way of versioning your ref `database'. Using tags\nto save the points in time might be useful but it would generate\na lot of temporary files. A commit every 5 minutes for a typical\nworking week would generate 480 tags per week. That's just too much.\n\nI was actually thinking this morning that another way to do this\nis to keep a metadata branch within the repository which records\nall of the refs in tree objects, then save the root commit under\nthe special ref `LOG` in GIT_DIR. Every update to a logged ref\nwould cause the tree to be updated and a new commit to be built.\nThe branch would be a relatively simple string of pearls as its\ndoubtful you would branch it.\n\nThere are a number of downsides to this, not the least of which is\nI'd like to put a commit or tag SHA1 into the tree object rather than\nwriting each ref as a blob (saves space). Currently commits and tags\naren't permitted in a tree object so that would require some effort.\nBut on the other hand you could pull (and track!) someone elses\nref log through the standard GIT protocol.\n\nBut this is starting to head down into the `bind commit` discussion;\nhow do we record a number of commits as being related and tie them\nup into a single super commit?\n\n-- \nShawn.\n"},{"id":"20371","messageId":"BAYC1-PASMTP1190ADCE746F3E0BEEC69BAEA50@CEZ.ICE","threadId":"4206","inReplyTo":"20060521005009.GA7179@spearce.org","subject":"Re: [PATCH 0/5] More ref logging","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-21T02:43:44Z","receivedAt":"2006-05-21T02:43:44Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sat, 20 May 2006 20:50:09 -0400\nShawn Pearce wrote:\n\n> It sort of is a new way of tagging commits with extra data. But its\n> also sort of a way of versioning your ref `database'. Using tags\n> to save the points in time might be useful but it would generate\n> a lot of temporary files. A commit every 5 minutes for a typical\n> working week would generate 480 tags per week. That's just too much.\n\nBut isn't that just an implementation detail? I've actually run\ninto another situation where tags would be perfect if only they weren't\nso expensive (ie. entire repo was in a 50Mb pack including tag objects,\nbut the .git/refs/tags directory was over 100Mb).\n\nSo, if we found a way to store tags more efficiently your 480 tags per\nweek shouldn't be a problem at all. The main point being to extend\nand optimize the existing infrastructure rather than bolting on a new\nclass of objects (ie. ref log) which only serves a narrow (albeit\nimportant) purpose.\n \n> I was actually thinking this morning that another way to do this\n> is to keep a metadata branch within the repository which records\n> all of the refs in tree objects, then save the root commit under\n> the special ref `LOG` in GIT_DIR. Every update to a logged ref\n> would cause the tree to be updated and a new commit to be built.\n> The branch would be a relatively simple string of pearls as its\n> doubtful you would branch it.\n>\n> There are a number of downsides to this, not the least of which is\n> I'd like to put a commit or tag SHA1 into the tree object rather than\n> writing each ref as a blob (saves space). Currently commits and tags\n> aren't permitted in a tree object so that would require some effort.\n> But on the other hand you could pull (and track!) someone elses\n> ref log through the standard GIT protocol.\n \nYes, Linus proposed something similar earlier to hold meta data.\nBut i've come to see tags as a place to store any arbitrary meta\ndata associated with a commit. If their implementation was more\nefficient you could use them for your project and they could be used\nfor any number of other purposes as well.\n\n> But this is starting to head down into the `bind commit` discussion;\n> how do we record a number of commits as being related and tie them\n> up into a single super commit?\n\nWell, a tag that allowed the listing of multiple heads....\n\nSean\n"},{"id":"20373","messageId":"20060521045146.GA8269@spearce.org","threadId":"4206","inReplyTo":"20060520224344.7ebca48b.seanlkml@sympatico.ca","subject":"Re: [PATCH 0/5] More ref logging","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-21T04:51:46Z","receivedAt":"2006-05-21T04:51:46Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean wrote:\n> On Sat, 20 May 2006 20:50:09 -0400\n> Shawn Pearce wrote:\n> \n> > It sort of is a new way of tagging commits with extra data. But its\n> > also sort of a way of versioning your ref `database'. Using tags\n> > to save the points in time might be useful but it would generate\n> > a lot of temporary files. A commit every 5 minutes for a typical\n> > working week would generate 480 tags per week. That's just too much.\n> \n> But isn't that just an implementation detail? I've actually run\n> into another situation where tags would be perfect if only they weren't\n> so expensive (ie. entire repo was in a 50Mb pack including tag objects,\n> but the .git/refs/tags directory was over 100Mb).\n\nAny chance we could get some details on why so many tags were useful?\nYou have a good argument here but I'm not sure how a better tag\nstore could be structured. :-)\n \n> So, if we found a way to store tags more efficiently your 480 tags per\n> week shouldn't be a problem at all. The main point being to extend\n> and optimize the existing infrastructure rather than bolting on a new\n> class of objects (ie. ref log) which only serves a narrow (albeit\n> important) purpose.\n\nYea - despite being the author of ref log I'm still slightly unhappy\nwith the fact that it doesn't make reuse of existing GIT plumbing.\nBut I'm sort of OK with that right now as you can't map two indexes\ninto memory at once currently, nor is there a way to easily update\nmultiple refs at once if the ref log must serialize access to create\na string of trees and commits.\n\n-- \nShawn.\n"},{"id":"20374","messageId":"BAYC1-PASMTP110591AAE415FBD1523110AEA50@CEZ.ICE","threadId":"4206","inReplyTo":"20060521045146.GA8269@spearce.org","subject":"Re: [PATCH 0/5] More ref logging","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-21T05:09:44Z","receivedAt":"2006-05-21T05:09:44Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 21 May 2006 00:51:46 -0400\nShawn Pearce wrote:\n\n> Any chance we could get some details on why so many tags were useful?\n> You have a good argument here but I'm not sure how a better tag\n> store could be structured. :-)\n\nIt is a conversion from another SCM. So every one of the ~16K commits\nwas tagged with the reference number taken from the original SCM. This\nhas some very nice benefits in that you can refer to every commit\nin git by the original changeset #. For example, if someone reports a\nbug mentioning the original scm's reference id, you can say something\nlike: \"git show p4/1234\" without having to go back to the old scm.\n\nAlso, qgit, gitk and gitweb display them nicely which can be helpful\nduring the conversion. And if/when they're not needed any longer,\nyou just delete them without having to rewrite the history etc.. \n \n> Yea - despite being the author of ref log I'm still slightly unhappy\n> with the fact that it doesn't make reuse of existing GIT plumbing.\n> But I'm sort of OK with that right now as you can't map two indexes\n> into memory at once currently, nor is there a way to easily update\n> multiple refs at once if the ref log must serialize access to create\n> a string of trees and commits.\n\nWell it's not the end of the world either way, and sometimes it's just\nbetter to implement a workable solution rather than wait for one that's\ntheoretically cleaner. It just seemed like it was worth mentioning in\ncase you saw a way to make it happen without a lot of grief.\n\nSean\n"}]}