From: Pierre Habouzit <madcoder@debian.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jeff King <peff@peff.net>, Nicolas Pitre <nico@cam.org>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH] git-fetch: more terse fetch output
Date: Sun, 04 Nov 2007 15:01:03 +0100 [thread overview]
Message-ID: <20071104140103.GF26269@artemis.corp> (raw)
In-Reply-To: <Pine.LNX.4.64.0711041313020.4362@racer.site>
[-- 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 --]
prev parent reply other threads:[~2007-11-04 14:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-03 5:32 [PATCH] git-fetch: more terse fetch output Nicolas Pitre
2007-11-03 5:36 ` Junio C Hamano
2007-11-03 19:34 ` Linus Torvalds
2007-11-03 20:30 ` Nicolas Pitre
2007-11-03 20:40 ` Mike Hommey
2007-11-03 20:50 ` Nicolas Pitre
2007-11-03 21:03 ` Mike Hommey
2007-11-03 21:46 ` Pierre Habouzit
2007-11-03 22:02 ` Jakub Narebski
2007-11-03 22:48 ` Linus Torvalds
2007-11-03 23:31 ` Mike Hommey
2007-11-04 0:54 ` Johannes Schindelin
2007-11-04 1:03 ` Junio C Hamano
2007-11-04 1:49 ` David Brown
2007-11-04 2:14 ` Robin Rosenberg
2007-11-03 22:45 ` Linus Torvalds
2007-11-04 9:56 ` Steffen Prohaska
2007-11-04 4:58 ` Jeff King
2007-11-04 13:13 ` Johannes Schindelin
2007-11-04 14:01 ` Pierre Habouzit [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071104140103.GF26269@artemis.corp \
--to=madcoder@debian.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nico@cam.org \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).