threads / patch / 8531

patchIntroduce light weight commit annotations

Subject: [PATCH] Introduce light weight commit annotations

## tl;dr

18 messages between Jun 9, 2007 and Jun 12, 2007. Diffs are folded; open one to read it.

replies: 17people: 5as markdown or json

Johannes Schindelin· Jun 9, 2007, 17:55 UTC · lore

With the provided script, edit-commit-annotations, you can add after-the-fact annotations to commits, which will be shown by the log if the config variable core.showannotations is set.

The annotations are tracked in a new ref, refs/annotations/commits, in the same fan-out style as .git/objects/??/*, only that they only exist in the object database now.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	I have the hunch that this will be relatively fast and scalable,
	since the tree objects are sorted by name (the name being the
	object name of the to-be-annotated commit).
	I'm on the run for 15 hours now, but please feel free to discuss
	and / or trash it while I'm away.
 cache.h                       |    1 +
 commit.c                      |   48 ++++++++++++++++++++++++++++++++++++++++-
 config.c                      |    5 ++++
 environment.c                 |    1 +
 git-edit-commit-annotation.sh |   46 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 100 insertions(+), 1 deletions(-)
 create mode 100755 git-edit-commit-annotation.sh
Show changes to 5 files +100 −1

cache.h, commit.c, config.c, environment.c, git-edit-commit-annotation.sh

diff --git a/cache.h b/cache.h
index bc6b8e8..4166888 100644
--- a/cache.h
+++ b/cache.h
@@ -288,6 +288,7 @@ extern size_t packed_git_window_size;
 extern size_t packed_git_limit;
 extern size_t delta_base_cache_limit;
 extern int auto_crlf;
+extern int show_commit_annotations;
 
 #define GIT_REPO_VERSION 0
 extern int repository_format_version;
diff --git a/commit.c b/commit.c
index 4ca4d44..409ebc8 100644
--- a/commit.c
+++ b/commit.c
@@ -911,6 +911,48 @@ static long format_commit_message(const struct commit *commit,
 	return strlen(buf);
 }
 
+static unsigned long show_annotations(const struct commit *commit,
+		char *buf, unsigned long space)
+{
+	char name[80];
+	const char *hex = sha1_to_hex(commit->object.sha1);
+	unsigned char sha1[20];
+	char *msg;
+	unsigned long offset = 0, msgoffset = 0, msglen;
+	enum object_type type;
+
+	snprintf(name, sizeof(name),
+			"refs/annotations/commits:%.*s/%.*s",
+			2, hex, 38, hex + 2);
+	if (get_sha1(name, sha1))
+		return 0;
+
+	if (!(msg = read_sha1_file(sha1, &type, &msglen)) || !msglen)
+		return 0;
+	/* we will end the annotation by a newline anyway. */
+	if (msg[msglen - 1] == '\n')
+		msglen--;
+
+	offset += snprintf(buf + offset, space - offset - 1,
+			"\nAnnotation:\n");
+
+	for (msgoffset = 0; msgoffset < msglen;) {
+		int linelen = get_one_line(msg + msgoffset, msglen);
+
+		offset += snprintf(buf + offset, space - offset - 1,
+			"    %.*s", linelen, msg + msgoffset);
+
+		if (offset + 1 >= space)
+			break;
+
+		msgoffset += linelen;
+	}
+	buf[offset++] = '\n';
+	free(msg);
+
+	return offset;
+}
+
 unsigned long pretty_print_commit(enum cmit_fmt fmt,
 				  const struct commit *commit,
 				  unsigned long len,
@@ -1098,8 +1140,12 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
 	 */
 	if (fmt == CMIT_FMT_EMAIL && !body)
 		buf[offset++] = '\n';
-	buf[offset] = '\0';
 
+	if (fmt != CMIT_FMT_ONELINE && show_commit_annotations)
+		offset += show_annotations(commit,
+				buf + offset, space - offset);
+
+	buf[offset] = '\0';
 	free(reencoded);
 	return offset;
 }
diff --git a/config.c b/config.c
index 58d3ed5..34db9b2 100644
--- a/config.c
+++ b/config.c
@@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)
 		return 0;
 	}
 
+	if (!strcmp(var, "core.showannotaions")) {
+		show_commit_annotations = git_config_bool(var, value);
+		return 0;
+	}
+
 	if (!strcmp(var, "user.name")) {
 		strlcpy(git_default_name, value, sizeof(git_default_name));
 		return 0;
diff --git a/environment.c b/environment.c
index 8b9b89d..c649f19 100644
--- a/environment.c
+++ b/environment.c
@@ -32,6 +32,7 @@ size_t delta_base_cache_limit = 16 * 1024 * 1024;
 int pager_in_use;
 int pager_use_color = 1;
 int auto_crlf = 0;	/* 1: both ways, -1: only when adding git objects */
+int show_commit_annotations;
 
 static const char *git_dir;
 static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
diff --git a/git-edit-commit-annotation.sh b/git-edit-commit-annotation.sh
new file mode 100755
index 0000000..2abcd34
--- /dev/null
+++ b/git-edit-commit-annotation.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+USAGE="[commit-name]"
+. git-sh-setup
+
+test -n "$2" && usage
+COMMIT=$(git rev-parse --verify --default HEAD "$@")
+NAME=$(echo $COMMIT | sed "s/^../&\//")
+
+MESSAGE="$GIT_DIR"/COMMIT_ANNOTATION.$$
+git log -1 $COMMIT | sed "s/^/#/" > "$MESSAGE"
+
+GIT_INDEX_FILE="$MESSAGE".idx
+export GIT_INDEX_FILE
+
+TIPNAME=refs/annotations/commits
+OLDTIP=$(git show-ref $TIPNAME | cut -f 1 -d ' ')
+if [ -z "$OLDTIP" ]; then
+	OLDTIP=0000000000000000000000000000000000000000
+else
+	PARENT="-p $OLDTIP"
+	git read-tree $TIPNAME || die "Could not read index"
+	git cat-file blob :$NAME >> "$MESSAGE" 2> /dev/null
+fi
+
+${VISUAL:-${EDITOR:-vi}} "$MESSAGE"
+
+grep -v ^# < "$MESSAGE" | git stripspace > "$MESSAGE".processed
+mv "$MESSAGE".processed "$MESSAGE"
+if [ -z "$(cat "$MESSAGE")" ]; then
+	case $OLDTIP in 0000000000000000000000000000000000000000)
+		echo "Will not initialise with empty tree"
+		exit 1
+	esac
+	git update-index --force-remove $NAME ||
+		die "Could not update index"
+else
+	BLOB=$(git hash-object -w "$MESSAGE") ||
+		die "Could not write into object database"
+	git update-index --add --cacheinfo 0644 $BLOB $NAME ||
+		die "Could not write index"
+fi
+
+TREE=$(git write-tree) || die "Could not write tree"
+NEWTIP=$(date | git commit-tree $TREE $PARENT) || die "Could not annotate"
+git update-ref $TIPNAME $NEWTIP $OLDTIP
-- 
1.5.2.1.2713.gbb6a-dirty
Johan Herland· Jun 10, 2007, 13:14 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

On Saturday 09 June 2007, Johannes Schindelin wrote:
Show 7 quoted lines
> With the provided script, edit-commit-annotations, you can add
> after-the-fact annotations to commits, which will be shown by
> the log if the config variable core.showannotations is set.
> 
> The annotations are tracked in a new ref, refs/annotations/commits,
> in the same fan-out style as .git/objects/??/*, only that they only
> exist in the object database now.

Very interesting. I have to say that after having played around with it a couple of minutes, I really like it. Needs some polishing here and there (i.e. cleaning up the COMMIT_ANNOTATION.NNNN* files), but it is a very good proof-of-concept.

> 	I have the hunch that this will be relatively fast and scalable,
> 	since the tree objects are sorted by name (the name being the
> 	object name of the to-be-annotated commit).

I think I agree with your hunch, although I initially thought that your solution was a bit heavy on the number of objects created. But, hey, git is _designed_ to handle massive amounts of objects. :)

Show 13 quoted lines
> diff --git a/config.c b/config.c
> index 58d3ed5..34db9b2 100644
> --- a/config.c
> +++ b/config.c
> @@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)
>  		return 0;
>  	}
>  
> +	if (!strcmp(var, "core.showannotaions")) {
> +		show_commit_annotations = git_config_bool(var, value);
> +		return 0;
> +	}
> +

Small typo here. "core.showannotaions" should be "core.showannotations", I guess.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Johannes Schindelin· Jun 10, 2007, 18:56 UTC · re: Johan Herland · lore

Re: [PATCH] Introduce light weight commit annotations

Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
Show 14 quoted lines
> On Saturday 09 June 2007, Johannes Schindelin wrote:
>
> > With the provided script, edit-commit-annotations, you can add 
> > after-the-fact annotations to commits, which will be shown by the log 
> > if the config variable core.showannotations is set.
> > 
> > The annotations are tracked in a new ref, refs/annotations/commits, in 
> > the same fan-out style as .git/objects/??/*, only that they only exist 
> > in the object database now.
> 
> Very interesting. I have to say that after having played around with
> it a couple of minutes, I really like it. Needs some polishing here
> and there (i.e. cleaning up the COMMIT_ANNOTATION.NNNN* files), but
> it is a very good proof-of-concept.

Thanks. I composed it in a hurry, since I wanted it to go out before I took my flight home.

Show 7 quoted lines
> > 	I have the hunch that this will be relatively fast and scalable,
> > 	since the tree objects are sorted by name (the name being the
> > 	object name of the to-be-annotated commit).
> 
> I think I agree with your hunch, although I initially thought that your
> solution was a bit heavy on the number of objects created. But, hey, git
> is _designed_ to handle massive amounts of objects. :)

Besides, these tree objects should delta really well, being almost as efficient as having only one tree object to begin with.

Show 16 quoted lines
> > diff --git a/config.c b/config.c
> > index 58d3ed5..34db9b2 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)
> >  		return 0;
> >  	}
> >  
> > +	if (!strcmp(var, "core.showannotaions")) {
> > +		show_commit_annotations = git_config_bool(var, value);
> > +		return 0;
> > +	}
> > +
> 
> Small typo here. "core.showannotaions" should be "core.showannotations",
> I guess.

Yep. I tested it with "core.shownotes", but decided before sending the patch that the name would be inconsistent with the rest of the code.

However, as I suggested later, I could imagine that an even better way could be to have "core.annotationsRef", overrideable by GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.

BTW I am not married to calling it "annotations". If you like "notes" better, I'm fine with it.

Ciao, Dscho

Johan Herland· Jun 10, 2007, 19:20 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

On Sunday 10 June 2007, Johannes Schindelin wrote:
Show 13 quoted lines
> On Sun, 10 Jun 2007, Johan Herland wrote:
> > Small typo here. "core.showannotaions" should be "core.showannotations",
> > I guess.
> 
> Yep. I tested it with "core.shownotes", but decided before sending the 
> patch that the name would be inconsistent with the rest of the code.
> 
> However, as I suggested later, I could imagine that an even better way 
> could be to have "core.annotationsRef", overrideable by 
> GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.
> 
> BTW I am not married to calling it "annotations". If you like "notes" 
> better, I'm fine with it.

No problem. Actually I really wanted to call my first proof-of-concept "annotations", and not "notes", but I figured it would be confused with the "annotate-as-in-blame" concept. Besides there is already a git-annotate command...

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Johannes Schindelin· Jun 10, 2007, 19:53 UTC · re: Johan Herland · lore

Re: [PATCH] Introduce light weight commit annotations

Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
Show 19 quoted lines
> On Sunday 10 June 2007, Johannes Schindelin wrote:
> > On Sun, 10 Jun 2007, Johan Herland wrote:
> > > Small typo here. "core.showannotaions" should be "core.showannotations",
> > > I guess.
> > 
> > Yep. I tested it with "core.shownotes", but decided before sending the 
> > patch that the name would be inconsistent with the rest of the code.
> > 
> > However, as I suggested later, I could imagine that an even better way 
> > could be to have "core.annotationsRef", overrideable by 
> > GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.
> > 
> > BTW I am not married to calling it "annotations". If you like "notes" 
> > better, I'm fine with it.
> 
> No problem. Actually I really wanted to call my first
> proof-of-concept "annotations", and not "notes", but I
> figured it would be confused with the "annotate-as-in-blame"
> concept. Besides there is already a git-annotate command...
Not to forget that note is shorter to type.

Ciao, Dscho

Junio C Hamano· Jun 10, 2007, 22:11 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 14 quoted lines
> With the provided script, edit-commit-annotations, you can add
> after-the-fact annotations to commits, which will be shown by
> the log if the config variable core.showannotations is set.
>
> The annotations are tracked in a new ref, refs/annotations/commits,
> in the same fan-out style as .git/objects/??/*, only that they only
> exist in the object database now.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> 	I have the hunch that this will be relatively fast and scalable,
> 	since the tree objects are sorted by name (the name being the
> 	object name of the to-be-annotated commit).

The entries of tree are sorted but not necessarily of uniform length so you end up needing linear search anyway. The fan-out would help with the current tree objects.

It will hurt _if_ we introduce a new tree object format that would give you a quick random-access at an entry, but it is premature to worry about that now.

Johannes Schindelin· Jun 10, 2007, 23:00 UTC · re: Junio C Hamano · lore

Re: [PATCH] Introduce light weight commit annotations

Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
Show 20 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > With the provided script, edit-commit-annotations, you can add
> > after-the-fact annotations to commits, which will be shown by
> > the log if the config variable core.showannotations is set.
> >
> > The annotations are tracked in a new ref, refs/annotations/commits,
> > in the same fan-out style as .git/objects/??/*, only that they only
> > exist in the object database now.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > 	I have the hunch that this will be relatively fast and scalable,
> > 	since the tree objects are sorted by name (the name being the
> > 	object name of the to-be-annotated commit).
> 
> The entries of tree are sorted but not necessarily of uniform
> length so you end up needing linear search anyway.  The fan-out
> would help with the current tree objects.

I do not understand... the entries of a tree object are sorted alphabetically, right? Including the convention that if one is a prefix of another, it is "smaller".

While I think that the length would not be any problem, the entries' names of refs/annotations/commit^{tree} are _all_ of length two, and point to other tree objects. _Those_ tree objects contain _only_ entries whose names contain exactly 38 characters.

> It will hurt _if_ we introduce a new tree object format that would give 
> you a quick random-access at an entry, but it is premature to worry 
> about that now.
I do not see that. Care to enlighten me?

Ciao, Dscho

Junio C Hamano· Jun 10, 2007, 23:29 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
> I do not understand... the entries of a tree object are sorted 
> alphabetically, right? Including the convention that if one is a prefix of 
> another, it is "smaller".
>
> While I think that the length would not be any problem, the entries' names 
> of refs/annotations/commit^{tree} are _all_ of length two, and point to 
> other tree objects. _Those_ tree objects contain _only_ entries whose 
> names contain exactly 38 characters.

That is ONLY true if you are introducing a specialized tree object parser that knows it is dealing with the tree used in your annotation scheme that has entries of uniform size. In such a tree parser, you could bisect or Newton-Raphson a tree object data to find an entry more efficiently than for normal trees with enries of variable size.

But I do not think you are planning to do that (nor I would recommend you to). With the normal tree parser, the lookup for "refs/annotations/commit:??/?{38}" you have in your code would open one tree (the commit's tree), find the one with leading 2 hexdigits you would want among up to 256 entries with linear search (see tree-walk.c::find_tree_entry()), open that entry which is another tree, and do the same linear search to find the entry with the remaining 38 hexdigits. Finding annotation for commit 0000abcd... is much less expensive than ffff4567...

Show 5 quoted lines
>> It will hurt _if_ we introduce a new tree object format that would give 
>> you a quick random-access at an entry, but it is premature to worry 
>> about that now.
>
> I do not see that. Care to enlighten me?

At some point (probably git v3.0.0) we _might_ enhance/extend the tree object format so that it has an auxiliary hash table to help you look up an arbitrary entry in a huge tree object (huge in the sense that readdir(3) returns many entries, not in the sense that find(1) returns many results) more efficiently. Pack v4 is rumored to have something like that for in-pack trees.

If that happens, "refs/annotations/commit:?{40}" format would let you look up an annotation for a given commit much more efficiently than "refs/annotations/commit:??/?{38}", because it would have to open only one tree object, instead of two.

Johannes Schindelin· Jun 11, 2007, 10:25 UTC · re: Junio C Hamano · lore

Re: [PATCH] Introduce light weight commit annotations

Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
Show 17 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I do not understand... the entries of a tree object are sorted 
> > alphabetically, right? Including the convention that if one is a 
> > prefix of another, it is "smaller".
> >
> > While I think that the length would not be any problem, the entries' 
> > names of refs/annotations/commit^{tree} are _all_ of length two, and 
> > point to other tree objects. _Those_ tree objects contain _only_ 
> > entries whose names contain exactly 38 characters.
> 
> That is ONLY true if you are introducing a specialized tree
> object parser that knows it is dealing with the tree used in
> your annotation scheme that has entries of uniform size.  In
> such a tree parser, you could bisect or Newton-Raphson a tree
> object data to find an entry more efficiently than for normal
> trees with enries of variable size.

Ouch. That is a real flaw in my proposal. It completely destroys my "I think this will scale just fine" argument.

> If that happens, "refs/annotations/commit:?{40}" format would let you 
> look up an annotation for a given commit much more efficiently than 
> "refs/annotations/commit:??/?{38}", because it would have to open only 
> one tree object, instead of two.

Let me think that one through. At the moment I cannot think of an easy fix.

Ciao, Dscho

Johannes Schindelin· Jun 12, 2007, 17:28 UTC · re: Junio C Hamano · lore

Re: [PATCH] Introduce light weight commit annotations

Hi,
On Sun, 10 Jun 2007, Junio C Hamano wrote:
Show 8 quoted lines
> With the normal tree parser, the lookup for 
> "refs/annotations/commit:??/?{38}" you have in your code would open one 
> tree (the commit's tree), find the one with leading 2 hexdigits you 
> would want among up to 256 entries with linear search (see 
> tree-walk.c::find_tree_entry()), open that entry which is another tree, 
> and do the same linear search to find the entry with the remaining 38 
> hexdigits.  Finding annotation for commit 0000abcd... is much less 
> expensive than ffff4567...

Okay, I did not find a proper solution. commit->file name via "s/../&\//g" is too ugly. But then, I really hope that packv4 becomes unvapourware at some stage (for other reasons), and that _should_ help these issues.

Hmm.

Ciao, Dscho

Alex Riesen· Jun 10, 2007, 22:58 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:
> +MESSAGE="$GIT_DIR"/COMMIT_ANNOTATION.$$
> +git log -1 $COMMIT | sed "s/^/#/" > "$MESSAGE"
> +
> +GIT_INDEX_FILE="$MESSAGE".idx

Because of pid in the filenames, you probably want to cleanup after the annotation is commited.

Alex Riesen· Jun 10, 2007, 23:20 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:
Show 9 quoted lines
> 
> With the provided script, edit-commit-annotations, you can add
> after-the-fact annotations to commits, which will be shown by
> the log if the config variable core.showannotations is set.
> 
> The annotations are tracked in a new ref, refs/annotations/commits,
> in the same fan-out style as .git/objects/??/*, only that they only
> exist in the object database now.
> 
I like it too. And "notes" _is_ less to type :)

BTW, the annotations are a bit cumbersome to merge, if this implementation is to stay (and I personally would like it to) we may have to mention this little inconvenience somewhere.

And can I suggest an interface like the below?
    git notes [[--show] <commit>+] [-d|--delete <commit>+] [-e|--edit <commit>]
With the annotations file being completely removed if it is empty.
Junio C Hamano· Jun 11, 2007, 01:11 UTC · re: Alex Riesen · lore

Re: [PATCH] Introduce light weight commit annotations

Alex Riesen <raa.lkml@gmail.com> writes:
Show 9 quoted lines
> BTW, the annotations are a bit cumbersome to merge, if this
> implementation is to stay (and I personally would like it to) we may
> have to mention this little inconvenience somewhere.
>
> And can I suggest an interface like the below?
>
>     git notes [[--show] <commit>+] [-d|--delete <commit>+] [-e|--edit <commit>]
>
> With the annotations file being completely removed if it is empty.
That is a saner and more extensible interface.

I'll commit a minimally fixed version (essentially, renaming "annotations" to "notes") of Johannes's and push it out to 'pu' tonight.

I think it is a mistake to use config in Johannes's patch, especially without giving a command line override to disable the call to show_annotations() in a repository that has config.showannotations variable set, because the script primes the input with something like this:

	git log -1 $COMMIT | sed -e 's/^/#/' >$MESSAGE
	git cat-file blob $existing_note >>$MESSAGE

and the first "git log" would have already given you the contents of the existing note ;-).

Nicolas Pitre· Jun 11, 2007, 02:09 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce light weight commit annotations

On Sat, 9 Jun 2007, Johannes Schindelin wrote:
> The annotations are tracked in a new ref, refs/annotations/commits,
> in the same fan-out style as .git/objects/??/*, only that they only
> exist in the object database now.

Isn't this abusing the refs namespace a bit? Why not .git/annotations/... instead?

Nicolas
Alex Riesen· Jun 11, 2007, 07:24 UTC · re: Nicolas Pitre · lore

Re: [PATCH] Introduce light weight commit annotations

On 6/11/07, Nicolas Pitre <nico@cam.org> wrote:
Show 9 quoted lines
> On Sat, 9 Jun 2007, Johannes Schindelin wrote:
>
> > The annotations are tracked in a new ref, refs/annotations/commits,
> > in the same fan-out style as .git/objects/??/*, only that they only
> > exist in the object database now.
>
> Isn't this abusing the refs namespace a bit?  Why not
> .git/annotations/... instead?
>

It is still a reference, really. Besides, if it is not under refs/, we'd have to change fetch/push to allow distribution of the notes/annotations (there are special assumptions regarding reference names starting with "refs/"). Right now it just works.

Junio C Hamano· Jun 11, 2007, 07:43 UTC · re: Alex Riesen · lore

Re: [PATCH] Introduce light weight commit annotations

"Alex Riesen" <raa.lkml@gmail.com> writes:
> It is still a reference, really. Besides, if it is not under refs/, we'd
> have to change fetch/push to allow distribution of the notes/annotations
> (there are special assumptions regarding reference names starting
> with "refs/"). Right now it just works.
Two issues.

One is that it is unclear is how the reachability rules should be. Should an ??/?{38} entry in the refs/annotations/commits protects the commit the entry talks about (i.e. ???{38}) from getting pruned?

Another is how different kinds of annotations on the same commit should be managed. Should different commits and their histories pointed at by refs/annotations/{frotz,xyzzy,...} be used for that? Or perhaps we should make ??/?{38} a tree that has multiple files underneath it?

Alex Riesen· Jun 11, 2007, 08:05 UTC · re: Junio C Hamano · lore

Re: [PATCH] Introduce light weight commit annotations

On 6/11/07, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > It is still a reference, really. Besides, if it is not under refs/, we'd
> > have to change fetch/push to allow distribution of the notes/annotations
> > (there are special assumptions regarding reference names starting
> > with "refs/"). Right now it just works.
>
> Two issues.
>
> One is that it is unclear is how the reachability rules should
> be.  Should an ??/?{38} entry in the refs/annotations/commits
> protects the commit the entry talks about (i.e. ???{38}) from
> getting pruned?

I think it should be the other way around: annotations get loose and reported as such (and maybe even removed) by git-fsck.

Johannes Schindelin· Jun 11, 2007, 10:22 UTC · re: Nicolas Pitre · lore

Re: [PATCH] Introduce light weight commit annotations

Hi,
On Sun, 10 Jun 2007, Nicolas Pitre wrote:
Show 8 quoted lines
> On Sat, 9 Jun 2007, Johannes Schindelin wrote:
> 
> > The annotations are tracked in a new ref, refs/annotations/commits,
> > in the same fan-out style as .git/objects/??/*, only that they only
> > exist in the object database now.
> 
> Isn't this abusing the refs namespace a bit?  Why not 
> .git/annotations/... instead?

In the way I planned it, it is not at all abusing the refs namespace. These annotations _are_ tracked in a proper branch. Only that the "file names" in the tree objects actually refer to commit names.

Ciao, Dscho

← back to recent threads