{"thread":{"id":"10605","subject":"[PATCH] git-fetch: more terse fetch output","startedAt":"2007-11-03T05:32:48Z","lastAt":"2007-11-04T14:01:03Z","messageCount":20,"participants":["Nicolas Pitre","Junio C Hamano","Linus Torvalds","Mike Hommey","Pierre Habouzit","Jakub Narebski","Johannes Schindelin","David Brown","Robin Rosenberg","Jeff King","Steffen Prohaska"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"58069","messageId":"alpine.LFD.0.9999.0711030101340.21255@xanadu.home","threadId":"10605","inReplyTo":null,"subject":"[PATCH] git-fetch: more terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-03T05:32:48Z","receivedAt":"2007-11-03T05:32:48Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\nThis makes the fetch output much more terse and prettier on a 80 column \ndisplay, based on a consensus reached on the mailing list. Here's an \nexample output:\n\nReceiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\nResolving deltas: 100% (4604/4604), done.\nFrom git://git.kernel.org/pub/scm/git/git\n ! [rejected] html -> origin/html (non fast forward)\n 136e631..f45e867 maint -> origin/maint (fast forward)\n 9850e2e..44dd7e0 man -> origin/man (fast forward)\n 3e4bb08..e3d6d56 master -> origin/master (fast forward)\n fa3665c..536f64a next -> origin/next (fast forward)\n + 4f6d9d6...768326f pu -> origin/pu (forced update)\n * [new branch] todo -> origin/todo\n\nSome portions of this patch have been extracted from earlier proposals\nby Jeff King and Shawn Pearce.\n\nSigned-off-by: Nicolas Pitre \n---\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 003ed76..960b1da 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -131,12 +131,6 @@ static struct ref *get_ref_map(struct transport *transport,\n \treturn ref_map;\n }\n \n-static void show_new(enum object_type type, unsigned char *sha1_new)\n-{\n-\tfprintf(stderr, \" %s: %s\\n\", typename(type),\n-\t\tfind_unique_abbrev(sha1_new, DEFAULT_ABBREV));\n-}\n-\n static int s_update_ref(const char *action,\n \t\t\tstruct ref *ref,\n \t\t\tint check_old)\n@@ -157,34 +151,38 @@ static int s_update_ref(const char *action,\n \treturn 0;\n }\n \n+#define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)\n+\n static int update_local_ref(struct ref *ref,\n-\t\t\t const char *note,\n-\t\t\t int verbose)\n+\t\t\t const char *remote,\n+\t\t\t int verbose,\n+\t\t\t char *display)\n {\n-\tchar oldh[41], newh[41];\n \tstruct commit *current = NULL, *updated;\n \tenum object_type type;\n \tstruct branch *current_branch = branch_get(NULL);\n+\tconst char *pretty_ref = ref->name + (\n+\t\t!prefixcmp(ref->name, \"refs/heads/\") ? 11 :\n+\t\t!prefixcmp(ref->name, \"refs/tags/\") ? 10 :\n+\t\t!prefixcmp(ref->name, \"refs/remotes/\") ? 13 :\n+\t\t0);\n \n+\t*display = 0;\n \ttype = sha1_object_info(ref->new_sha1, NULL);\n \tif (type < 0)\n \t\tdie(\"object %s not found\", sha1_to_hex(ref->new_sha1));\n \n \tif (!*ref->name) {\n \t\t/* Not storing */\n-\t\tif (verbose) {\n-\t\t\tfprintf(stderr, \"* fetched %s\\n\", note);\n-\t\t\tshow_new(type, ref->new_sha1);\n-\t\t}\n+\t\tif (verbose)\n+\t\t\tsprintf(display, \"* branch %s -> FETCH_HEAD\", remote);\n \t\treturn 0;\n \t}\n \n \tif (!hashcmp(ref->old_sha1, ref->new_sha1)) {\n-\t\tif (verbose) {\n-\t\t\tfprintf(stderr, \"* %s: same as %s\\n\",\n-\t\t\t\tref->name, note);\n-\t\t\tshow_new(type, ref->new_sha1);\n-\t\t}\n+\t\tif (verbose)\n+\t\t\tsprintf(display, \"= %-*s %s -> %s\", SUMMARY_WIDTH,\n+\t\t\t\t\"[up to date]\", remote, pretty_ref);\n \t\treturn 0;\n \t}\n \n@@ -196,63 +194,65 @@ static int update_local_ref(struct ref *ref,\n \t\t * If this is the head, and it's not okay to update\n \t\t * the head, and the old value of the head isn't empty...\n \t\t */\n-\t\tfprintf(stderr,\n-\t\t\t\" * %s: Cannot fetch into the current branch.\\n\",\n-\t\t\tref->name);\n+\t\tsprintf(display, \"! %-*s %s -> %s (can't fetch in current branch)\",\n+\t\t\tSUMMARY_WIDTH, \"[rejected]\", remote, pretty_ref);\n \t\treturn 1;\n \t}\n \n \tif (!is_null_sha1(ref->old_sha1) &&\n \t !prefixcmp(ref->name, \"refs/tags/\")) {\n-\t\tfprintf(stderr, \"* %s: updating with %s\\n\",\n-\t\t\tref->name, note);\n-\t\tshow_new(type, ref->new_sha1);\n+\t\tsprintf(display, \"- %-*s %s -> %s\",\n+\t\t\tSUMMARY_WIDTH, \"[tag update]\", remote, pretty_ref);\n \t\treturn s_update_ref(\"updating tag\", ref, 0);\n \t}\n \n \tcurrent = lookup_commit_reference_gently(ref->old_sha1, 1);\n \tupdated = lookup_commit_reference_gently(ref->new_sha1, 1);\n \tif (!current || !updated) {\n-\t\tchar *msg;\n-\t\tif (!strncmp(ref->name, \"refs/tags/\", 10))\n+\t\tconst char *msg;\n+\t\tconst char *what;\n+\t\tif (!strncmp(ref->name, \"refs/tags/\", 10)) {\n \t\t\tmsg = \"storing tag\";\n-\t\telse\n+\t\t\twhat = \"[new tag]\";\n+\t\t}\n+\t\telse {\n \t\t\tmsg = \"storing head\";\n-\t\tfprintf(stderr, \"* %s: storing %s\\n\",\n-\t\t\tref->name, note);\n-\t\tshow_new(type, ref->new_sha1);\n+\t\t\twhat = \"[new branch]\";\n+\t\t}\n+\n+\t\tsprintf(display, \"* %-*s %s -> %s\",\n+\t\t\tSUMMARY_WIDTH, what, remote, pretty_ref);\n \t\treturn s_update_ref(msg, ref, 0);\n \t}\n \n-\tstrcpy(oldh, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n-\tstrcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n-\n \tif (in_merge_bases(current, &updated, 1)) {\n-\t\tfprintf(stderr, \"* %s: fast forward to %s\\n\",\n-\t\t\tref->name, note);\n-\t\tfprintf(stderr, \" old..new: %s..%s\\n\", oldh, newh);\n+\t\tchar quickref[83];\n+\t\tstrcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n+\t\tstrcat(quickref, \"..\");\n+\t\tstrcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n+\t\tsprintf(display, \" %-*s %s -> %s (fast forward)\",\n+\t\t\tSUMMARY_WIDTH, quickref, remote, pretty_ref);\n \t\treturn s_update_ref(\"fast forward\", ref, 1);\n-\t}\n-\tif (!force && !ref->force) {\n-\t\tfprintf(stderr,\n-\t\t\t\"* %s: not updating to non-fast forward %s\\n\",\n-\t\t\tref->name, note);\n-\t\tfprintf(stderr,\n-\t\t\t\" old...new: %s...%s\\n\", oldh, newh);\n+\t} else if (force || ref->force) {\n+\t\tchar quickref[84];\n+\t\tstrcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n+\t\tstrcat(quickref, \"...\");\n+\t\tstrcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n+\t\tsprintf(display, \"+ %-*s %s -> %s (forced update)\",\n+\t\t\tSUMMARY_WIDTH, quickref, remote, pretty_ref);\n+\t\treturn s_update_ref(\"forced-update\", ref, 1);\n+\t} else {\n+\t\tsprintf(display, \"! %-*s %s -> %s (non fast forward)\",\n+\t\t\tSUMMARY_WIDTH, \"[rejected]\", remote, pretty_ref);\n \t\treturn 1;\n \t}\n-\tfprintf(stderr,\n-\t\t\"* %s: forcing update to non-fast forward %s\\n\",\n-\t\tref->name, note);\n-\tfprintf(stderr, \" old...new: %s...%s\\n\", oldh, newh);\n-\treturn s_update_ref(\"forced-update\", ref, 1);\n }\n \n static void store_updated_refs(const char *url, struct ref *ref_map)\n {\n \tFILE *fp;\n \tstruct commit *commit;\n-\tint url_len, i, note_len;\n+\tint url_len, i, note_len, shown_url = 0;\n \tchar note[1024];\n \tconst char *what, *kind;\n \tstruct ref *rm;\n@@ -315,8 +315,17 @@ static void store_updated_refs(const char *url, struct ref *ref_map)\n \t\t\trm->merge ? \"\" : \"not-for-merge\",\n \t\t\tnote);\n \n-\t\tif (ref)\n-\t\t\tupdate_local_ref(ref, note, verbose);\n+\t\tif (ref) {\n+\t\t\tupdate_local_ref(ref, what, verbose, note);\n+\t\t\tif (*note) {\n+\t\t\t\tif (!shown_url) {\n+\t\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n+\t\t\t\t\t\t\turl_len, url);\n+\t\t\t\t\tshown_url = 1;\n+\t\t\t\t}\n+\t\t\t\tfprintf(stderr, \" %s\\n\", note);\n+\t\t\t}\n+\t\t}\n \t}\n \tfclose(fp);\n }\n@@ -376,9 +385,6 @@ static struct ref *find_non_local_tags(struct transport *transport,\n \t\tif (!path_list_has_path(&existing_refs, ref_name) &&\n \t\t !path_list_has_path(&new_refs, ref_name) &&\n \t\t lookup_object(ref->old_sha1)) {\n-\t\t\tfprintf(stderr, \"Auto-following %s\\n\",\n-\t\t\t\tref_name);\n-\n \t\t\tpath_list_insert(ref_name, &new_refs);\n \n \t\t\trm = alloc_ref(strlen(ref_name) + 1);\n"},{"id":"58070","messageId":"7vtzo3yjp7.fsf@gitster.siamese.dyndns.org","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711030101340.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-03T05:36:04Z","receivedAt":"2007-11-03T05:36:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> This makes the fetch output much more terse and prettier on a 80 column \n> display, based on a consensus reached on the mailing list. Here's an \n> example output:\n>\n> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> Resolving deltas: 100% (4604/4604), done.\n> From git://git.kernel.org/pub/scm/git/git\n> ! [rejected] html -> origin/html (non fast forward)\n> 136e631..f45e867 maint -> origin/maint (fast forward)\n> 9850e2e..44dd7e0 man -> origin/man (fast forward)\n> 3e4bb08..e3d6d56 master -> origin/master (fast forward)\n> fa3665c..536f64a next -> origin/next (fast forward)\n> + 4f6d9d6...768326f pu -> origin/pu (forced update)\n> * [new branch] todo -> origin/todo\n\nYay!\n"},{"id":"58166","messageId":"alpine.LFD.0.999.0711031229470.15101@woody.linux-foundation.org","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711030101340.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-03T19:34:37Z","receivedAt":"2007-11-03T19:34:37Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 3 Nov 2007, Nicolas Pitre wrote:\n> \n> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n\nI mostly like this, but can we please just use \"MB/kB\" instead of \n\"MiB/KiB\"?\n\nI hope it was some kind of joke on crazy EU bureaucrats that just wasn't \ncaught in time.\n\nI also get the glitch, ie\n\n\tremote: Total 118 (delta 86), reused 112 (delta 86)iB/s\n\nwhere that \"iB/s\" remains as garbage from the previous line: we use \nhardcoded vt100 sequences for colorization, and nobody has complained yet, \nso maybe we should just do the same for \"reset and clear to end of line\"?\n\nOr maybe just add a few spaces. Using kB/MB instead of KiB/MiB will make \nit a few less characters to overwrite too.\n\n\t\tLinus\n"},{"id":"58172","messageId":"alpine.LFD.0.9999.0711031627000.21255@xanadu.home","threadId":"10605","inReplyTo":"alpine.LFD.0.999.0711031229470.15101@woody.linux-foundation.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-03T20:30:27Z","receivedAt":"2007-11-03T20:30:27Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 3 Nov 2007, Linus Torvalds wrote:\n\n> \n> \n> On Sat, 3 Nov 2007, Nicolas Pitre wrote:\n> > \n> > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> \n> I mostly like this, but can we please just use \"MB/kB\" instead of \n> \"MiB/KiB\"?\n> \n> I hope it was some kind of joke on crazy EU bureaucrats that just wasn't \n> caught in time.\n\nI don't care either ways. In fact my own preference is for MB/kB, but \nif I had used that first I'm sure someone else would have asked for the \npurist notations.\n\n\nNicolas\n"},{"id":"58175","messageId":"20071103204000.GA24959@glandium.org","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711031627000.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-03T20:40:00Z","receivedAt":"2007-11-03T20:40:00Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:\n> On Sat, 3 Nov 2007, Linus Torvalds wrote:\n> \n> > \n> > \n> > On Sat, 3 Nov 2007, Nicolas Pitre wrote:\n> > > \n> > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> > \n> > I mostly like this, but can we please just use \"MB/kB\" instead of \n> > \"MiB/KiB\"?\n> > \n> > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't \n> > caught in time.\n> \n> I don't care either ways. In fact my own preference is for MB/kB, but \n> if I had used that first I'm sure someone else would have asked for the \n> purist notations.\n\nAs far as you don't claim 1MB is 1024KB, it's okay.\n\nMike\n"},{"id":"58176","messageId":"alpine.LFD.0.9999.0711031645350.21255@xanadu.home","threadId":"10605","inReplyTo":"20071103204000.GA24959@glandium.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-03T20:50:54Z","receivedAt":"2007-11-03T20:50:54Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 3 Nov 2007, Mike Hommey wrote:\n\n> On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:\n> > On Sat, 3 Nov 2007, Linus Torvalds wrote:\n> > \n> > > \n> > > \n> > > On Sat, 3 Nov 2007, Nicolas Pitre wrote:\n> > > > \n> > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> > > \n> > > I mostly like this, but can we please just use \"MB/kB\" instead of \n> > > \"MiB/KiB\"?\n> > > \n> > > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't \n> > > caught in time.\n> > \n> > I don't care either ways. In fact my own preference is for MB/kB, but \n> > if I had used that first I'm sure someone else would have asked for the \n> > purist notations.\n> \n> As far as you don't claim 1MB is 1024KB, it's okay.\n\n[ heh, I knew someone would say something ]\n\nYes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk \nmanufacturers decided to redefine the common interpretation of what \neveryone else used to consider what a MB is just to boost their \nmarketing claims.\n\n\nNicolas\n"},{"id":"58178","messageId":"20071103210321.GA25685@glandium.org","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711031645350.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-03T21:03:21Z","receivedAt":"2007-11-03T21:03:21Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote:\n> [ heh, I knew someone would say something ]\n> \n> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk \n> manufacturers decided to redefine the common interpretation of what \n> everyone else used to consider what a MB is just to boost their \n> marketing claims.\n\nHow many grams in a kilogram ? How many meters in a kilometer ? How many\njoule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...\n\nAnd you know what ? It's not only a matter of hard disk manufacturers.\n\nHow fast is gigabit ethernet ? Yep, 1000000000 bits/s\nHow big would people say a 44000000 bytes file is ? 44MB or 42MB ?\nAnd my favourite: How many bytes in a 1.44MB floppy disk ? 1474560, that\nis, 1.44 * 1024000.\n\nThose who made this big mess are the ones who decided a KB was 1024\nbytes, not the others.\n\nMike\n"},{"id":"58180","messageId":"20071103214602.GF13417@artemis.corp","threadId":"10605","inReplyTo":"20071103210321.GA25685@glandium.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-03T21:46:02Z","receivedAt":"2007-11-03T21:46:02Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sat, Nov 03, 2007 at 09:03:21PM +0000, Mike Hommey wrote:\n> Those who made this big mess are the ones who decided a KB was 1024\n> bytes, not the others.\n\n Oooh noes, we already had that discussion on debian-devel@ a few month\nago, could we _please_ spare it :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58182","messageId":"fgir54$7ft$1@ger.gmane.org","threadId":"10605","inReplyTo":"20071103210321.GA25685@glandium.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-03T22:02:16Z","receivedAt":"2007-11-03T22:02:16Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Mike Hommey wrote:\n\n> On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote:\n>> [ heh, I knew someone would say something ]\n>> \n>> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk \n>> manufacturers decided to redefine the common interpretation of what \n>> everyone else used to consider what a MB is just to boost their \n>> marketing claims.\n> \n> How many grams in a kilogram ? How many meters in a kilometer ? How many\n> joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...\n> \n> And you know what ? It's not only a matter of hard disk manufacturers.\n> \n> How fast is gigabit ethernet ? Yep, 1000000000 bits/s\n> How big would people say a 44000000 bytes file is ? 44MB or 42MB ?\n> And my favourite: How many bytes in a 1.44MB floppy disk ? 1474560, that\n> is, 1.44 * 1024000.\n> \n> Those who made this big mess are the ones who decided a KB was 1024\n> bytes, not the others.\n\nNo, the problem is that in _computer science_ kB (or KB) was 1024 bytes,\nand MB was 1024 kilobytes, because 1024 is a power of 2, and for example\nnaturally the memory which can be adressed comes as a power of 2.\n\nNow in other parts of science k means 1000, and M means 1000000. To make\nthe computer sciences meaning of kB explicit SI introduced ki and Mi prefix.\nAnd manufacturers claiming HDD size x GB in the SI meaning took part...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"58185","messageId":"alpine.LFD.0.999.0711031542010.15101@woody.linux-foundation.org","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711031645350.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-03T22:45:47Z","receivedAt":"2007-11-03T22:45:47Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 3 Nov 2007, Nicolas Pitre wrote:\n>\n> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk \n> manufacturers decided to redefine the common interpretation of what \n> everyone else used to consider what a MB is just to boost their \n> marketing claims.\n\nActually, they just lost even that in a lawsuit (yeah, they \"settled\").\n\nThe fact is, 1MB = 1024kB = 1048576 bytes.\n\nAnybody who claims anything else is a lying piece of pondscum, trying to \njust fool people into paying more for less.\n\nWhich is why you should *not* use MiB and KiB - it only validates the \npondscum.\n\n\t\t\tLinus\n"},{"id":"58186","messageId":"alpine.LFD.0.999.0711031546110.15101@woody.linux-foundation.org","threadId":"10605","inReplyTo":"20071103210321.GA25685@glandium.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-03T22:48:42Z","receivedAt":"2007-11-03T22:48:42Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 3 Nov 2007, Mike Hommey wrote:\n> \n> How many grams in a kilogram ? How many meters in a kilometer ? How many\n> joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...\n\nHow many 'u's in the word \"colour\"?\n\nOh, wait - it depends on context, doesn't it?\n\nkB is 1024 bytes. The fact that \"k\" means something else in other contexts \nis simply irrelevant.\n\n\t\t\tLinus\n"},{"id":"58187","messageId":"20071103233144.GA16734@glandium.org","threadId":"10605","inReplyTo":"alpine.LFD.0.999.0711031546110.15101@woody.linux-foundation.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-03T23:31:44Z","receivedAt":"2007-11-03T23:31:44Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote:\n> \n> \n> On Sat, 3 Nov 2007, Mike Hommey wrote:\n> > \n> > How many grams in a kilogram ? How many meters in a kilometer ? How many\n> > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...\n> \n> How many 'u's in the word \"colour\"?\n> \n> Oh, wait - it depends on context, doesn't it?\n> \n> kB is 1024 bytes. The fact that \"k\" means something else in other contexts \n> is simply irrelevant.\n\nWhat about the fact that \"kB\" means different things depending whether it's\nused for bandwidth or memory capacity ?\nDoes your brain have base 2 hard-coded so that you instantly know 50000000\nbytes are 47.68MB ? Are people unable to do so pondscum ?\n\nMike\n"},{"id":"58195","messageId":"Pine.LNX.4.64.0711040050430.4362@racer.site","threadId":"10605","inReplyTo":"20071103233144.GA16734@glandium.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-04T00:54:55Z","receivedAt":"2007-11-04T00:54:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 4 Nov 2007, Mike Hommey wrote:\n\n> On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote:\n> > \n> > \n> > On Sat, 3 Nov 2007, Mike Hommey wrote:\n> > > \n> > > How many grams in a kilogram ? How many meters in a kilometer ? How many\n> > > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...\n> > \n> > How many 'u's in the word \"colour\"?\n> > \n> > Oh, wait - it depends on context, doesn't it?\n> > \n> > kB is 1024 bytes. The fact that \"k\" means something else in other \n> > contexts is simply irrelevant.\n> \n> What about the fact that \"kB\" means different things depending whether \n> it's used for bandwidth or memory capacity ?\n>\n> Does your brain have base 2 hard-coded so that you instantly know \n> 50000000 bytes are 47.68MB ? Are people unable to do so pondscum ?\n\nGet over it. kB is not the same as km. It really means something \ndifferent. And all all people who actually _understand_ something of the \nmatter know what a kilobyte is.\n\nJust because some _wankers_^Wbureaucrats decided to make life hard on \nthose people who have actually a _clue_ on real life, does not mean that \nwe have to accept it.\n\n1kB = 1024 bytes.\n\n1MB = 1024*1024 bytes.\n\nEverybody who claims anything else is just an annoyance to the rest of the \nworld, who is not clueless, thank you very much.\n\nAnd hard disk manufacturers be damned, and should burn in hell.\n\nCiao,\nDscho\n"},{"id":"58196","messageId":"7v1wb6yg8d.fsf@gitster.siamese.dyndns.org","threadId":"10605","inReplyTo":"Pine.LNX.4.64.0711040050430.4362@racer.site","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-04T01:03:14Z","receivedAt":"2007-11-04T01:03:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> 1kB = 1024 bytes.\n>\n> 1MB = 1024*1024 bytes.\n>\n> Everybody who claims anything else is just an annoyance to the rest of the \n> world, who is not clueless, thank you very much.\n>\n> And hard disk manufacturers be damned, and should burn in hell.\n\nDon't blame the hard disk people too harshly. The insanity\ndates back to floppy disk days, where they marketted 1440kB\ndisks as 1.44MB.\n\nI wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal\nbytes. I am too lazy to check ;-)\n"},{"id":"58197","messageId":"20071104014930.GA27392@old.davidb.org","threadId":"10605","inReplyTo":"7v1wb6yg8d.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-11-04T01:49:30Z","receivedAt":"2007-11-04T01:49:30Z","isPatch":true,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sat, Nov 03, 2007 at 06:03:14PM -0700, Junio C Hamano wrote:\n\n>I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal\n>bytes. I am too lazy to check ;-)\n\nOf course. A certain magneto optical manufacturer created a 605MB drive,\nwhich they marked as 640MB, trying to make it sound like it had the same\ncapacity as a CD. Even with 1,000 bytes 634,388,480 is quite a stretch to\ncall 640MB. I never found the footnote \"____ defines megabyte to be 991232\nbytes\".\n\nDave\n"},{"id":"58198","messageId":"200711040314.36668.robin.rosenberg@dewire.com","threadId":"10605","inReplyTo":"20071104014930.GA27392@old.davidb.org","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-11-04T02:14:34Z","receivedAt":"2007-11-04T02:14:34Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 04 november 2007 skrev David Brown:\n> On Sat, Nov 03, 2007 at 06:03:14PM -0700, Junio C Hamano wrote:\n> \n> >I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal\n> >bytes. I am too lazy to check ;-)\n> \n> Of course. A certain magneto optical manufacturer created a 605MB drive,\n> which they marked as 640MB, trying to make it sound like it had the same\n> capacity as a CD. Even with 1,000 bytes 634,388,480 is quite a stretch to\n> call 640MB. I never found the footnote \"____ defines megabyte to be 991232\n> bytes\".\n\nThey may have used the term \"unformatted\" capacity.\n\n-- robin\n"},{"id":"58212","messageId":"20071104045800.GB12359@segfault.peff.net","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711030101340.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-04T04:58:00Z","receivedAt":"2007-11-04T04:58:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote:\n\n> This makes the fetch output much more terse and prettier on a 80 column \n> display, based on a consensus reached on the mailing list. Here's an \n> example output:\n\nThank you for this; it was at the end of a very long todo list for me.\n\n> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> Resolving deltas: 100% (4604/4604), done.\n> From git://git.kernel.org/pub/scm/git/git\n> ! [rejected] html -> origin/html (non fast forward)\n> 136e631..f45e867 maint -> origin/maint (fast forward)\n> 9850e2e..44dd7e0 man -> origin/man (fast forward)\n> 3e4bb08..e3d6d56 master -> origin/master (fast forward)\n> fa3665c..536f64a next -> origin/next (fast forward)\n> + 4f6d9d6...768326f pu -> origin/pu (forced update)\n> * [new branch] todo -> origin/todo\n\nOne nice thing about this format is that it works equally well for\n\"push\" (changing \"From\" to \"To\" and reversing the order of the\nbranches). Comments?\n\n-Peff\n"},{"id":"58237","messageId":"EB9F9DF7-0D71-4542-9049-5C0942304076@zib.de","threadId":"10605","inReplyTo":"alpine.LFD.0.9999.0711031645350.21255@xanadu.home","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-04T09:56:40Z","receivedAt":"2007-11-04T09:56:40Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 3, 2007, at 9:50 PM, Nicolas Pitre wrote:\n\n> On Sat, 3 Nov 2007, Mike Hommey wrote:\n>\n>> On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:\n>>> On Sat, 3 Nov 2007, Linus Torvalds wrote:\n>>>\n>>>>\n>>>>\n>>>> On Sat, 3 Nov 2007, Nicolas Pitre wrote:\n>>>>>\n>>>>> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n>>>>\n>>>> I mostly like this, but can we please just use \"MB/kB\" instead of\n>>>> \"MiB/KiB\"?\n>>>>\n>>>> I hope it was some kind of joke on crazy EU bureaucrats that \n>>>> just wasn't\n>>>> caught in time.\n>>>\n>>> I don't care either ways. In fact my own preference is for MB/ \n>>> kB, but\n>>> if I had used that first I'm sure someone else would have asked \n>>> for the\n>>> purist notations.\n>>\n>> As far as you don't claim 1MB is 1024KB, it's okay.\n>\n> [ heh, I knew someone would say something ]\n>\n> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard \n> disk\n> manufacturers decided to redefine the common interpretation of what\n> everyone else used to consider what a MB is just to boost their\n> marketing claims.\n\nI believe it doesn't matter what prefix we use for a\n_progress indicator_, as long as we use the same prefix for\nthe the amount already transferred and the bandwidth. A precise\nlanguage doesn't matter here.\n\nHere is a short excerpt from a discussion of the standard.\nI haven't downloaded the full document \"IEEE Trial-Use Standard\nfor Prefixes for Binary Multiples\" but copied from Wikipedia :\n\n\n“This standard is prepared with two goals in mind: (1) to\npreserve the SI prefixes as unambiguous decimal multipliers and\n(2) to provide alternative prefixes for those cases where binary\nmultipliers are needed. The first goal affects the general\npublic, the wide audience of technical and nontechnical persons\nwho use computers without much concern for their construction\nor inner working. These persons will normally interpret kilo,\nmega, etc., in their proper decimal sense. The second goal\nspeaks to specialists—the prefixes for binary multiples make\nit possible for persons who work in the information sciences\nto communicate with precision.”\n\n\nBinary multiplier make it possible to communicate with\nprecision. If you use the binary prefixes it is absolutely\nclear what you are talking about. The meaning of the old\nprefixes depend on the context.\n\nBut all this does not matter here. We are talking about a\nprogress indicator. Precision doesn't matter. The user wants\nto be sure that something is happening and get an idea of how\nmuch longer it will take to finish the fetch. An approximation\nis sufficient.\n\nWhat matters though is saving two characters, because the line\nwidth is limited. So lets take \"MB, kB\".\n\n\tSteffen\n"},{"id":"58261","messageId":"Pine.LNX.4.64.0711041313020.4362@racer.site","threadId":"10605","inReplyTo":"20071104045800.GB12359@segfault.peff.net","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-04T13:13:40Z","receivedAt":"2007-11-04T13:13:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 4 Nov 2007, Jeff King wrote:\n\n> On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote:\n> \n> > This makes the fetch output much more terse and prettier on a 80 column \n> > display, based on a consensus reached on the mailing list. Here's an \n> > example output:\n> \n> Thank you for this; it was at the end of a very long todo list for me.\n> \n> > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> > Resolving deltas: 100% (4604/4604), done.\n> > From git://git.kernel.org/pub/scm/git/git\n> > ! [rejected] html -> origin/html (non fast forward)\n> > 136e631..f45e867 maint -> origin/maint (fast forward)\n> > 9850e2e..44dd7e0 man -> origin/man (fast forward)\n> > 3e4bb08..e3d6d56 master -> origin/master (fast forward)\n> > fa3665c..536f64a next -> origin/next (fast forward)\n> > + 4f6d9d6...768326f pu -> origin/pu (forced update)\n> > * [new branch] todo -> origin/todo\n> \n> One nice thing about this format is that it works equally well for\n> \"push\" (changing \"From\" to \"To\" and reversing the order of the\n> branches). Comments?\n\nI would like that, too.\n\nCiao,\nDscho\n"},{"id":"58268","messageId":"20071104140103.GF26269@artemis.corp","threadId":"10605","inReplyTo":"Pine.LNX.4.64.0711041313020.4362@racer.site","subject":"Re: [PATCH] git-fetch: more terse fetch output","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-04T14:01:03Z","receivedAt":"2007-11-04T14:01:03Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Nov 04, 2007 at 01:13:40PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 4 Nov 2007, Jeff King wrote:\n> \n> > On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote:\n> > \n> > > This makes the fetch output much more terse and prettier on a 80 column \n> > > display, based on a consensus reached on the mailing list. Here's an \n> > > example output:\n> > \n> > Thank you for this; it was at the end of a very long todo list for me.\n> > \n> > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n> > > Resolving deltas: 100% (4604/4604), done.\n> > > From git://git.kernel.org/pub/scm/git/git\n> > > ! [rejected] html -> origin/html (non fast forward)\n> > > 136e631..f45e867 maint -> origin/maint (fast forward)\n> > > 9850e2e..44dd7e0 man -> origin/man (fast forward)\n> > > 3e4bb08..e3d6d56 master -> origin/master (fast forward)\n> > > fa3665c..536f64a next -> origin/next (fast forward)\n> > > + 4f6d9d6...768326f pu -> origin/pu (forced update)\n> > > * [new branch] todo -> origin/todo\n> > \n> > One nice thing about this format is that it works equally well for\n> > \"push\" (changing \"From\" to \"To\" and reversing the order of the\n> > branches). Comments?\n> \n> I would like that, too.\n\n Seconded.\n\nbtw I believe that an even best attempt to align columns could be done\n\n Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n Resolving deltas: 100% (4604/4604), done.\n From git://git.kernel.org/pub/scm/git/git\n ! [rejected] html -> origin/html (non fast forward)\n 136e631..f45e867 maint -> origin/maint (fast forward)\n 9850e2e..44dd7e0 man -> origin/man (fast forward)\n 3e4bb08..e3d6d56 master -> origin/master (fast forward)\n fa3665c..536f64a next -> origin/next (fast forward)\n + 4f6d9d6...768326f pu -> origin/pu (forced update)\n * [new branch] todo -> origin/todo\n\nThis is way easier to read (for me at least). Of course, perfect\nalignment of the first column needs to know the lengths of refnames\nprior to the fetch, which is not the case, and would be an overkill. A\n10 char column looks quite ok to me.\n\nI'd also argue that (fast forward) does not need to be mentioned after\nthe \"if things work, say nothing\"-unixish-philosophy. those\nparenthesized words catch my attention, to read that it was a fast\nforward after all. So my even preferred output would be:\n\n Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.\n Resolving deltas: 100% (4604/4604), done.\n From git://git.kernel.org/pub/scm/git/git\n ! [rejected] html -> origin/html (non fast forward)\n 136e631..f45e867 maint -> origin/maint\n 9850e2e..44dd7e0 man -> origin/man\n 3e4bb08..e3d6d56 master -> origin/master\n fa3665c..536f64a next -> origin/next\n + 4f6d9d6...768326f pu -> origin/pu (forced update)\n * [new branch] todo -> origin/todo\n\n Something like the following should do it.\n\nAuthor: Pierre Habouzit \nDate: Sun Nov 4 14:59:28 2007 +0100\n\n builtin-fetch: be even quieter, more column-formatting\n \n Signed-off-by: Pierre Habouzit \n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 12b1c4b..92d789f 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -156,6 +156,7 @@ static int s_update_ref(const char *action,\n }\n \n #define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)\n+#define REFCOL_WIDTH 10\n \n static int update_local_ref(struct ref *ref,\n \t\t\t const char *remote,\n@@ -185,8 +186,9 @@ static int update_local_ref(struct ref *ref,\n \n \tif (!hashcmp(ref->old_sha1, ref->new_sha1)) {\n \t\tif (verbose)\n-\t\t\tsprintf(display, \"= %-*s %s -> %s\", SUMMARY_WIDTH,\n-\t\t\t\t\"[up to date]\", remote, pretty_ref);\n+\t\t\tsprintf(display, \"= %-*s %-*s -> %s\", SUMMARY_WIDTH,\n+\t\t\t\t\"[up to date]\", REFCOL_WIDTH, remote,\n+\t\t\t\tpretty_ref);\n \t\treturn 0;\n \t}\n \n@@ -198,15 +200,17 @@ static int update_local_ref(struct ref *ref,\n \t\t * If this is the head, and it's not okay to update\n \t\t * the head, and the old value of the head isn't empty...\n \t\t */\n-\t\tsprintf(display, \"! %-*s %s -> %s (can't fetch in current branch)\",\n-\t\t\tSUMMARY_WIDTH, \"[rejected]\", remote, pretty_ref);\n+\t\tsprintf(display, \"! %-*s %-*s -> %s (can't fetch in current branch)\",\n+\t\t\tSUMMARY_WIDTH, \"[rejected]\", REFCOL_WIDTH, remote,\n+\t\t\tpretty_ref);\n \t\treturn 1;\n \t}\n \n \tif (!is_null_sha1(ref->old_sha1) &&\n \t !prefixcmp(ref->name, \"refs/tags/\")) {\n-\t\tsprintf(display, \"- %-*s %s -> %s\",\n-\t\t\tSUMMARY_WIDTH, \"[tag update]\", remote, pretty_ref);\n+\t\tsprintf(display, \"- %-*s %-*s -> %s\",\n+\t\t\tSUMMARY_WIDTH, \"[tag update]\", REFCOL_WIDTH, remote,\n+\t\t\tpretty_ref);\n \t\treturn s_update_ref(\"updating tag\", ref, 0);\n \t}\n \n@@ -224,8 +228,8 @@ static int update_local_ref(struct ref *ref,\n \t\t\twhat = \"[new branch]\";\n \t\t}\n \n-\t\tsprintf(display, \"* %-*s %s -> %s\",\n-\t\t\tSUMMARY_WIDTH, what, remote, pretty_ref);\n+\t\tsprintf(display, \"* %-*s %-*s -> %s\", SUMMARY_WIDTH, what,\n+\t\t\tREFCOL_WIDTH, remote, pretty_ref);\n \t\treturn s_update_ref(msg, ref, 0);\n \t}\n \n@@ -234,20 +238,21 @@ static int update_local_ref(struct ref *ref,\n \t\tstrcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n \t\tstrcat(quickref, \"..\");\n \t\tstrcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n-\t\tsprintf(display, \" %-*s %s -> %s (fast forward)\",\n-\t\t\tSUMMARY_WIDTH, quickref, remote, pretty_ref);\n+\t\tsprintf(display, \" %-*s %-*s -> %s\", SUMMARY_WIDTH, quickref,\n+\t\t\tREFCOL_WIDTH, remote, pretty_ref);\n \t\treturn s_update_ref(\"fast forward\", ref, 1);\n \t} else if (force || ref->force) {\n \t\tchar quickref[84];\n \t\tstrcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV));\n \t\tstrcat(quickref, \"...\");\n \t\tstrcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));\n-\t\tsprintf(display, \"+ %-*s %s -> %s (forced update)\",\n-\t\t\tSUMMARY_WIDTH, quickref, remote, pretty_ref);\n+\t\tsprintf(display, \"+ %-*s %-*s -> %s (forced update)\",\n+\t\t\tSUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote, pretty_ref);\n \t\treturn s_update_ref(\"forced-update\", ref, 1);\n \t} else {\n-\t\tsprintf(display, \"! %-*s %s -> %s (non fast forward)\",\n-\t\t\tSUMMARY_WIDTH, \"[rejected]\", remote, pretty_ref);\n+\t\tsprintf(display, \"! %-*s %-*s -> %s (non fast forward)\",\n+\t\t\tSUMMARY_WIDTH, \"[rejected]\", REFCOL_WIDTH, remote,\n+\t\t\tpretty_ref);\n \t\treturn 1;\n \t}\n }\n"}]}