# [PATCH] git-fetch: more terse fetch output 20 messages from 2007-11-03 to 2007-11-04. Participants: Nicolas Pitre, Junio C Hamano, Linus Torvalds, Mike Hommey, Pierre Habouzit, Jakub Narebski, Johannes Schindelin, David Brown, Robin Rosenberg, Jeff King, Steffen Prohaska. Thread: https://gitlist.dev/t/10605 ## Nicolas Pitre, 2007-11-03 05:32 Subject: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.9999.0711030101340.21255%40xanadu.home ``` This makes the fetch output much more terse and prettier on a 80 column display, based on a consensus reached on the mailing list. Here's an example output: Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. Resolving deltas: 100% (4604/4604), done. From git://git.kernel.org/pub/scm/git/git ! [rejected] html -> origin/html (non fast forward) 136e631..f45e867 maint -> origin/maint (fast forward) 9850e2e..44dd7e0 man -> origin/man (fast forward) 3e4bb08..e3d6d56 master -> origin/master (fast forward) fa3665c..536f64a next -> origin/next (fast forward) + 4f6d9d6...768326f pu -> origin/pu (forced update) * [new branch] todo -> origin/todo Some portions of this patch have been extracted from earlier proposals by Jeff King and Shawn Pearce. Signed-off-by: Nicolas Pitre --- diff --git a/builtin-fetch.c b/builtin-fetch.c index 003ed76..960b1da 100644 --- a/builtin-fetch.c +++ b/builtin-fetch.c @@ -131,12 +131,6 @@ static struct ref *get_ref_map(struct transport *transport, return ref_map; } -static void show_new(enum object_type type, unsigned char *sha1_new) -{ - fprintf(stderr, " %s: %s\n", typename(type), - find_unique_abbrev(sha1_new, DEFAULT_ABBREV)); -} - static int s_update_ref(const char *action, struct ref *ref, int check_old) @@ -157,34 +151,38 @@ static int s_update_ref(const char *action, return 0; } +#define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3) + static int update_local_ref(struct ref *ref, - const char *note, - int verbose) + const char *remote, + int verbose, + char *display) { - char oldh[41], newh[41]; struct commit *current = NULL, *updated; enum object_type type; struct branch *current_branch = branch_get(NULL); + const char *pretty_ref = ref->name + ( + !prefixcmp(ref->name, "refs/heads/") ? 11 : + !prefixcmp(ref->name, "refs/tags/") ? 10 : + !prefixcmp(ref->name, "refs/remotes/") ? 13 : + 0); + *display = 0; type = sha1_object_info(ref->new_sha1, NULL); if (type < 0) die("object %s not found", sha1_to_hex(ref->new_sha1)); if (!*ref->name) { /* Not storing */ - if (verbose) { - fprintf(stderr, "* fetched %s\n", note); - show_new(type, ref->new_sha1); - } + if (verbose) + sprintf(display, "* branch %s -> FETCH_HEAD", remote); return 0; } if (!hashcmp(ref->old_sha1, ref->new_sha1)) { - if (verbose) { - fprintf(stderr, "* %s: same as %s\n", - ref->name, note); - show_new(type, ref->new_sha1); - } + if (verbose) + sprintf(display, "= %-*s %s -> %s", SUMMARY_WIDTH, + "[up to date]", remote, pretty_ref); return 0; } @@ -196,63 +194,65 @@ static int update_local_ref(struct ref *ref, * If this is the head, and it's not okay to update * the head, and the old value of the head isn't empty... */ - fprintf(stderr, - " * %s: Cannot fetch into the current branch.\n", - ref->name); + sprintf(display, "! %-*s %s -> %s (can't fetch in current branch)", + SUMMARY_WIDTH, "[rejected]", remote, pretty_ref); return 1; } if (!is_null_sha1(ref->old_sha1) && !prefixcmp(ref->name, "refs/tags/")) { - fprintf(stderr, "* %s: updating with %s\n", - ref->name, note); - show_new(type, ref->new_sha1); + sprintf(display, "- %-*s %s -> %s", + SUMMARY_WIDTH, "[tag update]", remote, pretty_ref); return s_update_ref("updating tag", ref, 0); } current = lookup_commit_reference_gently(ref->old_sha1, 1); updated = lookup_commit_reference_gently(ref->new_sha1, 1); if (!current || !updated) { - char *msg; - if (!strncmp(ref->name, "refs/tags/", 10)) + const char *msg; + const char *what; + if (!strncmp(ref->name, "refs/tags/", 10)) { msg = "storing tag"; - else + what = "[new tag]"; + } + else { msg = "storing head"; - fprintf(stderr, "* %s: storing %s\n", - ref->name, note); - show_new(type, ref->new_sha1); + what = "[new branch]"; + } + + sprintf(display, "* %-*s %s -> %s", + SUMMARY_WIDTH, what, remote, pretty_ref); return s_update_ref(msg, ref, 0); } - strcpy(oldh, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV)); - strcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV)); - if (in_merge_bases(current, &updated, 1)) { - fprintf(stderr, "* %s: fast forward to %s\n", - ref->name, note); - fprintf(stderr, " old..new: %s..%s\n", oldh, newh); + char quickref[83]; + strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV)); + strcat(quickref, ".."); + strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV)); + sprintf(display, " %-*s %s -> %s (fast forward)", + SUMMARY_WIDTH, quickref, remote, pretty_ref); return s_update_ref("fast forward", ref, 1); - } - if (!force && !ref->force) { - fprintf(stderr, - "* %s: not updating to non-fast forward %s\n", - ref->name, note); - fprintf(stderr, - " old...new: %s...%s\n", oldh, newh); + } else if (force || ref->force) { + char quickref[84]; + strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV)); + strcat(quickref, "..."); + strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV)); + sprintf(display, "+ %-*s %s -> %s (forced update)", + SUMMARY_WIDTH, quickref, remote, pretty_ref); + return s_update_ref("forced-update", ref, 1); + } else { + sprintf(display, "! %-*s %s -> %s (non fast forward)", + SUMMARY_WIDTH, "[rejected]", remote, pretty_ref); return 1; } - fprintf(stderr, - "* %s: forcing update to non-fast forward %s\n", - ref->name, note); - fprintf(stderr, " old...new: %s...%s\n", oldh, newh); - return s_update_ref("forced-update", ref, 1); } static void store_updated_refs(const char *url, struct ref *ref_map) { FILE *fp; struct commit *commit; - int url_len, i, note_len; + int url_len, i, note_len, shown_url = 0; char note[1024]; const char *what, *kind; struct ref *rm; @@ -315,8 +315,17 @@ static void store_updated_refs(const char *url, struct ref *ref_map) rm->merge ? "" : "not-for-merge", note); - if (ref) - update_local_ref(ref, note, verbose); + if (ref) { + update_local_ref(ref, what, verbose, note); + if (*note) { + if (!shown_url) { + fprintf(stderr, "From %.*s\n", + url_len, url); + shown_url = 1; + } + fprintf(stderr, " %s\n", note); + } + } } fclose(fp); } @@ -376,9 +385,6 @@ static struct ref *find_non_local_tags(struct transport *transport, if (!path_list_has_path(&existing_refs, ref_name) && !path_list_has_path(&new_refs, ref_name) && lookup_object(ref->old_sha1)) { - fprintf(stderr, "Auto-following %s\n", - ref_name); - path_list_insert(ref_name, &new_refs); rm = alloc_ref(strlen(ref_name) + 1); ``` ## Junio C Hamano, 2007-11-03 05:36 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <7vtzo3yjp7.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vtzo3yjp7.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Nicolas Pitre writes: > This makes the fetch output much more terse and prettier on a 80 column > display, based on a consensus reached on the mailing list. Here's an > example output: > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > Resolving deltas: 100% (4604/4604), done. > From git://git.kernel.org/pub/scm/git/git > ! [rejected] html -> origin/html (non fast forward) > 136e631..f45e867 maint -> origin/maint (fast forward) > 9850e2e..44dd7e0 man -> origin/man (fast forward) > 3e4bb08..e3d6d56 master -> origin/master (fast forward) > fa3665c..536f64a next -> origin/next (fast forward) > + 4f6d9d6...768326f pu -> origin/pu (forced update) > * [new branch] todo -> origin/todo Yay! ``` ## Linus Torvalds, 2007-11-03 19:34 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.999.0711031229470.15101%40woody.linux-foundation.org In-Reply-To: ``` On Sat, 3 Nov 2007, Nicolas Pitre wrote: > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. I mostly like this, but can we please just use "MB/kB" instead of "MiB/KiB"? I hope it was some kind of joke on crazy EU bureaucrats that just wasn't caught in time. I also get the glitch, ie remote: Total 118 (delta 86), reused 112 (delta 86)iB/s where that "iB/s" remains as garbage from the previous line: we use hardcoded vt100 sequences for colorization, and nobody has complained yet, so maybe we should just do the same for "reset and clear to end of line"? Or maybe just add a few spaces. Using kB/MB instead of KiB/MiB will make it a few less characters to overwrite too. Linus ``` ## Nicolas Pitre, 2007-11-03 20:30 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.9999.0711031627000.21255%40xanadu.home In-Reply-To: ``` On Sat, 3 Nov 2007, Linus Torvalds wrote: > > > On Sat, 3 Nov 2007, Nicolas Pitre wrote: > > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > > I mostly like this, but can we please just use "MB/kB" instead of > "MiB/KiB"? > > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't > caught in time. I don't care either ways. In fact my own preference is for MB/kB, but if I had used that first I'm sure someone else would have asked for the purist notations. Nicolas ``` ## Mike Hommey, 2007-11-03 20:40 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071103204000.GA24959@glandium.org> URL: https://gitlist.dev/e/20071103204000.GA24959%40glandium.org In-Reply-To: ``` On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote: > On Sat, 3 Nov 2007, Linus Torvalds wrote: > > > > > > > On Sat, 3 Nov 2007, Nicolas Pitre wrote: > > > > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > > > > I mostly like this, but can we please just use "MB/kB" instead of > > "MiB/KiB"? > > > > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't > > caught in time. > > I don't care either ways. In fact my own preference is for MB/kB, but > if I had used that first I'm sure someone else would have asked for the > purist notations. As far as you don't claim 1MB is 1024KB, it's okay. Mike ``` ## Nicolas Pitre, 2007-11-03 20:50 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.9999.0711031645350.21255%40xanadu.home In-Reply-To: <20071103204000.GA24959@glandium.org> ``` On Sat, 3 Nov 2007, Mike Hommey wrote: > On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote: > > On Sat, 3 Nov 2007, Linus Torvalds wrote: > > > > > > > > > > > On Sat, 3 Nov 2007, Nicolas Pitre wrote: > > > > > > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > > > > > > I mostly like this, but can we please just use "MB/kB" instead of > > > "MiB/KiB"? > > > > > > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't > > > caught in time. > > > > I don't care either ways. In fact my own preference is for MB/kB, but > > if I had used that first I'm sure someone else would have asked for the > > purist notations. > > As far as you don't claim 1MB is 1024KB, it's okay. [ heh, I knew someone would say something ] Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk manufacturers decided to redefine the common interpretation of what everyone else used to consider what a MB is just to boost their marketing claims. Nicolas ``` ## Mike Hommey, 2007-11-03 21:03 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071103210321.GA25685@glandium.org> URL: https://gitlist.dev/e/20071103210321.GA25685%40glandium.org In-Reply-To: ``` On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote: > [ heh, I knew someone would say something ] > > Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk > manufacturers decided to redefine the common interpretation of what > everyone else used to consider what a MB is just to boost their > marketing claims. How many grams in a kilogram ? How many meters in a kilometer ? How many joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait... And you know what ? It's not only a matter of hard disk manufacturers. How fast is gigabit ethernet ? Yep, 1000000000 bits/s How big would people say a 44000000 bytes file is ? 44MB or 42MB ? And my favourite: How many bytes in a 1.44MB floppy disk ? 1474560, that is, 1.44 * 1024000. Those who made this big mess are the ones who decided a KB was 1024 bytes, not the others. Mike ``` ## Pierre Habouzit, 2007-11-03 21:46 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071103214602.GF13417@artemis.corp> URL: https://gitlist.dev/e/20071103214602.GF13417%40artemis.corp In-Reply-To: <20071103210321.GA25685@glandium.org> ``` On Sat, Nov 03, 2007 at 09:03:21PM +0000, Mike Hommey wrote: > Those who made this big mess are the ones who decided a KB was 1024 > bytes, not the others. Oooh noes, we already had that discussion on debian-devel@ a few month ago, could we _please_ spare it :) -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Jakub Narebski, 2007-11-03 22:02 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/fgir54%247ft%241%40ger.gmane.org In-Reply-To: <20071103210321.GA25685@glandium.org> ``` Mike Hommey wrote: > On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote: >> [ heh, I knew someone would say something ] >> >> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk >> manufacturers decided to redefine the common interpretation of what >> everyone else used to consider what a MB is just to boost their >> marketing claims. > > How many grams in a kilogram ? How many meters in a kilometer ? How many > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait... > > And you know what ? It's not only a matter of hard disk manufacturers. > > How fast is gigabit ethernet ? Yep, 1000000000 bits/s > How big would people say a 44000000 bytes file is ? 44MB or 42MB ? > And my favourite: How many bytes in a 1.44MB floppy disk ? 1474560, that > is, 1.44 * 1024000. > > Those who made this big mess are the ones who decided a KB was 1024 > bytes, not the others. No, the problem is that in _computer science_ kB (or KB) was 1024 bytes, and MB was 1024 kilobytes, because 1024 is a power of 2, and for example naturally the memory which can be adressed comes as a power of 2. Now in other parts of science k means 1000, and M means 1000000. To make the computer sciences meaning of kB explicit SI introduced ki and Mi prefix. And manufacturers claiming HDD size x GB in the SI meaning took part... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Linus Torvalds, 2007-11-03 22:45 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.999.0711031542010.15101%40woody.linux-foundation.org In-Reply-To: ``` On Sat, 3 Nov 2007, Nicolas Pitre wrote: > > Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk > manufacturers decided to redefine the common interpretation of what > everyone else used to consider what a MB is just to boost their > marketing claims. Actually, they just lost even that in a lawsuit (yeah, they "settled"). The fact is, 1MB = 1024kB = 1048576 bytes. Anybody who claims anything else is a lying piece of pondscum, trying to just fool people into paying more for less. Which is why you should *not* use MiB and KiB - it only validates the pondscum. Linus ``` ## Linus Torvalds, 2007-11-03 22:48 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.999.0711031546110.15101%40woody.linux-foundation.org In-Reply-To: <20071103210321.GA25685@glandium.org> ``` On Sat, 3 Nov 2007, Mike Hommey wrote: > > How many grams in a kilogram ? How many meters in a kilometer ? How many > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait... How many 'u's in the word "colour"? Oh, wait - it depends on context, doesn't it? kB is 1024 bytes. The fact that "k" means something else in other contexts is simply irrelevant. Linus ``` ## Mike Hommey, 2007-11-03 23:31 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071103233144.GA16734@glandium.org> URL: https://gitlist.dev/e/20071103233144.GA16734%40glandium.org In-Reply-To: ``` On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote: > > > On Sat, 3 Nov 2007, Mike Hommey wrote: > > > > How many grams in a kilogram ? How many meters in a kilometer ? How many > > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait... > > How many 'u's in the word "colour"? > > Oh, wait - it depends on context, doesn't it? > > kB is 1024 bytes. The fact that "k" means something else in other contexts > is simply irrelevant. What about the fact that "kB" means different things depending whether it's used for bandwidth or memory capacity ? Does your brain have base 2 hard-coded so that you instantly know 50000000 bytes are 47.68MB ? Are people unable to do so pondscum ? Mike ``` ## Johannes Schindelin, 2007-11-04 00:54 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711040050430.4362%40racer.site In-Reply-To: <20071103233144.GA16734@glandium.org> ``` Hi, On Sun, 4 Nov 2007, Mike Hommey wrote: > On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote: > > > > > > On Sat, 3 Nov 2007, Mike Hommey wrote: > > > > > > How many grams in a kilogram ? How many meters in a kilometer ? How many > > > joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait... > > > > How many 'u's in the word "colour"? > > > > Oh, wait - it depends on context, doesn't it? > > > > kB is 1024 bytes. The fact that "k" means something else in other > > contexts is simply irrelevant. > > What about the fact that "kB" means different things depending whether > it's used for bandwidth or memory capacity ? > > Does your brain have base 2 hard-coded so that you instantly know > 50000000 bytes are 47.68MB ? Are people unable to do so pondscum ? Get over it. kB is not the same as km. It really means something different. And all all people who actually _understand_ something of the matter know what a kilobyte is. Just because some _wankers_^Wbureaucrats decided to make life hard on those people who have actually a _clue_ on real life, does not mean that we have to accept it. 1kB = 1024 bytes. 1MB = 1024*1024 bytes. Everybody who claims anything else is just an annoyance to the rest of the world, who is not clueless, thank you very much. And hard disk manufacturers be damned, and should burn in hell. Ciao, Dscho ``` ## Junio C Hamano, 2007-11-04 01:03 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <7v1wb6yg8d.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v1wb6yg8d.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Johannes Schindelin writes: > 1kB = 1024 bytes. > > 1MB = 1024*1024 bytes. > > Everybody who claims anything else is just an annoyance to the rest of the > world, who is not clueless, thank you very much. > > And hard disk manufacturers be damned, and should burn in hell. Don't blame the hard disk people too harshly. The insanity dates back to floppy disk days, where they marketted 1440kB disks as 1.44MB. I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal bytes. I am too lazy to check ;-) ``` ## David Brown, 2007-11-04 01:49 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071104014930.GA27392@old.davidb.org> URL: https://gitlist.dev/e/20071104014930.GA27392%40old.davidb.org In-Reply-To: <7v1wb6yg8d.fsf@gitster.siamese.dyndns.org> ``` On Sat, Nov 03, 2007 at 06:03:14PM -0700, Junio C Hamano wrote: >I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal >bytes. I am too lazy to check ;-) Of course. A certain magneto optical manufacturer created a 605MB drive, which they marked as 640MB, trying to make it sound like it had the same capacity as a CD. Even with 1,000 bytes 634,388,480 is quite a stretch to call 640MB. I never found the footnote "____ defines megabyte to be 991232 bytes". Dave ``` ## Robin Rosenberg, 2007-11-04 02:14 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <200711040314.36668.robin.rosenberg@dewire.com> URL: https://gitlist.dev/e/200711040314.36668.robin.rosenberg%40dewire.com In-Reply-To: <20071104014930.GA27392@old.davidb.org> ``` söndag 04 november 2007 skrev David Brown: > On Sat, Nov 03, 2007 at 06:03:14PM -0700, Junio C Hamano wrote: > > >I wonder if 700MB CD-ROM and 4.7GB DVD-R are also in decimal > >bytes. I am too lazy to check ;-) > > Of course. A certain magneto optical manufacturer created a 605MB drive, > which they marked as 640MB, trying to make it sound like it had the same > capacity as a CD. Even with 1,000 bytes 634,388,480 is quite a stretch to > call 640MB. I never found the footnote "____ defines megabyte to be 991232 > bytes". They may have used the term "unformatted" capacity. -- robin ``` ## Jeff King, 2007-11-04 04:58 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071104045800.GB12359@segfault.peff.net> URL: https://gitlist.dev/e/20071104045800.GB12359%40segfault.peff.net In-Reply-To: ``` On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote: > This makes the fetch output much more terse and prettier on a 80 column > display, based on a consensus reached on the mailing list. Here's an > example output: Thank you for this; it was at the end of a very long todo list for me. > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > Resolving deltas: 100% (4604/4604), done. > From git://git.kernel.org/pub/scm/git/git > ! [rejected] html -> origin/html (non fast forward) > 136e631..f45e867 maint -> origin/maint (fast forward) > 9850e2e..44dd7e0 man -> origin/man (fast forward) > 3e4bb08..e3d6d56 master -> origin/master (fast forward) > fa3665c..536f64a next -> origin/next (fast forward) > + 4f6d9d6...768326f pu -> origin/pu (forced update) > * [new branch] todo -> origin/todo One nice thing about this format is that it works equally well for "push" (changing "From" to "To" and reversing the order of the branches). Comments? -Peff ``` ## Steffen Prohaska, 2007-11-04 09:56 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/EB9F9DF7-0D71-4542-9049-5C0942304076%40zib.de In-Reply-To: ``` On Nov 3, 2007, at 9:50 PM, Nicolas Pitre wrote: > On Sat, 3 Nov 2007, Mike Hommey wrote: > >> On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote: >>> On Sat, 3 Nov 2007, Linus Torvalds wrote: >>> >>>> >>>> >>>> On Sat, 3 Nov 2007, Nicolas Pitre wrote: >>>>> >>>>> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. >>>> >>>> I mostly like this, but can we please just use "MB/kB" instead of >>>> "MiB/KiB"? >>>> >>>> I hope it was some kind of joke on crazy EU bureaucrats that >>>> just wasn't >>>> caught in time. >>> >>> I don't care either ways. In fact my own preference is for MB/ >>> kB, but >>> if I had used that first I'm sure someone else would have asked >>> for the >>> purist notations. >> >> As far as you don't claim 1MB is 1024KB, it's okay. > > [ heh, I knew someone would say something ] > > Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard > disk > manufacturers decided to redefine the common interpretation of what > everyone else used to consider what a MB is just to boost their > marketing claims. I believe it doesn't matter what prefix we use for a _progress indicator_, as long as we use the same prefix for the the amount already transferred and the bandwidth. A precise language doesn't matter here. Here is a short excerpt from a discussion of the standard. I haven't downloaded the full document "IEEE Trial-Use Standard for Prefixes for Binary Multiples" but copied from Wikipedia : “This standard is prepared with two goals in mind: (1) to preserve the SI prefixes as unambiguous decimal multipliers and (2) to provide alternative prefixes for those cases where binary multipliers are needed. The first goal affects the general public, the wide audience of technical and nontechnical persons who use computers without much concern for their construction or inner working. These persons will normally interpret kilo, mega, etc., in their proper decimal sense. The second goal speaks to specialists—the prefixes for binary multiples make it possible for persons who work in the information sciences to communicate with precision.” Binary multiplier make it possible to communicate with precision. If you use the binary prefixes it is absolutely clear what you are talking about. The meaning of the old prefixes depend on the context. But all this does not matter here. We are talking about a progress indicator. Precision doesn't matter. The user wants to be sure that something is happening and get an idea of how much longer it will take to finish the fetch. An approximation is sufficient. What matters though is saving two characters, because the line width is limited. So lets take "MB, kB". Steffen ``` ## Johannes Schindelin, 2007-11-04 13:13 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711041313020.4362%40racer.site In-Reply-To: <20071104045800.GB12359@segfault.peff.net> ``` Hi, On Sun, 4 Nov 2007, Jeff King wrote: > On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote: > > > This makes the fetch output much more terse and prettier on a 80 column > > display, based on a consensus reached on the mailing list. Here's an > > example output: > > Thank you for this; it was at the end of a very long todo list for me. > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > > Resolving deltas: 100% (4604/4604), done. > > From git://git.kernel.org/pub/scm/git/git > > ! [rejected] html -> origin/html (non fast forward) > > 136e631..f45e867 maint -> origin/maint (fast forward) > > 9850e2e..44dd7e0 man -> origin/man (fast forward) > > 3e4bb08..e3d6d56 master -> origin/master (fast forward) > > fa3665c..536f64a next -> origin/next (fast forward) > > + 4f6d9d6...768326f pu -> origin/pu (forced update) > > * [new branch] todo -> origin/todo > > One nice thing about this format is that it works equally well for > "push" (changing "From" to "To" and reversing the order of the > branches). Comments? I would like that, too. Ciao, Dscho ``` ## Pierre Habouzit, 2007-11-04 14:01 Subject: Re: [PATCH] git-fetch: more terse fetch output Message-ID: <20071104140103.GF26269@artemis.corp> URL: https://gitlist.dev/e/20071104140103.GF26269%40artemis.corp In-Reply-To: ``` On Sun, Nov 04, 2007 at 01:13:40PM +0000, Johannes Schindelin wrote: > Hi, > > On Sun, 4 Nov 2007, Jeff King wrote: > > > On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote: > > > > > This makes the fetch output much more terse and prettier on a 80 column > > > display, based on a consensus reached on the mailing list. Here's an > > > example output: > > > > Thank you for this; it was at the end of a very long todo list for me. > > > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. > > > Resolving deltas: 100% (4604/4604), done. > > > From git://git.kernel.org/pub/scm/git/git > > > ! [rejected] html -> origin/html (non fast forward) > > > 136e631..f45e867 maint -> origin/maint (fast forward) > > > 9850e2e..44dd7e0 man -> origin/man (fast forward) > > > 3e4bb08..e3d6d56 master -> origin/master (fast forward) > > > fa3665c..536f64a next -> origin/next (fast forward) > > > + 4f6d9d6...768326f pu -> origin/pu (forced update) > > > * [new branch] todo -> origin/todo > > > > One nice thing about this format is that it works equally well for > > "push" (changing "From" to "To" and reversing the order of the > > branches). Comments? > > I would like that, too. Seconded. btw I believe that an even best attempt to align columns could be done Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. Resolving deltas: 100% (4604/4604), done. From git://git.kernel.org/pub/scm/git/git ! [rejected] html -> origin/html (non fast forward) 136e631..f45e867 maint -> origin/maint (fast forward) 9850e2e..44dd7e0 man -> origin/man (fast forward) 3e4bb08..e3d6d56 master -> origin/master (fast forward) fa3665c..536f64a next -> origin/next (fast forward) + 4f6d9d6...768326f pu -> origin/pu (forced update) * [new branch] todo -> origin/todo This is way easier to read (for me at least). Of course, perfect alignment of the first column needs to know the lengths of refnames prior to the fetch, which is not the case, and would be an overkill. A 10 char column looks quite ok to me. I'd also argue that (fast forward) does not need to be mentioned after the "if things work, say nothing"-unixish-philosophy. those parenthesized words catch my attention, to read that it was a fast forward after all. So my even preferred output would be: Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done. Resolving deltas: 100% (4604/4604), done. From git://git.kernel.org/pub/scm/git/git ! [rejected] html -> origin/html (non fast forward) 136e631..f45e867 maint -> origin/maint 9850e2e..44dd7e0 man -> origin/man 3e4bb08..e3d6d56 master -> origin/master fa3665c..536f64a next -> origin/next + 4f6d9d6...768326f pu -> origin/pu (forced update) * [new branch] todo -> origin/todo Something like the following should do it. Author: Pierre Habouzit Date: Sun Nov 4 14:59:28 2007 +0100 builtin-fetch: be even quieter, more column-formatting Signed-off-by: Pierre Habouzit diff --git a/builtin-fetch.c b/builtin-fetch.c index 12b1c4b..92d789f 100644 --- a/builtin-fetch.c +++ b/builtin-fetch.c @@ -156,6 +156,7 @@ static int s_update_ref(const char *action, } #define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3) +#define REFCOL_WIDTH 10 static int update_local_ref(struct ref *ref, const char *remote, @@ -185,8 +186,9 @@ static int update_local_ref(struct ref *ref, if (!hashcmp(ref->old_sha1, ref->new_sha1)) { if (verbose) - sprintf(display, "= %-*s %s -> %s", SUMMARY_WIDTH, - "[up to date]", remote, pretty_ref); + sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH, + "[up to date]", REFCOL_WIDTH, remote, + pretty_ref); return 0; } @@ -198,15 +200,17 @@ static int update_local_ref(struct ref *ref, * If this is the head, and it's not okay to update * the head, and the old value of the head isn't empty... */ - sprintf(display, "! %-*s %s -> %s (can't fetch in current branch)", - SUMMARY_WIDTH, "[rejected]", remote, pretty_ref); + sprintf(display, "! %-*s %-*s -> %s (can't fetch in current branch)", + SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote, + pretty_ref); return 1; } if (!is_null_sha1(ref->old_sha1) && !prefixcmp(ref->name, "refs/tags/")) { - sprintf(display, "- %-*s %s -> %s", - SUMMARY_WIDTH, "[tag update]", remote, pretty_ref); + sprintf(display, "- %-*s %-*s -> %s", + SUMMARY_WIDTH, "[tag update]", REFCOL_WIDTH, remote, + pretty_ref); return s_update_ref("updating tag", ref, 0); } @@ -224,8 +228,8 @@ static int update_local_ref(struct ref *ref, what = "[new branch]"; } - sprintf(display, "* %-*s %s -> %s", - SUMMARY_WIDTH, what, remote, pretty_ref); + sprintf(display, "* %-*s %-*s -> %s", SUMMARY_WIDTH, what, + REFCOL_WIDTH, remote, pretty_ref); return s_update_ref(msg, ref, 0); } @@ -234,20 +238,21 @@ static int update_local_ref(struct ref *ref, strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV)); strcat(quickref, ".."); strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV)); - sprintf(display, " %-*s %s -> %s (fast forward)", - SUMMARY_WIDTH, quickref, remote, pretty_ref); + sprintf(display, " %-*s %-*s -> %s", SUMMARY_WIDTH, quickref, + REFCOL_WIDTH, remote, pretty_ref); return s_update_ref("fast forward", ref, 1); } else if (force || ref->force) { char quickref[84]; strcpy(quickref, find_unique_abbrev(current->object.sha1, DEFAULT_ABBREV)); strcat(quickref, "..."); strcat(quickref, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV)); - sprintf(display, "+ %-*s %s -> %s (forced update)", - SUMMARY_WIDTH, quickref, remote, pretty_ref); + sprintf(display, "+ %-*s %-*s -> %s (forced update)", + SUMMARY_WIDTH, quickref, REFCOL_WIDTH, remote, pretty_ref); return s_update_ref("forced-update", ref, 1); } else { - sprintf(display, "! %-*s %s -> %s (non fast forward)", - SUMMARY_WIDTH, "[rejected]", remote, pretty_ref); + sprintf(display, "! %-*s %-*s -> %s (non fast forward)", + SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote, + pretty_ref); return 1; } } ```