Sean <seanlkml@xxxxxxxxxxxx> wrote: > On Fri, 19 May 2006 05:14:56 -0400 > Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > > > * [PATCH 5/5] Enable ref log creation in git checkout -b. > > > > Fix git checkout -b to behave like git branch. > > It seems that the ref log is a new way of tagging commits with some > extra meta data. Conceptually this seems very close to what git tags > already do. So... what about using regular git tags rather than > creating a ref log? All the regular git-rev-list tools could be > used to query the tags and prune would delete them automatically etc. It sort of is a new way of tagging commits with extra data. But its also sort of a way of versioning your ref `database'. Using tags to save the points in time might be useful but it would generate a lot of temporary files. A commit every 5 minutes for a typical working week would generate 480 tags per week. That's just too much. I was actually thinking this morning that another way to do this is to keep a metadata branch within the repository which records all of the refs in tree objects, then save the root commit under the special ref `LOG` in GIT_DIR. Every update to a logged ref would cause the tree to be updated and a new commit to be built. The branch would be a relatively simple string of pearls as its doubtful you would branch it. There are a number of downsides to this, not the least of which is I'd like to put a commit or tag SHA1 into the tree object rather than writing each ref as a blob (saves space). Currently commits and tags aren't permitted in a tree object so that would require some effort. But on the other hand you could pull (and track!) someone elses ref log through the standard GIT protocol. But this is starting to head down into the `bind commit` discussion; how do we record a number of commits as being related and tie them up into a single super commit? -- Shawn. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html