{"thread":{"id":"8166","subject":"[PATCH] Add an option to git-ls-tree to display also the size of object","startedAt":"2007-05-15T10:24:30Z","lastAt":"2007-05-20T03:54:07Z","messageCount":9,"participants":["Jakub Narebski","Junio C Hamano","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"42209","messageId":"11792246701367-git-send-email-jnareb@gmail.com","threadId":"8166","inReplyTo":null,"subject":"[PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-15T10:24:30Z","receivedAt":"2007-05-15T10:24:30Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Add -l/--long/--size option to git-ls-tree command, which displays\nobject size of an entry after object id (left-justified with minimum\nwidth of 7 characters).\n\nSigned-off-by: Jakub Narebski <jnareb@gmail.com>\n---\nThis is to be used in 'tree' view in gitweb, controlled by the\n%feature hash.\n\n Documentation/git-ls-tree.txt |   14 +++++++++++++-\n builtin-ls-tree.c             |   34 ++++++++++++++++++++++++++--------\n 2 files changed, 39 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt\nindex 7899394..367f9bb 100644\n--- a/Documentation/git-ls-tree.txt\n+++ b/Documentation/git-ls-tree.txt\n@@ -9,7 +9,7 @@ git-ls-tree - List the contents of a tree object\n SYNOPSIS\n --------\n [verse]\n-'git-ls-tree' [-d] [-r] [-t] [-z]\n+'git-ls-tree' [-d] [-r] [-t] [-l] [-z]\n \t    [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]\n \t    <tree-ish> [paths...]\n \n@@ -36,6 +36,11 @@ OPTIONS\n \tShow tree entries even when going to recurse them. Has no effect\n \tif '-r' was not passed. '-d' implies '-t'.\n \n+-l::\n+--long::\n+--size::\n+\tShow object size of entries.\n+\n -z::\n \t\\0 line termination on output.\n \n@@ -65,6 +70,13 @@ Output Format\n When the `-z` option is not used, TAB, LF, and backslash characters\n in pathnames are represented as `\\t`, `\\n`, and `\\\\`, respectively.\n \n+When the `-l` option is used, format changes to\n+\n+        <mode> SP <type> SP <object> SP <object size> TAB <file>\n+\n+Object size identified by <objest> is given in bytes, and left-justified\n+with minimum width of 7 characters.\n+\n \n Author\n ------\ndiff --git a/builtin-ls-tree.c b/builtin-ls-tree.c\nindex 1cb4dca..0c2eef7 100644\n--- a/builtin-ls-tree.c\n+++ b/builtin-ls-tree.c\n@@ -15,6 +15,7 @@ static int line_termination = '\\n';\n #define LS_TREE_ONLY 2\n #define LS_SHOW_TREES 4\n #define LS_NAME_ONLY 8\n+#define LS_SHOW_SIZE 16\n static int abbrev;\n static int ls_options;\n static const char **pathspec;\n@@ -22,7 +23,7 @@ static int chomp_prefix;\n static const char *ls_tree_prefix;\n \n static const char ls_tree_usage[] =\n-\t\"git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]\";\n+\t\"git-ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]\";\n \n static int show_recursive(const char *base, int baselen, const char *pathname)\n {\n@@ -55,10 +56,11 @@ static int show_recursive(const char *base, int baselen, const char *pathname)\n }\n \n static int show_tree(const unsigned char *sha1, const char *base, int baselen,\n-\t\t     const char *pathname, unsigned mode, int stage)\n+                     const char *pathname, unsigned mode, int stage)\n {\n \tint retval = 0;\n \tconst char *type = blob_type;\n+\tunsigned long size;\n \n \tif (S_ISDIRLNK(mode)) {\n \t\t/*\n@@ -92,13 +94,21 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,\n \t    (baselen < chomp_prefix || memcmp(ls_tree_prefix, base, chomp_prefix)))\n \t\treturn 0;\n \n-\tif (!(ls_options & LS_NAME_ONLY))\n-\t\tprintf(\"%06o %s %s\\t\", mode, type,\n-\t\t\t\tabbrev ? find_unique_abbrev(sha1,abbrev)\n-\t\t\t\t\t: sha1_to_hex(sha1));\n+\tif (!(ls_options & LS_NAME_ONLY)) {\n+\t\tif (ls_options & LS_SHOW_SIZE) {\n+\t\t\tsha1_object_info(sha1, &size);\n+\t\t\tprintf(\"%06o %s %s %7lu\\t\", mode, type,\n+\t\t\t       abbrev ? find_unique_abbrev(sha1, abbrev)\n+\t\t\t              : sha1_to_hex(sha1),\n+\t\t\t       size);\n+\t\t} else\n+\t\t\tprintf(\"%06o %s %s\\t\", mode, type,\n+\t\t\t       abbrev ? find_unique_abbrev(sha1, abbrev)\n+\t\t\t              : sha1_to_hex(sha1));\n+\t}\n \twrite_name_quoted(base + chomp_prefix, baselen - chomp_prefix,\n-\t\t\t  pathname,\n-\t\t\t  line_termination, stdout);\n+\t                  pathname,\n+\t                  line_termination, stdout);\n \tputchar(line_termination);\n \treturn retval;\n }\n@@ -126,12 +136,20 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)\n \t\tcase 't':\n \t\t\tls_options |= LS_SHOW_TREES;\n \t\t\tbreak;\n+\t\tcase 'l':\n+\t\t\tls_options |= LS_SHOW_SIZE;\n+\t\t\tbreak;\n \t\tcase '-':\n \t\t\tif (!strcmp(argv[1]+2, \"name-only\") ||\n \t\t\t    !strcmp(argv[1]+2, \"name-status\")) {\n \t\t\t\tls_options |= LS_NAME_ONLY;\n \t\t\t\tbreak;\n \t\t\t}\n+\t\t\tif (!strcmp(argv[1]+2, \"long\") ||\n+\t\t\t    !strcmp(argv[1]+2, \"size\")) {\n+\t\t\t\tls_options |= LS_SHOW_SIZE;\n+\t\t\t\tbreak;\n+\t\t\t}\n \t\t\tif (!strcmp(argv[1]+2, \"full-name\")) {\n \t\t\t\tchomp_prefix = 0;\n \t\t\t\tbreak;\n-- \n1.5.1.4\n"},{"id":"42241","messageId":"7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net","threadId":"8166","inReplyTo":"11792246701367-git-send-email-jnareb@gmail.com","subject":"Re: [PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-15T18:58:56Z","receivedAt":"2007-05-15T18:58:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Add -l/--long/--size option to git-ls-tree command, which displays\n> object size of an entry after object id (left-justified with minimum\n> width of 7 characters).\n\nNot a NAK at all (but not an ACK either yet), but just asking\nquestions on some design considerations.\n\n* Do these options do different things?  If not, why have more\n  than one (or two, --long and its shorthand -l)?\n\n* Why pad to 7 places?  Do we have a similar padding elsewhere?\n  Will this ever used by non-scripts?  How does this padding\n  affect parsers other than Perl that read this information?\n\n* Does it make sense to show size information when giving a tree\n  entry?  I realize not having it in the output would make the\n  job of the script reading the output a bit harder, but if this\n  output is meant also for human consumption I think it would\n  not be so interesting and raise a confusion factor.\n\n  Also I suspect that having to show the size of a tree object,\n  expressed in terms of the canonical representation, might\n  force packv4 aware ls-tree to convert its traversal efficient\n  representation to the canonical one only to get its size.\n"},{"id":"42259","messageId":"200705160119.10802.jnareb@gmail.com","threadId":"8166","inReplyTo":"7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-15T23:19:10Z","receivedAt":"2007-05-15T23:19:10Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n> > Add -l/--long/--size option to git-ls-tree command, which displays\n> > object size of an entry after object id (left-justified with minimum\n> > width of 7 characters).\n> \n> Not a NAK at all (but not an ACK either yet), but just asking\n> questions on some design considerations.\n\nI guess I should use [PATCH/RFC] for this patch...\n\n> * Do these options do different things?  If not, why have more\n>   than one (or two, --long and its shorthand -l)?\n\nThe idea was to have output similar (if possible by git-ls-tree\nmachinery) to 'ls -l' output, hence -l/--long, but actually it is\nabout --size.\n\n> * Why pad to 7 places?  Do we have a similar padding elsewhere?\n>   Will this ever used by non-scripts?  How does this padding\n>   affect parsers other than Perl that read this information?\n\nPadding is added here to make output more human-readable. And I guess\npadding of 7 places is default for 'ls -l'.\n\nBut certainly padding is not needed.\n\n> * Does it make sense to show size information when giving a tree\n>   entry?  I realize not having it in the output would make the\n>   job of the script reading the output a bit harder, but if this\n>   output is meant also for human consumption I think it would\n>   not be so interesting and raise a confusion factor.\n\nGiving tree size information is similar to 'ls -l giving size of\ndirectory, and not total size taken by its contents. That would be\nbetter left for git-ls-tree `--du' option :-)\n\n>   Also I suspect that having to show the size of a tree object,\n>   expressed in terms of the canonical representation, might\n>   force packv4 aware ls-tree to convert its traversal efficient\n>   representation to the canonical one only to get its size.\n\nIt still will be accessible, but perhaps it would be less efficient\nwith v4 pack. It is I think acceptable that -l needs more CPU (and I/O) \ntime...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"42260","messageId":"20070515232017.GP3141@spearce.org","threadId":"8166","inReplyTo":"7vy7jpj4lr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-15T23:20:17Z","receivedAt":"2007-05-15T23:20:17Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n> > Add -l/--long/--size option to git-ls-tree command, which displays\n> > object size of an entry after object id (left-justified with minimum\n> > width of 7 characters).\n> \n>   Also I suspect that having to show the size of a tree object,\n>   expressed in terms of the canonical representation, might\n>   force packv4 aware ls-tree to convert its traversal efficient\n>   representation to the canonical one only to get its size.\n\nYes, you are right Junio.  In pack v4 we don't know the size of\nthe canonical representation.  We compute it on the fly when its\nneeded by summing up the lengths of the names of each element in\nthe tree, so it requires us to expand the delta chain and is thus\nO(delta_depth * entry_count) or something like that.\n\nI didn't see this as a huge problem, as the only in-tree caller at\nthe time that needed the size and did not also want the canonical\nrepresentation was the -s flag to cat-file.\n\nSo I'm kind of against adding something that would want to print\nthat canonical representation for every subtree in a parent tree,\nas it would make either pack v4 less efficient for that operation\nor force it to store the canonical size, for no other good reason.\n\n-- \nShawn.\n"},{"id":"42272","messageId":"7vps51hacw.fsf@assigned-by-dhcp.cox.net","threadId":"8166","inReplyTo":"200705160119.10802.jnareb@gmail.com","subject":"Re: [PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T00:37:35Z","receivedAt":"2007-05-16T00:37:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Jakub Narebski <jnareb@gmail.com> writes:\n>> \n>> > Add -l/--long/--size option to git-ls-tree command, which displays\n>> > object size of an entry after object id (left-justified with minimum\n>> > width of 7 characters).\n>> \n>> Not a NAK at all (but not an ACK either yet), but just asking\n>> questions on some design considerations.\n>\n> I guess I should use [PATCH/RFC] for this patch...\n\nI do not see any need for that.  As far as I am concerned, all\nthe [PATCH] are RFCs ;-)\n\n>> * Do these options do different things?  If not, why have more\n>>   than one (or two, --long and its shorthand -l)?\n>\n> The idea was to have output similar (if possible by git-ls-tree\n> machinery) to 'ls -l' output, hence -l/--long, but actually it is\n> about --size.\n\n\"ls -l\" is about long (it is not \"long to show everything the\nsystem knows\", but \"longer than usual), so I think it is Ok to\nsay \"ls-tree -l\" and people would understand.\n\n>> * Why pad to 7 places?  Do we have a similar padding elsewhere?\n>>   Will this ever used by non-scripts?  How does this padding\n>>   affect parsers other than Perl that read this information?\n>\n> Padding is added here to make output more human-readable. And I guess\n> padding of 7 places is default for 'ls -l'.\n\nOk, \"it is to make the output also consumable more easily by\nhumans\" is a very reasonable answer.\n\n>>   Also I suspect that having to show the size of a tree object,\n>>   expressed in terms of the canonical representation, might\n>>   force packv4 aware ls-tree to convert its traversal efficient\n>>   representation to the canonical one only to get its size.\n>\n> It still will be accessible, but perhaps it would be less efficient\n> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O) \n> time...\n\nShawn answered this better than I could.  I am moderately\nnegative on the size of tree objects part.\n\nBut modulo these details, I agree that being able to get the\nsize of each blob would be useful.\n"},{"id":"42275","messageId":"200705160254.38463.jnareb@gmail.com","threadId":"8166","inReplyTo":"7vps51hacw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-16T00:54:37Z","receivedAt":"2007-05-16T00:54:37Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n>> Junio C Hamano wrote:\n\n>>>   Also I suspect that having to show the size of a tree object,\n>>>   expressed in terms of the canonical representation, might\n>>>   force packv4 aware ls-tree to convert its traversal efficient\n>>>   representation to the canonical one only to get its size.\n>>\n>> It still will be accessible, but perhaps it would be less efficient\n>> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O) \n>> time...\n> \n> Shawn answered this better than I could.  I am moderately\n> negative on the size of tree objects part.\n> \n> But modulo these details, I agree that being able to get the\n> size of each blob would be useful.\n\nWe can always return ' ', '-', or '0' as size for tree entries.\nI wonder what to do about commits/gitlinks/subprojects...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"42276","messageId":"7vabw5h8yb.fsf@assigned-by-dhcp.cox.net","threadId":"8166","inReplyTo":"200705160254.38463.jnareb@gmail.com","subject":"Re: [PATCH] Add an option to git-ls-tree to display also the size of object","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-16T01:07:56Z","receivedAt":"2007-05-16T01:07:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Jakub Narebski <jnareb@gmail.com> writes:\n>>> Junio C Hamano wrote:\n>\n>>>>   Also I suspect that having to show the size of a tree object,\n>>>>   expressed in terms of the canonical representation, might\n>>>>   force packv4 aware ls-tree to convert its traversal efficient\n>>>>   representation to the canonical one only to get its size.\n>>>\n>>> It still will be accessible, but perhaps it would be less efficient\n>>> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O) \n>>> time...\n>> \n>> Shawn answered this better than I could.  I am moderately\n>> negative on the size of tree objects part.\n>> \n>> But modulo these details, I agree that being able to get the\n>> size of each blob would be useful.\n>\n> We can always return ' ', '-', or '0' as size for tree entries.\n> I wonder what to do about commits/gitlinks/subprojects...\n\nThe same \"the size of this type of object is not given\", I would\nsay.\n"},{"id":"42656","messageId":"200705192208.11905.jnareb@gmail.com","threadId":"8166","inReplyTo":"7vps51hacw.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH v2] Add an option to git-ls-tree to display also the size of blob","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-19T20:08:11Z","receivedAt":"2007-05-19T20:08:11Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Add -l/--long option to git-ls-tree command, which displays\nobject size of a blob entry.  Object size is placed after\nobject id (left-justified with minimum width of 7 characters).\nFor non-blob entries `-' is used.\n\nRationale: for non-blob entries size of an object has no much\nmeaning, and is not very interesting.  Moreover, in planned\npack v4 tree objects would be constructed on demand, so tree\nsize would need to be calculated... although isn't object size\nstored in the header?\n\nWhile at it, cleanup whitespace: tabs are for indent, spaces are\nfor align.\n\nSigned-off-by: Jakub Narebski <jnareb@gmail.com>\n---\nI hope this addresses concerns mentioned in this thread: the\nalternate name --size for -l/--long option, and showing size\nfor tree (and commit/submodule) objects.\n\n Documentation/git-ls-tree.txt |   14 +++++++++++++-\n builtin-ls-tree.c             |   39 +++++++++++++++++++++++++++++++--------\n 2 files changed, 44 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt\nindex 7899394..ad7f1b9 100644\n--- a/Documentation/git-ls-tree.txt\n+++ b/Documentation/git-ls-tree.txt\n@@ -9,7 +9,7 @@ git-ls-tree - List the contents of a tree object\n SYNOPSIS\n --------\n [verse]\n-'git-ls-tree' [-d] [-r] [-t] [-z]\n+'git-ls-tree' [-d] [-r] [-t] [-l] [-z]\n \t    [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]\n \t    <tree-ish> [paths...]\n \n@@ -36,6 +36,10 @@ OPTIONS\n \tShow tree entries even when going to recurse them. Has no effect\n \tif '-r' was not passed. '-d' implies '-t'.\n \n+-l::\n+--long::\n+\tShow object size of blob (file) entries.\n+\n -z::\n \t\\0 line termination on output.\n \n@@ -65,6 +69,14 @@ Output Format\n When the `-z` option is not used, TAB, LF, and backslash characters\n in pathnames are represented as `\\t`, `\\n`, and `\\\\`, respectively.\n \n+When the `-l` option is used, format changes to\n+\n+        <mode> SP <type> SP <object> SP <object size> TAB <file>\n+\n+Object size identified by <object> is given in bytes, and right-justified\n+with minimum width of 7 characters.  Object size is given only for blobs\n+(file) entries; for other entries `-` character is used in place of size.\n+\n \n Author\n ------\ndiff --git a/builtin-ls-tree.c b/builtin-ls-tree.c\nindex 1cb4dca..1d2dc40 100644\n--- a/builtin-ls-tree.c\n+++ b/builtin-ls-tree.c\n@@ -15,6 +15,7 @@ static int line_termination = '\\n';\n #define LS_TREE_ONLY 2\n #define LS_SHOW_TREES 4\n #define LS_NAME_ONLY 8\n+#define LS_SHOW_SIZE 16\n static int abbrev;\n static int ls_options;\n static const char **pathspec;\n@@ -22,7 +23,7 @@ static int chomp_prefix;\n static const char *ls_tree_prefix;\n \n static const char ls_tree_usage[] =\n-\t\"git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]\";\n+\t\"git-ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]\";\n \n static int show_recursive(const char *base, int baselen, const char *pathname)\n {\n@@ -55,10 +56,11 @@ static int show_recursive(const char *base, int baselen, const char *pathname)\n }\n \n static int show_tree(const unsigned char *sha1, const char *base, int baselen,\n-\t\t     const char *pathname, unsigned mode, int stage)\n+                     const char *pathname, unsigned mode, int stage)\n {\n \tint retval = 0;\n \tconst char *type = blob_type;\n+\tunsigned long size;\n \n \tif (S_ISDIRLNK(mode)) {\n \t\t/*\n@@ -92,13 +94,27 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,\n \t    (baselen < chomp_prefix || memcmp(ls_tree_prefix, base, chomp_prefix)))\n \t\treturn 0;\n \n-\tif (!(ls_options & LS_NAME_ONLY))\n-\t\tprintf(\"%06o %s %s\\t\", mode, type,\n-\t\t\t\tabbrev ? find_unique_abbrev(sha1,abbrev)\n-\t\t\t\t\t: sha1_to_hex(sha1));\n+\tif (!(ls_options & LS_NAME_ONLY)) {\n+\t\tif (ls_options & LS_SHOW_SIZE) {\n+\t\t\tif (!strcmp(type, blob_type)) {\n+\t\t\t\tsha1_object_info(sha1, &size);\n+\t\t\t\tprintf(\"%06o %s %s %7lu\\t\", mode, type,\n+\t\t\t\t       abbrev ? find_unique_abbrev(sha1, abbrev)\n+\t\t\t\t              : sha1_to_hex(sha1),\n+\t\t\t\t       size);\n+\t\t\t} else\n+\t\t\t\tprintf(\"%06o %s %s %7c\\t\", mode, type,\n+\t\t\t\t       abbrev ? find_unique_abbrev(sha1, abbrev)\n+\t\t\t\t              : sha1_to_hex(sha1),\n+\t\t\t\t       '-');\n+\t\t} else\n+\t\t\tprintf(\"%06o %s %s\\t\", mode, type,\n+\t\t\t       abbrev ? find_unique_abbrev(sha1, abbrev)\n+\t\t\t              : sha1_to_hex(sha1));\n+\t}\n \twrite_name_quoted(base + chomp_prefix, baselen - chomp_prefix,\n-\t\t\t  pathname,\n-\t\t\t  line_termination, stdout);\n+\t                  pathname,\n+\t                  line_termination, stdout);\n \tputchar(line_termination);\n \treturn retval;\n }\n@@ -126,12 +142,19 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)\n \t\tcase 't':\n \t\t\tls_options |= LS_SHOW_TREES;\n \t\t\tbreak;\n+\t\tcase 'l':\n+\t\t\tls_options |= LS_SHOW_SIZE;\n+\t\t\tbreak;\n \t\tcase '-':\n \t\t\tif (!strcmp(argv[1]+2, \"name-only\") ||\n \t\t\t    !strcmp(argv[1]+2, \"name-status\")) {\n \t\t\t\tls_options |= LS_NAME_ONLY;\n \t\t\t\tbreak;\n \t\t\t}\n+\t\t\tif (!strcmp(argv[1]+2, \"long\")) {\n+\t\t\t\tls_options |= LS_SHOW_SIZE;\n+\t\t\t\tbreak;\n+\t\t\t}\n \t\t\tif (!strcmp(argv[1]+2, \"full-name\")) {\n \t\t\t\tchomp_prefix = 0;\n \t\t\t\tbreak;\n-- \n1.5.1.4\n"},{"id":"42669","messageId":"20070520035407.GF3141@spearce.org","threadId":"8166","inReplyTo":"200705192208.11905.jnareb@gmail.com","subject":"Re: [PATCH v2] Add an option to git-ls-tree to display also the size of blob","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-20T03:54:07Z","receivedAt":"2007-05-20T03:54:07Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> wrote:\n> Rationale: for non-blob entries size of an object has no much\n> meaning, and is not very interesting.  Moreover, in planned\n> pack v4 tree objects would be constructed on demand, so tree\n> size would need to be calculated... although isn't object size\n> stored in the header?\n\nYes and no.  In pack v4 the object sizes stored within the packfile\nare more about what we need to know in order to efficiently unpack\nthe object than about supplying the canonical format length.  If a\nvalue is redundant, we don't store it.  The canonical format length\nis almost always redundant.\n\nFor blobs we still need the raw data length to unpack efficiently,\nand hence we have the blob's canonical size readily available.\nFor trees its actually more the tree entry record count, as that\nis all we need to know in order to recover the tree.  For commits\nwe don't even need a length, but we instead have the number of\nparent commits.\n\nSince pack v4 is really about faster runtime decoding our ability\nto reproduce canonical encoding of objects is reduced slightly.\nI think that's OK as we actually only need the canonical encoding\ninfrequently (index-pack during network transfer, cat-file) and\nwe're not really considering pack v4 for network transfer.  Yet.\n \n> I hope this addresses concerns mentioned in this thread: the\n> alternate name --size for -l/--long option, and showing size\n> for tree (and commit/submodule) objects.\n\nYes, thanks!\n\n-- \nShawn.\n"}]}