linux@xxxxxxxxxxx writes:
>> Ideally we would have two sha1 values in the cache - the sha1 in the
>> file, and if that is the ID of a tag object, we would also put the
>> sha1 of the commit that the tag points to in the cache.
>
> Now that's not a bad idea. Hacking it in to Linus's scheme, that's
>
> <foo sha>\t<foo^{} sha>\tfoo
That's a dubious idea.
- Why assume a tag points directly at a commit, or if it is
not, why assume "foo^{}" (dereferencing repeatedly until we
get a non-tag) is special?
- Why assume the user wants access to only the object name of
what the tag points at? Perhaps most users would want to
have its type, dates (committer and author), and probably the
first line of the commit message if it is (and most likely it
is) a commit? -- at least gitweb and gitk would want these.
You should separate the issue of the internal data structure
implementation and programming interface for Porcelains. From
the internal data structure point-of-view, the second one is a
redundant piece of information. Caching it _would_ speed up the
access to it, but then the issue becomes where we draw the line
to stop.
It is probably more useful to think about what kind of
information formatted in what way is often wanted by Porcelains
who want to grab many refs in one-go. If you can come up with a
set that can satisfy everybody using that as the cache file
format would be fine, but I strongly doubt you can satisfy
everybody. In which case, thinking about the ways for the
Porcelain to express flexibly what information is wanted and
formatted in what way, and have a command to access that
(git-show-refs, anybody?) would be more fruitful, and at that
point, the internal representation of the cached data becomes
the implementation detail.
-
To unsubscribe from this list: 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