git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2 0/2] clone: simplify progress message

From
PHPete Harlan <pgit@pcharlan.com>
Date
May 9, 2010, 20:09 UTC
Message-ID
<4BE7166A.5030107@pcharlan.com>
In-Reply-To
<20100509110221.GA16639@coredump.intra.peff.net>
On 05/09/2010 04:02 AM, Jeff King wrote:
Show 13 quoted lines
> 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.

Show 19 quoted lines
>> 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(-)
Previous: Jeff KingNext: Pete Harlan
Message 3 of 14 in “clone: have progress report mention top level dir, not git dir”
  1. clone: have progress report mention top level dir, not git dirPete Harlan, May 9, 2010
  2. Jeff KingMay 9, 2010
  3. 0/2 clone: simplify progress messagePete Harlan, May 9, 2010
  4. 1/2 clone: have progress report mention top level dir, not git dirPete Harlan, May 9, 2010
  5. 2/2 clone: add bare clone to the progress messagePete Harlan, May 9, 2010
  6. Junio C HamanoMay 9, 2010
  7. Pete HarlanMay 9, 2010
  8. Jeff KingMay 10, 2010
  9. Michael J GruberMay 10, 2010
  10. clone: report check out for non-bare clonesMichael J Gruber, May 10, 2010
  11. Junio C HamanoMay 12, 2010
  12. Michael J GruberMay 12, 2010
  13. Pete HarlanMay 10, 2010
  14. Michael J GruberMay 11, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.