git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Pierre Habouzit <madcoder@debian.org>
Subject: Re: Comment on weak refs
Date: Sun, 10 Jun 2007 15:41:44 +0200	[thread overview]
Message-ID: <200706101541.44362.johan@herland.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0706100716480.4059@racer.site>

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

  reply	other threads:[~2007-06-10 13:41 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-04  0:51 Refactoring the tag object; Introducing soft references (softrefs); Git 'notes' (take 2) Johan Herland
2007-06-04  0:51 ` [PATCH 0/6] Refactor the tag object Johan Herland
2007-06-04  0:52   ` [PATCH 1/6] Refactor git tag objects; make "tag" header optional; introduce new optional "keywords" header Johan Herland
2007-06-04  6:08     ` Matthias Lederhofer
2007-06-04  7:30       ` Johan Herland
2007-06-04  0:53   ` [PATCH 2/6] git-show: When showing tag objects with no tag name, show tag object's SHA1 instead of an empty string Johan Herland
2007-06-04  0:53   ` [PATCH 3/6] git-fsck: Do thorough verification of tag objects Johan Herland
2007-06-04  5:56     ` Matthias Lederhofer
2007-06-04  7:51       ` Johan Herland
2007-06-06  7:18         ` Junio C Hamano
2007-06-06  8:06           ` Johan Herland
2007-06-06  9:03             ` Junio C Hamano
2007-06-06  9:21               ` Junio C Hamano
2007-06-06 10:26                 ` Johan Herland
2007-06-06 10:35                   ` Junio C Hamano
2007-06-04  0:54   ` [PATCH 4/6] Documentation/git-mktag: Document the changes in tag object structure Johan Herland
2007-06-04  0:54   ` [PATCH 5/6] git-mktag tests: Fix and expand the mktag tests according to the new " Johan Herland
2007-06-04  0:54   ` [PATCH 6/6] Add fsck_verify_ref_to_tag_object() to verify that refname matches name stored in tag object Johan Herland
2007-06-04 20:32   ` [PATCH 0/6] Refactor the " Junio C Hamano
2007-06-07 22:13   ` [PATCH] Fix bug in tag parsing when thorough verification was in effect Johan Herland
2007-06-09 18:19 ` [PATCH 0/7] Introduce soft references (softrefs) Johan Herland
2007-06-09 18:21   ` [PATCH 1/7] Softrefs: Add softrefs header file with API documentation Johan Herland
2007-06-10  6:58     ` Johannes Schindelin
2007-06-10  7:43       ` Junio C Hamano
2007-06-10  7:54         ` Johannes Schindelin
2007-06-10 14:00       ` Johan Herland
2007-06-10 14:27     ` Jakub Narebski
2007-06-10 14:45       ` [PATCH] Teach git-gc to merge unsorted softrefs Johan Herland
2007-06-09 18:22   ` [PATCH 2/7] Softrefs: Add implementation of softrefs API Johan Herland
2007-06-09 18:22   ` [PATCH 3/7] Softrefs: Add git-softref, a builtin command for adding, listing and administering softrefs Johan Herland
2007-06-09 18:23   ` [PATCH 4/7] Softrefs: Add manual page documenting git-softref and softrefs subsystem in general Johan Herland
2007-06-09 18:23   ` [PATCH 5/7] Softrefs: Add testcases for basic softrefs behaviour Johan Herland
2007-06-09 18:24   ` [PATCH 6/7] Softrefs: Administrivia associated with softrefs subsystem and git-softref builtin Johan Herland
2007-06-09 18:24   ` [PATCH 7/7] Teach git-mktag to register softrefs for all tag objects Johan Herland
2007-06-09 18:25   ` [PATCH] Change softrefs file format from text (82 bytes per entry) to binary (40 bytes per entry) Johan Herland
2007-06-10  8:02     ` Johannes Schindelin
2007-06-10  8:30       ` Junio C Hamano
2007-06-10  9:46         ` Johannes Schindelin
2007-06-10 14:03       ` Johan Herland
2007-06-09 23:55   ` Comment on weak refs Junio C Hamano
2007-06-10  1:25     ` Johan Herland
2007-06-10  6:33       ` Johannes Schindelin
2007-06-10 13:41         ` Johan Herland [this message]
2007-06-10 14:09           ` Pierre Habouzit
2007-06-10 14:25             ` Pierre Habouzit
2007-06-10  9:03       ` Pierre Habouzit
2007-06-10 15:26     ` Jakub Narebski
2007-06-09 22:57 ` Refactoring the tag object; Introducing soft references (softrefs); Git 'notes' (take 2) Steven Grimm
2007-06-09 23:16   ` Johan Herland
2007-06-10  8:29     ` Pierre Habouzit
2007-06-10 14:31       ` Johan Herland
2007-06-10 19:42         ` Steven Grimm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200706101541.44362.johan@herland.net \
    --to=johan@herland.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=madcoder@debian.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).