git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Introduce light weight commit annotations
@ 2007-06-09 17:55 Johannes Schindelin
  2007-06-10 13:14 ` Johan Herland
                   ` (4 more replies)
  0 siblings, 5 replies; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-09 17:55 UTC (permalink / raw)
  To: git, gitster, Johan Herland


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

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

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-09 17:55 [PATCH] Introduce light weight commit annotations Johannes Schindelin
@ 2007-06-10 13:14 ` Johan Herland
  2007-06-10 18:56   ` Johannes Schindelin
  2007-06-10 22:11 ` Junio C Hamano
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 18+ messages in thread
From: Johan Herland @ 2007-06-10 13:14 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster

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.

> 	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. :)

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 13:14 ` Johan Herland
@ 2007-06-10 18:56   ` Johannes Schindelin
  2007-06-10 19:20     ` Johan Herland
  0 siblings, 1 reply; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-10 18:56 UTC (permalink / raw)
  To: Johan Herland; +Cc: git, gitster

Hi,

On Sun, 10 Jun 2007, Johan Herland wrote:

> 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.

> > 	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.

> > 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 18:56   ` Johannes Schindelin
@ 2007-06-10 19:20     ` Johan Herland
  2007-06-10 19:53       ` Johannes Schindelin
  0 siblings, 1 reply; 18+ messages in thread
From: Johan Herland @ 2007-06-10 19:20 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster

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...


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 19:20     ` Johan Herland
@ 2007-06-10 19:53       ` Johannes Schindelin
  0 siblings, 0 replies; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-10 19:53 UTC (permalink / raw)
  To: Johan Herland; +Cc: git, gitster

Hi,

On Sun, 10 Jun 2007, Johan Herland wrote:

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-09 17:55 [PATCH] Introduce light weight commit annotations Johannes Schindelin
  2007-06-10 13:14 ` Johan Herland
@ 2007-06-10 22:11 ` Junio C Hamano
  2007-06-10 23:00   ` Johannes Schindelin
  2007-06-10 22:58 ` Alex Riesen
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2007-06-10 22:11 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster, Johan Herland

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.

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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-09 17:55 [PATCH] Introduce light weight commit annotations Johannes Schindelin
  2007-06-10 13:14 ` Johan Herland
  2007-06-10 22:11 ` Junio C Hamano
@ 2007-06-10 22:58 ` Alex Riesen
  2007-06-10 23:20 ` Alex Riesen
  2007-06-11  2:09 ` Nicolas Pitre
  4 siblings, 0 replies; 18+ messages in thread
From: Alex Riesen @ 2007-06-10 22:58 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster, Johan Herland

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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 22:11 ` Junio C Hamano
@ 2007-06-10 23:00   ` Johannes Schindelin
  2007-06-10 23:29     ` Junio C Hamano
  0 siblings, 1 reply; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-10 23:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johan Herland

Hi,

On Sun, 10 Jun 2007, Junio C Hamano wrote:

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-09 17:55 [PATCH] Introduce light weight commit annotations Johannes Schindelin
                   ` (2 preceding siblings ...)
  2007-06-10 22:58 ` Alex Riesen
@ 2007-06-10 23:20 ` Alex Riesen
  2007-06-11  1:11   ` Junio C Hamano
  2007-06-11  2:09 ` Nicolas Pitre
  4 siblings, 1 reply; 18+ messages in thread
From: Alex Riesen @ 2007-06-10 23:20 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster, Johan Herland

Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:
> 
> 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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 23:00   ` Johannes Schindelin
@ 2007-06-10 23:29     ` Junio C Hamano
  2007-06-11 10:25       ` Johannes Schindelin
  2007-06-12 17:28       ` Johannes Schindelin
  0 siblings, 2 replies; 18+ messages in thread
From: Junio C Hamano @ 2007-06-10 23:29 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Johan Herland

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.

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...

>> 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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 23:20 ` Alex Riesen
@ 2007-06-11  1:11   ` Junio C Hamano
  0 siblings, 0 replies; 18+ messages in thread
From: Junio C Hamano @ 2007-06-11  1:11 UTC (permalink / raw)
  To: Alex Riesen; +Cc: Johannes Schindelin, git, Johan Herland

Alex Riesen <raa.lkml@gmail.com> writes:

> 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 ;-).

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-09 17:55 [PATCH] Introduce light weight commit annotations Johannes Schindelin
                   ` (3 preceding siblings ...)
  2007-06-10 23:20 ` Alex Riesen
@ 2007-06-11  2:09 ` Nicolas Pitre
  2007-06-11  7:24   ` Alex Riesen
  2007-06-11 10:22   ` Johannes Schindelin
  4 siblings, 2 replies; 18+ messages in thread
From: Nicolas Pitre @ 2007-06-11  2:09 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, gitster, Johan Herland

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-11  2:09 ` Nicolas Pitre
@ 2007-06-11  7:24   ` Alex Riesen
  2007-06-11  7:43     ` Junio C Hamano
  2007-06-11 10:22   ` Johannes Schindelin
  1 sibling, 1 reply; 18+ messages in thread
From: Alex Riesen @ 2007-06-11  7:24 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Johannes Schindelin, git, gitster, Johan Herland

On 6/11/07, Nicolas Pitre <nico@cam.org> wrote:
> 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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-11  7:24   ` Alex Riesen
@ 2007-06-11  7:43     ` Junio C Hamano
  2007-06-11  8:05       ` Alex Riesen
  0 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2007-06-11  7:43 UTC (permalink / raw)
  To: Alex Riesen
  Cc: Nicolas Pitre, Johannes Schindelin, git, gitster, Johan Herland

"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?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-11  7:43     ` Junio C Hamano
@ 2007-06-11  8:05       ` Alex Riesen
  0 siblings, 0 replies; 18+ messages in thread
From: Alex Riesen @ 2007-06-11  8:05 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Schindelin, git, Johan Herland

On 6/11/07, Junio C Hamano <gitster@pobox.com> wrote:
> "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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-11  2:09 ` Nicolas Pitre
  2007-06-11  7:24   ` Alex Riesen
@ 2007-06-11 10:22   ` Johannes Schindelin
  1 sibling, 0 replies; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-11 10:22 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, gitster, Johan Herland

Hi,

On Sun, 10 Jun 2007, Nicolas Pitre wrote:

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 23:29     ` Junio C Hamano
@ 2007-06-11 10:25       ` Johannes Schindelin
  2007-06-12 17:28       ` Johannes Schindelin
  1 sibling, 0 replies; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-11 10:25 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johan Herland

Hi,

On Sun, 10 Jun 2007, Junio C Hamano wrote:

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] Introduce light weight commit annotations
  2007-06-10 23:29     ` Junio C Hamano
  2007-06-11 10:25       ` Johannes Schindelin
@ 2007-06-12 17:28       ` Johannes Schindelin
  1 sibling, 0 replies; 18+ messages in thread
From: Johannes Schindelin @ 2007-06-12 17:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johan Herland

Hi,

On Sun, 10 Jun 2007, Junio C Hamano wrote:

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2007-06-12 17:31 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-09 17:55 [PATCH] Introduce light weight commit annotations Johannes Schindelin
2007-06-10 13:14 ` Johan Herland
2007-06-10 18:56   ` Johannes Schindelin
2007-06-10 19:20     ` Johan Herland
2007-06-10 19:53       ` Johannes Schindelin
2007-06-10 22:11 ` Junio C Hamano
2007-06-10 23:00   ` Johannes Schindelin
2007-06-10 23:29     ` Junio C Hamano
2007-06-11 10:25       ` Johannes Schindelin
2007-06-12 17:28       ` Johannes Schindelin
2007-06-10 22:58 ` Alex Riesen
2007-06-10 23:20 ` Alex Riesen
2007-06-11  1:11   ` Junio C Hamano
2007-06-11  2:09 ` Nicolas Pitre
2007-06-11  7:24   ` Alex Riesen
2007-06-11  7:43     ` Junio C Hamano
2007-06-11  8:05       ` Alex Riesen
2007-06-11 10:22   ` Johannes Schindelin

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).