{"thread":{"id":"8531","subject":"[PATCH] Introduce light weight commit annotations","startedAt":"2007-06-09T17:55:10Z","lastAt":"2007-06-12T17:28:19Z","messageCount":18,"participants":["Johannes Schindelin","Johan Herland","Junio C Hamano","Alex Riesen","Nicolas Pitre"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"44461","messageId":"Pine.LNX.4.64.0706091854330.4059@racer.site","threadId":"8531","inReplyTo":null,"subject":"[PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-09T17:55:10Z","receivedAt":"2007-06-09T17:55:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWith the provided script, edit-commit-annotations, you can add\nafter-the-fact annotations to commits, which will be shown by\nthe log if the config variable core.showannotations is set.\n\nThe annotations are tracked in a new ref, refs/annotations/commits,\nin the same fan-out style as .git/objects/??/*, only that they only\nexist in the object database now.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n\n\tI have the hunch that this will be relatively fast and scalable,\n\tsince the tree objects are sorted by name (the name being the\n\tobject name of the to-be-annotated commit).\n\n\tI'm on the run for 15 hours now, but please feel free to discuss\n\tand / or trash it while I'm away.\n\n cache.h                       |    1 +\n commit.c                      |   48 ++++++++++++++++++++++++++++++++++++++++-\n config.c                      |    5 ++++\n environment.c                 |    1 +\n git-edit-commit-annotation.sh |   46 +++++++++++++++++++++++++++++++++++++++\n 5 files changed, 100 insertions(+), 1 deletions(-)\n create mode 100755 git-edit-commit-annotation.sh\n\ndiff --git a/cache.h b/cache.h\nindex bc6b8e8..4166888 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -288,6 +288,7 @@ extern size_t packed_git_window_size;\n extern size_t packed_git_limit;\n extern size_t delta_base_cache_limit;\n extern int auto_crlf;\n+extern int show_commit_annotations;\n \n #define GIT_REPO_VERSION 0\n extern int repository_format_version;\ndiff --git a/commit.c b/commit.c\nindex 4ca4d44..409ebc8 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -911,6 +911,48 @@ static long format_commit_message(const struct commit *commit,\n \treturn strlen(buf);\n }\n \n+static unsigned long show_annotations(const struct commit *commit,\n+\t\tchar *buf, unsigned long space)\n+{\n+\tchar name[80];\n+\tconst char *hex = sha1_to_hex(commit->object.sha1);\n+\tunsigned char sha1[20];\n+\tchar *msg;\n+\tunsigned long offset = 0, msgoffset = 0, msglen;\n+\tenum object_type type;\n+\n+\tsnprintf(name, sizeof(name),\n+\t\t\t\"refs/annotations/commits:%.*s/%.*s\",\n+\t\t\t2, hex, 38, hex + 2);\n+\tif (get_sha1(name, sha1))\n+\t\treturn 0;\n+\n+\tif (!(msg = read_sha1_file(sha1, &type, &msglen)) || !msglen)\n+\t\treturn 0;\n+\t/* we will end the annotation by a newline anyway. */\n+\tif (msg[msglen - 1] == '\\n')\n+\t\tmsglen--;\n+\n+\toffset += snprintf(buf + offset, space - offset - 1,\n+\t\t\t\"\\nAnnotation:\\n\");\n+\n+\tfor (msgoffset = 0; msgoffset < msglen;) {\n+\t\tint linelen = get_one_line(msg + msgoffset, msglen);\n+\n+\t\toffset += snprintf(buf + offset, space - offset - 1,\n+\t\t\t\"    %.*s\", linelen, msg + msgoffset);\n+\n+\t\tif (offset + 1 >= space)\n+\t\t\tbreak;\n+\n+\t\tmsgoffset += linelen;\n+\t}\n+\tbuf[offset++] = '\\n';\n+\tfree(msg);\n+\n+\treturn offset;\n+}\n+\n unsigned long pretty_print_commit(enum cmit_fmt fmt,\n \t\t\t\t  const struct commit *commit,\n \t\t\t\t  unsigned long len,\n@@ -1098,8 +1140,12 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,\n \t */\n \tif (fmt == CMIT_FMT_EMAIL && !body)\n \t\tbuf[offset++] = '\\n';\n-\tbuf[offset] = '\\0';\n \n+\tif (fmt != CMIT_FMT_ONELINE && show_commit_annotations)\n+\t\toffset += show_annotations(commit,\n+\t\t\t\tbuf + offset, space - offset);\n+\n+\tbuf[offset] = '\\0';\n \tfree(reencoded);\n \treturn offset;\n }\ndiff --git a/config.c b/config.c\nindex 58d3ed5..34db9b2 100644\n--- a/config.c\n+++ b/config.c\n@@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.showannotaions\")) {\n+\t\tshow_commit_annotations = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"user.name\")) {\n \t\tstrlcpy(git_default_name, value, sizeof(git_default_name));\n \t\treturn 0;\ndiff --git a/environment.c b/environment.c\nindex 8b9b89d..c649f19 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -32,6 +32,7 @@ size_t delta_base_cache_limit = 16 * 1024 * 1024;\n int pager_in_use;\n int pager_use_color = 1;\n int auto_crlf = 0;\t/* 1: both ways, -1: only when adding git objects */\n+int show_commit_annotations;\n \n static const char *git_dir;\n static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;\ndiff --git a/git-edit-commit-annotation.sh b/git-edit-commit-annotation.sh\nnew file mode 100755\nindex 0000000..2abcd34\n--- /dev/null\n+++ b/git-edit-commit-annotation.sh\n@@ -0,0 +1,46 @@\n+#!/bin/sh\n+\n+USAGE=\"[commit-name]\"\n+. git-sh-setup\n+\n+test -n \"$2\" && usage\n+COMMIT=$(git rev-parse --verify --default HEAD \"$@\")\n+NAME=$(echo $COMMIT | sed \"s/^../&\\//\")\n+\n+MESSAGE=\"$GIT_DIR\"/COMMIT_ANNOTATION.$$\n+git log -1 $COMMIT | sed \"s/^/#/\" > \"$MESSAGE\"\n+\n+GIT_INDEX_FILE=\"$MESSAGE\".idx\n+export GIT_INDEX_FILE\n+\n+TIPNAME=refs/annotations/commits\n+OLDTIP=$(git show-ref $TIPNAME | cut -f 1 -d ' ')\n+if [ -z \"$OLDTIP\" ]; then\n+\tOLDTIP=0000000000000000000000000000000000000000\n+else\n+\tPARENT=\"-p $OLDTIP\"\n+\tgit read-tree $TIPNAME || die \"Could not read index\"\n+\tgit cat-file blob :$NAME >> \"$MESSAGE\" 2> /dev/null\n+fi\n+\n+${VISUAL:-${EDITOR:-vi}} \"$MESSAGE\"\n+\n+grep -v ^# < \"$MESSAGE\" | git stripspace > \"$MESSAGE\".processed\n+mv \"$MESSAGE\".processed \"$MESSAGE\"\n+if [ -z \"$(cat \"$MESSAGE\")\" ]; then\n+\tcase $OLDTIP in 0000000000000000000000000000000000000000)\n+\t\techo \"Will not initialise with empty tree\"\n+\t\texit 1\n+\tesac\n+\tgit update-index --force-remove $NAME ||\n+\t\tdie \"Could not update index\"\n+else\n+\tBLOB=$(git hash-object -w \"$MESSAGE\") ||\n+\t\tdie \"Could not write into object database\"\n+\tgit update-index --add --cacheinfo 0644 $BLOB $NAME ||\n+\t\tdie \"Could not write index\"\n+fi\n+\n+TREE=$(git write-tree) || die \"Could not write tree\"\n+NEWTIP=$(date | git commit-tree $TREE $PARENT) || die \"Could not annotate\"\n+git update-ref $TIPNAME $NEWTIP $OLDTIP\n-- \n1.5.2.1.2713.gbb6a-dirty\n"},{"id":"44599","messageId":"200706101514.14954.johan@herland.net","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706091854330.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-06-10T13:14:14Z","receivedAt":"2007-06-10T13:14:14Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 09 June 2007, Johannes Schindelin wrote:\n> With the provided script, edit-commit-annotations, you can add\n> after-the-fact annotations to commits, which will be shown by\n> the log if the config variable core.showannotations is set.\n> \n> The annotations are tracked in a new ref, refs/annotations/commits,\n> in the same fan-out style as .git/objects/??/*, only that they only\n> exist in the object database now.\n\nVery interesting. I have to say that after having played around with\nit a couple of minutes, I really like it. Needs some polishing here\nand there (i.e. cleaning up the COMMIT_ANNOTATION.NNNN* files), but\nit is a very good proof-of-concept.\n\n> \tI have the hunch that this will be relatively fast and scalable,\n> \tsince the tree objects are sorted by name (the name being the\n> \tobject name of the to-be-annotated commit).\n\nI think I agree with your hunch, although I initially thought that your\nsolution was a bit heavy on the number of objects created. But, hey, git\nis _designed_ to handle massive amounts of objects. :)\n\n> diff --git a/config.c b/config.c\n> index 58d3ed5..34db9b2 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)\n>  \t\treturn 0;\n>  \t}\n>  \n> +\tif (!strcmp(var, \"core.showannotaions\")) {\n> +\t\tshow_commit_annotations = git_config_bool(var, value);\n> +\t\treturn 0;\n> +\t}\n> +\n\nSmall typo here. \"core.showannotaions\" should be \"core.showannotations\",\nI guess.\n\n\n...Johan\n\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"44629","messageId":"Pine.LNX.4.64.0706101952180.4059@racer.site","threadId":"8531","inReplyTo":"200706101514.14954.johan@herland.net","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-10T18:56:32Z","receivedAt":"2007-06-10T18:56:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Jun 2007, Johan Herland wrote:\n\n> On Saturday 09 June 2007, Johannes Schindelin wrote:\n>\n> > With the provided script, edit-commit-annotations, you can add \n> > after-the-fact annotations to commits, which will be shown by the log \n> > if the config variable core.showannotations is set.\n> > \n> > The annotations are tracked in a new ref, refs/annotations/commits, in \n> > the same fan-out style as .git/objects/??/*, only that they only exist \n> > in the object database now.\n> \n> Very interesting. I have to say that after having played around with\n> it a couple of minutes, I really like it. Needs some polishing here\n> and there (i.e. cleaning up the COMMIT_ANNOTATION.NNNN* files), but\n> it is a very good proof-of-concept.\n\nThanks. I composed it in a hurry, since I wanted it to go out before I \ntook my flight home.\n\n> > \tI have the hunch that this will be relatively fast and scalable,\n> > \tsince the tree objects are sorted by name (the name being the\n> > \tobject name of the to-be-annotated commit).\n> \n> I think I agree with your hunch, although I initially thought that your\n> solution was a bit heavy on the number of objects created. But, hey, git\n> is _designed_ to handle massive amounts of objects. :)\n\nBesides, these tree objects should delta really well, being almost as \nefficient as having only one tree object to begin with.\n\n> > diff --git a/config.c b/config.c\n> > index 58d3ed5..34db9b2 100644\n> > --- a/config.c\n> > +++ b/config.c\n> > @@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)\n> >  \t\treturn 0;\n> >  \t}\n> >  \n> > +\tif (!strcmp(var, \"core.showannotaions\")) {\n> > +\t\tshow_commit_annotations = git_config_bool(var, value);\n> > +\t\treturn 0;\n> > +\t}\n> > +\n> \n> Small typo here. \"core.showannotaions\" should be \"core.showannotations\",\n> I guess.\n\nYep. I tested it with \"core.shownotes\", but decided before sending the \npatch that the name would be inconsistent with the rest of the code.\n\nHowever, as I suggested later, I could imagine that an even better way \ncould be to have \"core.annotationsRef\", overrideable by \nGIT_ANNOTATIONS_REF, which could possibly even be a list of refs.\n\nBTW I am not married to calling it \"annotations\". If you like \"notes\" \nbetter, I'm fine with it.\n\nCiao,\nDscho\n"},{"id":"44632","messageId":"200706102120.55758.johan@herland.net","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706101952180.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-06-10T19:20:55Z","receivedAt":"2007-06-10T19:20:55Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 10 June 2007, Johannes Schindelin wrote:\n> On Sun, 10 Jun 2007, Johan Herland wrote:\n> > Small typo here. \"core.showannotaions\" should be \"core.showannotations\",\n> > I guess.\n> \n> Yep. I tested it with \"core.shownotes\", but decided before sending the \n> patch that the name would be inconsistent with the rest of the code.\n> \n> However, as I suggested later, I could imagine that an even better way \n> could be to have \"core.annotationsRef\", overrideable by \n> GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.\n> \n> BTW I am not married to calling it \"annotations\". If you like \"notes\" \n> better, I'm fine with it.\n\nNo problem. Actually I really wanted to call my first\nproof-of-concept \"annotations\", and not \"notes\", but I\nfigured it would be confused with the \"annotate-as-in-blame\"\nconcept. Besides there is already a git-annotate command...\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"44635","messageId":"Pine.LNX.4.64.0706102052450.4059@racer.site","threadId":"8531","inReplyTo":"200706102120.55758.johan@herland.net","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-10T19:53:01Z","receivedAt":"2007-06-10T19:53:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Jun 2007, Johan Herland wrote:\n\n> On Sunday 10 June 2007, Johannes Schindelin wrote:\n> > On Sun, 10 Jun 2007, Johan Herland wrote:\n> > > Small typo here. \"core.showannotaions\" should be \"core.showannotations\",\n> > > I guess.\n> > \n> > Yep. I tested it with \"core.shownotes\", but decided before sending the \n> > patch that the name would be inconsistent with the rest of the code.\n> > \n> > However, as I suggested later, I could imagine that an even better way \n> > could be to have \"core.annotationsRef\", overrideable by \n> > GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.\n> > \n> > BTW I am not married to calling it \"annotations\". If you like \"notes\" \n> > better, I'm fine with it.\n> \n> No problem. Actually I really wanted to call my first\n> proof-of-concept \"annotations\", and not \"notes\", but I\n> figured it would be confused with the \"annotate-as-in-blame\"\n> concept. Besides there is already a git-annotate command...\n\nNot to forget that note is shorter to type.\n\nCiao,\nDscho\n"},{"id":"44652","messageId":"7v4plf7948.fsf@assigned-by-dhcp.cox.net","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706091854330.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-10T22:11:35Z","receivedAt":"2007-06-10T22:11:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> With the provided script, edit-commit-annotations, you can add\n> after-the-fact annotations to commits, which will be shown by\n> the log if the config variable core.showannotations is set.\n>\n> The annotations are tracked in a new ref, refs/annotations/commits,\n> in the same fan-out style as .git/objects/??/*, only that they only\n> exist in the object database now.\n>\n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n>\n> \tI have the hunch that this will be relatively fast and scalable,\n> \tsince the tree objects are sorted by name (the name being the\n> \tobject name of the to-be-annotated commit).\n\nThe entries of tree are sorted but not necessarily of uniform\nlength so you end up needing linear search anyway.  The fan-out\nwould help with the current tree objects.\n\nIt will hurt _if_ we introduce a new tree object format that\nwould give you a quick random-access at an entry, but it is\npremature to worry about that now.\n"},{"id":"44657","messageId":"20070610225851.GA5761@steel.home","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706091854330.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-10T22:58:51Z","receivedAt":"2007-06-10T22:58:51Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:\n> +MESSAGE=\"$GIT_DIR\"/COMMIT_ANNOTATION.$$\n> +git log -1 $COMMIT | sed \"s/^/#/\" > \"$MESSAGE\"\n> +\n> +GIT_INDEX_FILE=\"$MESSAGE\".idx\n\nBecause of pid in the filenames, you probably want to cleanup after\nthe annotation is commited.\n"},{"id":"44659","messageId":"Pine.LNX.4.64.0706102333050.4059@racer.site","threadId":"8531","inReplyTo":"7v4plf7948.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-10T23:00:09Z","receivedAt":"2007-06-10T23:00:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Jun 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > With the provided script, edit-commit-annotations, you can add\n> > after-the-fact annotations to commits, which will be shown by\n> > the log if the config variable core.showannotations is set.\n> >\n> > The annotations are tracked in a new ref, refs/annotations/commits,\n> > in the same fan-out style as .git/objects/??/*, only that they only\n> > exist in the object database now.\n> >\n> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > ---\n> >\n> > \tI have the hunch that this will be relatively fast and scalable,\n> > \tsince the tree objects are sorted by name (the name being the\n> > \tobject name of the to-be-annotated commit).\n> \n> The entries of tree are sorted but not necessarily of uniform\n> length so you end up needing linear search anyway.  The fan-out\n> would help with the current tree objects.\n\nI do not understand... the entries of a tree object are sorted \nalphabetically, right? Including the convention that if one is a prefix of \nanother, it is \"smaller\".\n\nWhile I think that the length would not be any problem, the entries' names \nof refs/annotations/commit^{tree} are _all_ of length two, and point to \nother tree objects. _Those_ tree objects contain _only_ entries whose \nnames contain exactly 38 characters.\n\n> It will hurt _if_ we introduce a new tree object format that would give \n> you a quick random-access at an entry, but it is premature to worry \n> about that now.\n\nI do not see that. Care to enlighten me?\n\nCiao,\nDscho\n"},{"id":"44662","messageId":"20070610232016.GB5761@steel.home","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706091854330.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-10T23:20:16Z","receivedAt":"2007-06-10T23:20:16Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Sat, Jun 09, 2007 19:55:10 +0200:\n> \n> With the provided script, edit-commit-annotations, you can add\n> after-the-fact annotations to commits, which will be shown by\n> the log if the config variable core.showannotations is set.\n> \n> The annotations are tracked in a new ref, refs/annotations/commits,\n> in the same fan-out style as .git/objects/??/*, only that they only\n> exist in the object database now.\n> \n\nI like it too. And \"notes\" _is_ less to type :)\n\nBTW, the annotations are a bit cumbersome to merge, if this\nimplementation is to stay (and I personally would like it to) we may\nhave to mention this little inconvenience somewhere.\n\nAnd can I suggest an interface like the below?\n\n    git notes [[--show] <commit>+] [-d|--delete <commit>+] [-e|--edit <commit>]\n\nWith the annotations file being completely removed if it is empty.\n"},{"id":"44664","messageId":"7v4plf5qxp.fsf@assigned-by-dhcp.cox.net","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706102333050.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-10T23:29:38Z","receivedAt":"2007-06-10T23:29:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I do not understand... the entries of a tree object are sorted \n> alphabetically, right? Including the convention that if one is a prefix of \n> another, it is \"smaller\".\n>\n> While I think that the length would not be any problem, the entries' names \n> of refs/annotations/commit^{tree} are _all_ of length two, and point to \n> other tree objects. _Those_ tree objects contain _only_ entries whose \n> names contain exactly 38 characters.\n\nThat is ONLY true if you are introducing a specialized tree\nobject parser that knows it is dealing with the tree used in\nyour annotation scheme that has entries of uniform size.  In\nsuch a tree parser, you could bisect or Newton-Raphson a tree\nobject data to find an entry more efficiently than for normal\ntrees with enries of variable size.\n\nBut I do not think you are planning to do that (nor I would\nrecommend you to).  With the normal tree parser, the lookup for\n\"refs/annotations/commit:??/?{38}\" you have in your code would\nopen one tree (the commit's tree), find the one with leading 2\nhexdigits you would want among up to 256 entries with linear\nsearch (see tree-walk.c::find_tree_entry()), open that entry\nwhich is another tree, and do the same linear search to find the\nentry with the remaining 38 hexdigits.  Finding annotation for\ncommit 0000abcd... is much less expensive than ffff4567...\n\n>> It will hurt _if_ we introduce a new tree object format that would give \n>> you a quick random-access at an entry, but it is premature to worry \n>> about that now.\n>\n> I do not see that. Care to enlighten me?\n\nAt some point (probably git v3.0.0) we _might_ enhance/extend\nthe tree object format so that it has an auxiliary hash table to\nhelp you look up an arbitrary entry in a huge tree object (huge\nin the sense that readdir(3) returns many entries, not in the\nsense that find(1) returns many results) more efficiently. Pack\nv4 is rumored to have something like that for in-pack trees.\n\nIf that happens, \"refs/annotations/commit:?{40}\" format would\nlet you look up an annotation for a given commit much more\nefficiently than \"refs/annotations/commit:??/?{38}\", because it\nwould have to open only one tree object, instead of two.\n"},{"id":"44683","messageId":"7vsl8z2t3s.fsf@assigned-by-dhcp.cox.net","threadId":"8531","inReplyTo":"20070610232016.GB5761@steel.home","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-11T01:11:03Z","receivedAt":"2007-06-11T01:11:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> BTW, the annotations are a bit cumbersome to merge, if this\n> implementation is to stay (and I personally would like it to) we may\n> have to mention this little inconvenience somewhere.\n>\n> And can I suggest an interface like the below?\n>\n>     git notes [[--show] <commit>+] [-d|--delete <commit>+] [-e|--edit <commit>]\n>\n> With the annotations file being completely removed if it is empty.\n\nThat is a saner and more extensible interface.\n\nI'll commit a minimally fixed version (essentially, renaming\n\"annotations\" to \"notes\") of Johannes's and push it out to 'pu'\ntonight.\n\nI think it is a mistake to use config in Johannes's patch,\nespecially without giving a command line override to disable\nthe call to show_annotations() in a repository that has\nconfig.showannotations variable set, because the script primes\nthe input with something like this:\n\n\tgit log -1 $COMMIT | sed -e 's/^/#/' >$MESSAGE\n\tgit cat-file blob $existing_note >>$MESSAGE\n\nand the first \"git log\" would have already given you the\ncontents of the existing note ;-).\n"},{"id":"44686","messageId":"alpine.LFD.0.99.0706102206590.12885@xanadu.home","threadId":"8531","inReplyTo":"Pine.LNX.4.64.0706091854330.4059@racer.site","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-11T02:09:16Z","receivedAt":"2007-06-11T02:09:16Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 9 Jun 2007, Johannes Schindelin wrote:\n\n> The annotations are tracked in a new ref, refs/annotations/commits,\n> in the same fan-out style as .git/objects/??/*, only that they only\n> exist in the object database now.\n\nIsn't this abusing the refs namespace a bit?  Why not \n.git/annotations/... instead?\n\n\nNicolas\n"},{"id":"44699","messageId":"81b0412b0706110024mf975011t27b23555f6a23cc6@mail.gmail.com","threadId":"8531","inReplyTo":"alpine.LFD.0.99.0706102206590.12885@xanadu.home","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-11T07:24:36Z","receivedAt":"2007-06-11T07:24:36Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/11/07, Nicolas Pitre <nico@cam.org> wrote:\n> On Sat, 9 Jun 2007, Johannes Schindelin wrote:\n>\n> > The annotations are tracked in a new ref, refs/annotations/commits,\n> > in the same fan-out style as .git/objects/??/*, only that they only\n> > exist in the object database now.\n>\n> Isn't this abusing the refs namespace a bit?  Why not\n> .git/annotations/... instead?\n>\n\nIt is still a reference, really. Besides, if it is not under refs/, we'd\nhave to change fetch/push to allow distribution of the notes/annotations\n(there are special assumptions regarding reference names starting\nwith \"refs/\"). Right now it just works.\n"},{"id":"44701","messageId":"7vbqfnrl54.fsf@assigned-by-dhcp.pobox.com","threadId":"8531","inReplyTo":"81b0412b0706110024mf975011t27b23555f6a23cc6@mail.gmail.com","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-11T07:43:51Z","receivedAt":"2007-06-11T07:43:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" <raa.lkml@gmail.com> writes:\n\n> It is still a reference, really. Besides, if it is not under refs/, we'd\n> have to change fetch/push to allow distribution of the notes/annotations\n> (there are special assumptions regarding reference names starting\n> with \"refs/\"). Right now it just works.\n\nTwo issues.\n\nOne is that it is unclear is how the reachability rules should\nbe.  Should an ??/?{38} entry in the refs/annotations/commits\nprotects the commit the entry talks about (i.e. ???{38}) from\ngetting pruned?\n\nAnother is how different kinds of annotations on the same commit\nshould be managed.  Should different commits and their histories\npointed at by refs/annotations/{frotz,xyzzy,...} be used for\nthat?  Or perhaps we should make ??/?{38} a tree that has\nmultiple files underneath it?\n"},{"id":"44703","messageId":"81b0412b0706110105t369d908v70a140505caee778@mail.gmail.com","threadId":"8531","inReplyTo":"7vbqfnrl54.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-11T08:05:53Z","receivedAt":"2007-06-11T08:05:53Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/11/07, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Alex Riesen\" <raa.lkml@gmail.com> writes:\n>\n> > It is still a reference, really. Besides, if it is not under refs/, we'd\n> > have to change fetch/push to allow distribution of the notes/annotations\n> > (there are special assumptions regarding reference names starting\n> > with \"refs/\"). Right now it just works.\n>\n> Two issues.\n>\n> One is that it is unclear is how the reachability rules should\n> be.  Should an ??/?{38} entry in the refs/annotations/commits\n> protects the commit the entry talks about (i.e. ???{38}) from\n> getting pruned?\n\nI think it should be the other way around: annotations get loose\nand reported as such (and maybe even removed) by git-fsck.\n"},{"id":"44715","messageId":"Pine.LNX.4.64.0706111121120.4059@racer.site","threadId":"8531","inReplyTo":"alpine.LFD.0.99.0706102206590.12885@xanadu.home","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-11T10:22:40Z","receivedAt":"2007-06-11T10:22:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Jun 2007, Nicolas Pitre wrote:\n\n> On Sat, 9 Jun 2007, Johannes Schindelin wrote:\n> \n> > The annotations are tracked in a new ref, refs/annotations/commits,\n> > in the same fan-out style as .git/objects/??/*, only that they only\n> > exist in the object database now.\n> \n> Isn't this abusing the refs namespace a bit?  Why not \n> .git/annotations/... instead?\n\nIn the way I planned it, it is not at all abusing the refs namespace. \nThese annotations _are_ tracked in a proper branch. Only that the \"file \nnames\" in the tree objects actually refer to commit names.\n\nCiao,\nDscho\n"},{"id":"44716","messageId":"Pine.LNX.4.64.0706111122470.4059@racer.site","threadId":"8531","inReplyTo":"7v4plf5qxp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-11T10:25:54Z","receivedAt":"2007-06-11T10:25:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Jun 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > I do not understand... the entries of a tree object are sorted \n> > alphabetically, right? Including the convention that if one is a \n> > prefix of another, it is \"smaller\".\n> >\n> > While I think that the length would not be any problem, the entries' \n> > names of refs/annotations/commit^{tree} are _all_ of length two, and \n> > point to other tree objects. _Those_ tree objects contain _only_ \n> > entries whose names contain exactly 38 characters.\n> \n> That is ONLY true if you are introducing a specialized tree\n> object parser that knows it is dealing with the tree used in\n> your annotation scheme that has entries of uniform size.  In\n> such a tree parser, you could bisect or Newton-Raphson a tree\n> object data to find an entry more efficiently than for normal\n> trees with enries of variable size.\n\nOuch. That is a real flaw in my proposal. It completely destroys my \"I \nthink this will scale just fine\" argument.\n\n> If that happens, \"refs/annotations/commit:?{40}\" format would let you \n> look up an annotation for a given commit much more efficiently than \n> \"refs/annotations/commit:??/?{38}\", because it would have to open only \n> one tree object, instead of two.\n\nLet me think that one through. At the moment I cannot think of an easy \nfix.\n\nCiao,\nDscho\n"},{"id":"44847","messageId":"Pine.LNX.4.64.0706121825460.4059@racer.site","threadId":"8531","inReplyTo":"7v4plf5qxp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce light weight commit annotations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-12T17:28:19Z","receivedAt":"2007-06-12T17:28:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Jun 2007, Junio C Hamano wrote:\n\n> With the normal tree parser, the lookup for \n> \"refs/annotations/commit:??/?{38}\" you have in your code would open one \n> tree (the commit's tree), find the one with leading 2 hexdigits you \n> would want among up to 256 entries with linear search (see \n> tree-walk.c::find_tree_entry()), open that entry which is another tree, \n> and do the same linear search to find the entry with the remaining 38 \n> hexdigits.  Finding annotation for commit 0000abcd... is much less \n> expensive than ffff4567...\n\nOkay, I did not find a proper solution. commit->file name via \"s/../&\\//g\" \nis too ugly. But then, I really hope that packv4 becomes unvapourware at \nsome stage (for other reasons), and that _should_ help these issues.\n\nHmm.\n\nCiao,\nDscho\n"}]}