Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > On Mon, 22 May 2006, Junio C Hamano wrote: > > > * reflog > > > > I still haven't merged this series to "next" -- I do not have > > much against what the code does, but I am unconvinced if it is > > useful. Also objections raised on the list that this can be > > replaced by making sure that a repository that has hundreds of > > tags usable certainly have a point. > > I think it would make gitweb's summary view clearer, and Linus seemed > interested in being able to look up what happened in the fast forward > which was the first of several merges in a day. > > It could be replaced by a repository with hundreds of machine-readable > tags with code to parse dates into queries for suitable tags. But I don't > think there's an advantage to using the tag mechanism here, because you > never want to look the history up by exactly which history it is (the > thing that a tag ref is good for); you'll be looking for whatever reflog > item is the newest not after a specified time, where the specified time is > almost never a time that a reflog item was created. The thing is this might also be easily represented as a structure of tags; for example: refs/logs/heads/<ref>/<year>/<month>/<day> <hour>:<min>:<sec>:<seq> where the tag is a tag of the commit which was valid in that ref at that time. Searching for an entry "around a particular time" isn't that much more difficult than parsing a file, you just have to walk backwards through the sorted directory listings then read the tag object which matches; that tag object will point at the tree/commit/tag which is was in that ref.. What's ugly about this is simply the disk storage: a ref file is an expensive thing (relatively speaking) on most UNIX file systems due to the inode overhead. If this was stored in a more compact format (such as a GIT tree) then this would cost very little. So the alternative that I have been mentaly kicking around for the past two days is storing the GIT_DIR/refs directory within a standard GIT tree. This of course would need to be an option that gets enabled by the user as currently most tools expect the refs directory to actually be a directory, not a tree. The advantage here is that unlike proposed reflog it is a compact ref representation which could be used by other features, such as tagging a GIT commit with the unique name of the same change from another SCM. Or tagging your repository on every automated build, which runs once every 5 minutes. -- 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