From: Junio C Hamano <junkio@cox.net>
To: "Santi Béjar" <sbejar@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/5] fetch: Clean output
Date: Fri, 29 Sep 2006 19:17:39 -0700 [thread overview]
Message-ID: <7vpsdehzcs.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <8764f61r74.fsf@gmail.com> (Santi Béjar's message of "Fri, 29 Sep 2006 20:08:15 +0200")
Santi Béjar <sbejar@gmail.com> writes:
> Do not show duplicated remote branch information and reformat the output as:
>
> $ git fetch -v # the committish lines for the -v.
> * refs/heads/origin: fast forward to remote branch 'master' of ../git/
> 1ad7a06..bc1a580
> committish: bc1a580
I am not quite sure about this --- it is not obvious what these
two numbers represent anymore. Also I think the last line
outlived its usefulness (99% of the time refs are committish, so
noting exception is good but otherwise it is not interesting).
I know you opted for minimum patch, but it might be a good time
to polish the wording a bit while we are touching the general
vicinity of the code.
How about saying something like:
* refs/heads/origin: fast forward to remote branch 'master' of ../git/
old..new = 1ad7a06..bc1a580
> * refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
> 7c733a8...5faa935
> not updating.
> forcing update.
> committish: 5faa935
This is even more confusing. Perhaps we would want to have two
cases, depending on --force (and +).
* refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
but forcing update anyway. old...new = 7c733a8...5faa935
* refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
not updating. old...new = 7c733a8...5faa935
next prev parent reply other threads:[~2006-09-30 2:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-29 18:05 [PATCH 0/5] fetch & co: misc output cleanup Santi Béjar
2006-09-29 18:05 ` [PATCH 1/5] fetch: Reset remote refs list each time fetch_main is called Santi Béjar
2006-09-29 18:06 ` [PATCH 2/5] fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2" Santi Béjar
2006-09-29 18:06 ` [PATCH 3/5] fetch & co: Use short sha1 in the output Santi Béjar
2006-09-29 18:07 ` [PATCH 4/5] fetch: Add output for the not fast forward case Santi Béjar
2006-09-29 18:08 ` [PATCH 5/5] fetch: Clean output Santi Béjar
2006-09-30 2:17 ` Junio C Hamano [this message]
2006-09-30 9:42 ` Santi
2006-09-30 10:37 ` Junio C Hamano
2006-09-29 18:54 ` [PATCH 0/5] fetch & co: misc output cleanup A Large Angry SCM
2006-09-29 20:48 ` Santi
2006-09-29 21:27 ` Junio C Hamano
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=7vpsdehzcs.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=sbejar@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.