threads / patch / 10605

patchgit-fetch: more terse fetch output

Subject: [PATCH] git-fetch: more terse fetch output

## tl;dr

20 messages between Nov 3, 2007 and Nov 4, 2007. Diffs are folded; open one to read it.

replies: 19people: 11as markdown or json

Nicolas Pitre· Nov 3, 2007, 05:32 UTC · lore

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 <nico@cam.org>
---
Show changes to builtin-fetch.c +60 −54
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· Nov 3, 2007, 05:36 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

Nicolas Pitre <nico@cam.org> writes:
Show 14 quoted lines
> 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· Nov 3, 2007, 19:34 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

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· Nov 3, 2007, 20:30 UTC · re: Linus Torvalds · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sat, 3 Nov 2007, Linus Torvalds wrote:
Show 11 quoted lines
> 
> 
> 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· Nov 3, 2007, 20:40 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:
Show 17 quoted lines
> 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· Nov 3, 2007, 20:50 UTC · re: Mike Hommey · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sat, 3 Nov 2007, Mike Hommey wrote:
Show 20 quoted lines
> 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· Nov 3, 2007, 21:03 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote:
Show 6 quoted lines
> [ 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· Nov 3, 2007, 21:46 UTC · re: Mike Hommey · lore

Re: [PATCH] git-fetch: more terse fetch output

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· Nov 3, 2007, 22:02 UTC · re: Mike Hommey · lore

Re: [PATCH] git-fetch: more terse fetch output

Mike Hommey wrote:
Show 20 quoted lines
> 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· Nov 3, 2007, 22:48 UTC · re: Mike Hommey · lore

Re: [PATCH] git-fetch: more terse fetch output

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· Nov 3, 2007, 23:31 UTC · re: Linus Torvalds · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote:
Show 13 quoted lines
> 
> 
> 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· Nov 4, 2007, 00:54 UTC · re: Mike Hommey · lore

Re: [PATCH] git-fetch: more terse fetch output

Hi,
On Sun, 4 Nov 2007, Mike Hommey wrote:
Show 20 quoted lines
> 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· Nov 4, 2007, 01:03 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git-fetch: more terse fetch output

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
> 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· Nov 4, 2007, 01:49 UTC · re: Junio C Hamano · lore

Re: [PATCH] git-fetch: more terse fetch output

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· Nov 4, 2007, 02:14 UTC · re: David Brown · lore

Re: [PATCH] git-fetch: more terse fetch output

söndag 04 november 2007 skrev David Brown:
Show 10 quoted lines
> 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
Linus Torvalds· Nov 3, 2007, 22:45 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sat, 3 Nov 2007, Nicolas Pitre wrote:
Show 5 quoted lines
>
> 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
Steffen Prohaska· Nov 4, 2007, 09:56 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

On Nov 3, 2007, at 9:50 PM, Nicolas Pitre wrote:
Show 33 quoted lines
> 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 <http:// en.wikipedia.org/wiki/Binary_prefix>:

“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
Jeff King· Nov 4, 2007, 04:58 UTC · re: Nicolas Pitre · lore

Re: [PATCH] git-fetch: more terse fetch output

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.
Show 10 quoted lines
> 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
Johannes Schindelin· Nov 4, 2007, 13:13 UTC · re: Jeff King · lore

Re: [PATCH] git-fetch: more terse fetch output

Hi,
On Sun, 4 Nov 2007, Jeff King wrote:
Show 22 quoted lines
> 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· Nov 4, 2007, 14:01 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git-fetch: more terse fetch output

On Sun, Nov 04, 2007 at 01:13:40PM +0000, Johannes Schindelin wrote:
Show 28 quoted lines
> 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 <madcoder@debian.org>
Date:   Sun Nov 4 14:59:28 2007 +0100
    builtin-fetch: be even quieter, more column-formatting
    
    Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Show changes to builtin-fetch.c +19 −14
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;
 	}
 }

← back to recent threads