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@vger.kernel.org>, 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@vger.kernel.org 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:
Show 58 quoted lines
> 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@herland.net>
> www.herland.net
Pierre Habouzit <madcoder@debian.org>