[PATCH] git-fetch: more terse fetch output

[PATCH] git-fetch: more terse fetch output

[Nicolas Pitre]

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>
---

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);

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> 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!

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

[Linus Torvalds]

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

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

[Nicolas Pitre]

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

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

[Mike Hommey]

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

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

[Nicolas Pitre]

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

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

[Mike Hommey]

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

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jakub Narebski]

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

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

[Linus Torvalds]

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

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

[Linus Torvalds]

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

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

[Mike Hommey]

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

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ;-)

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

[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".

Dave

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

[Robin Rosenberg]

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

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

[Jeff King]

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

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

[Steffen Prohaska]

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 <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

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

[Johannes Schindelin]

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

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 6548 bytes --]

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 <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>

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;
 	}
 }

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]