Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Currently, cloning a local repository results in the progress report > "Initialized empty Git repository in ..." from init but no other output, > leaving the user to wonder what happened to the actual cloning. With your patch, local variant will become totally silent, but it may want to give some feedback like real transports do; it is not entirely clear what it should say, though. The progress report given by the real transports are to assure the user that we are not stuck, and the local one is usually reasonably fast. It's pointless to say "initialized empty" and then say "I am working hard to clone". As the command always creates a new directory and clones into it, it makes sense to say only the latter, and your 1-byte patch may be a good first step in that direction. An alternative might be to squelch init_db() like your patch did, and then replace it with a message of our own, perhaps like this: $ git clone -n /var/tmp/gomi victim-003 Cloning into victim-003... done. $ git clone -n file:///var/tmp/gomi victim-004 Cloning into victim-004... remote: Counting objects: ... Receiving objects: 100% (120/120), done. Here I am assuming we would add "done." to the local codepath. Personally I like the total silence your patch gives (i.e. no "Cloning into" line in either case, and no "done." in local case) slightly better; others may disagree and/or have better ideas. > This is RFC/RFD. An actual patch will also adjust several tests to > the new expected output. And documentation, especially the tutorials. "git init" as a top-level command may want to stay as-is; it is not like you run "init" over and over again. But we probably should make it an independent issue from the "clone" one. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html