On Sunday 10 June 2007, Johannes Schindelin wrote: > On Sun, 10 Jun 2007, Johan Herland wrote: > > On Sunday 10 June 2007, Junio C Hamano wrote: > Has my lightweight annotation patch reached you? > > I like my approach better than yours, because it is > > 1) a way, way smaller patch, and > 2) it automatically includes the versionability. I see your point, but your lightweight annotations are solving a different problem, aren't they? They do provide the after-the-fact annotations that sort of sparked of these discussions, but I can't see how your patch is a replacement of the general "relationships between arbitrary objects" concept that softrefs try to solve. Of course, it might be that the lightweight annotations are "good enough" for the use cases we currently see, and that softrefs are a bit overkill. We'll just have to see what features people (like Pierre) really need. > After thinking about it a little more (my plane was slow, and as a result > I am allowed to spend 8 more hours in Paris), I think that a small but > crucial change would make this thing even more useful: > > Instead of having "core.showAnnotations" be a boolean config, it might be > better to have "core.annotationsRef" instead, overrideable by the > environment variable GIT_ANNOTATION_REF. > > With this, you can have different refs for different kinds of annotations. > > For example, some people might add bugtracker comments (even comments like > "this commit was bad: introduced bug #798, solved by commit 9899fdadc.."). > Those comments could live in refs/annotations/bugs. To see them, just say > > GIT_ANNOTATION_REF=refs/annotations/bugs gitk > > Voila. Nice. Something similar should be possible to do with softrefs as well. > I am quite certain that treating annotations as branches, containing > fan-out directories for the reverse lookup. I am even quite certain that > in most cases, a working-directory-less merging is possible for such > annotations. I'm not convinced about the working-directory-less merging. AFAICS the lightweight annotations will behave pretty much like the "regular" version controlled filesystem, and you'll have the same kind of conflicts when you merge stuff between repos. I'd be glad to be proven wrong, of course. Have fun! ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
