Sorry for the noise, but I'm really pissed with git@vger recently. That mail I'm answering to, never made it to the list. Neither did my quite long answer to Martin, who kindly forwared it back to me so that I can send it again, sadly git@vger just does not wants mail, whereas its SMTP seems to accept mail: Jun 10 16:02:09 pan postfix/smtp[20560]: DE84FCAD9: to=<git@xxxxxxxxxxxxxxx>, relay=vger.kernel.org[209.132.176.167]:25, delay=4, delays=0.31/0.02/0.5/3.1, dsn=2.7.0, status=sent (250 2.7.0 nothing apparently wrong in the message. BF:<H 0.0800319>; S1754569AbXFJOCJ) I've sent a mail to postmaster@xxxxxxxxxxxxxxx a week ago, but it seems it remained a dead letter. Is anyone able to tell what's going wrong ? it's _really_ irritating, and let me want to give up discussions, as I _hate_ losing mail (I usually don't keep a copy of mails I send to a mail list as I expect it to send it back to me, and well, what would be a copy worth if nobody can read the mail anyway ?). So if anyone knows what can be done .... On Sun, Jun 10, 2007 at 03:41:44PM +0200, Johan Herland wrote: > 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 -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgppz2G5Tbtvm.pgp
Description: PGP signature
