From: Pete Harlan <pgit@pcharlan.com>
To: Jeff King <peff@peff.net>
Cc: git list <git@vger.kernel.org>
Subject: [PATCH v2 0/2] clone: simplify progress message
Date: Sun, 09 May 2010 13:09:14 -0700 [thread overview]
Message-ID: <4BE7166A.5030107@pcharlan.com> (raw)
In-Reply-To: <20100509110221.GA16639@coredump.intra.peff.net>
On 05/09/2010 04:02 AM, Jeff King wrote:
> On Sat, May 08, 2010 at 06:23:21PM -0700, Pete Harlan wrote:
>
>> "git clone foo bar" currently reports "Cloning into
>> /path/to/bar/.git". Change this message to "Cloning into bar" to more
>> closely match the user's expectation.
>
> I am a little torn on this. For most users, it is just another
> implementation detail that makes git's output more confusing. And it is
> likely to be the very first git message seen by many people. But at the
> same time, it is telling you where the repository actually is, which is
> something that can help users learn about how git works.
>
> I guess it comes down to how much detail we want to show.
For me it isn't only a matter of detail; I find "Cloning into
bar/.git" misleading, since bar is getting more than a .git directory.
>> For a --bare clone the current message prints the top level dir
>> (because that is the git dir), so one could argue in favor of the
>> current message because it confirms for the user whether their
>> checkout was bare or not. But that's only if the user is aware of how
>> it would appear in both cases; I doubt that the existing code intended
>> to make that distinction clear, and in practice I expect most users
>> (a) trust git to do what they asked and (b) wouldn't notice that
>> "Cloning into /path/to/bar" meant that it was a bare checkout.
>
> I do think there is some value to this distinction. But we can make it a
> lot less ugly for new users with:
>
> $ git clone /tmp/foo
> Cloning into /tmp/foo...
>
> $ git clone --bare /tmp/foo
> Cloning into bare repository /tmp/foo...
>
> or something like that.
Thank you for looking at this. I agree with you, and have added a
second patch that implements that.
These two changes modify a progress message introduced a few weeks ago
in 28ba96ab2. Unless there's a particular reason to report the .git
dir instead of the top level dir, seeing the top level dir feels more
natural to me.
For a --bare clone the current message prints the top level dir
(because that is the git dir), so one could argue in favor of the
current message because it confirms for the user whether their
checkout was bare or not. The second patch modifies the message per
Jeff King's suggestion, to say "Cloning to bare repository bar..." to
convey that information more directly.
Pete Harlan (2):
clone: have progress report mention top level dir, not git dir
clone: add bare clone to the progress message
builtin/clone.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
next prev parent reply other threads:[~2010-05-09 20:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-09 1:23 [PATCH/RFC] clone: have progress report mention top level dir, not git dir Pete Harlan
2010-05-09 11:02 ` Jeff King
2010-05-09 20:09 ` Pete Harlan [this message]
2010-05-09 20:10 ` [PATCH v2 1/2] " Pete Harlan
2010-05-09 20:11 ` [PATCH v2 2/2] clone: add bare clone to the progress message Pete Harlan
2010-05-09 22:15 ` [PATCH v2 0/2] clone: simplify " Junio C Hamano
2010-05-09 23:10 ` Pete Harlan
2010-05-10 5:47 ` Jeff King
2010-05-10 10:31 ` Michael J Gruber
2010-05-10 14:46 ` [PATCH] clone: report check out for non-bare clones Michael J Gruber
2010-05-12 1:55 ` Junio C Hamano
2010-05-12 7:59 ` Michael J Gruber
2010-05-10 23:22 ` [PATCH v2 0/2] clone: simplify progress message Pete Harlan
2010-05-11 7:27 ` Michael J Gruber
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=4BE7166A.5030107@pcharlan.com \
--to=pgit@pcharlan.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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.