{"thread":{"id":"23750","subject":"[PATCH/RFC] clone: have progress report mention top level dir, not git dir","startedAt":"2010-05-09T01:23:21Z","lastAt":"2010-05-12T07:59:33Z","messageCount":14,"participants":["Pete Harlan","Jeff King","Junio C Hamano","Michael J Gruber"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"141277","messageId":"4BE60E89.8010709@pcharlan.com","threadId":"23750","inReplyTo":null,"subject":"[PATCH/RFC] clone: have progress report mention top level dir, not git dir","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-05-09T01:23:21Z","receivedAt":"2010-05-09T01:23:21Z","isPatch":true,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"\"git clone foo bar\" currently reports \"Cloning into\n/path/to/bar/.git\". Change this message to \"Cloning into bar\" to more\nclosely match the user's expectation.\n\nSigned-off-by: Pete Harlan \n---\n\nThis changes a progress message introduced a few weeks ago in\n28ba96ab2. Unless there's a particular reason to report the .git dir\ninstead of the top level dir, seeing the top level dir feels more\nnatural to me.\n\n(Or printing nothing. For a local clone, silently succeeding seems\nlike a reasonable default. And for a nonlocal clone there's enough\nnoise that the user is comforted that something is happening.)\n\nFor a --bare clone the current message prints the top level dir\n(because that is the git dir), so one could argue in favor of the\ncurrent message because it confirms for the user whether their\ncheckout was bare or not. But that's only if the user is aware of how\nit would appear in both cases; I doubt that the existing code intended\nto make that distinction clear, and in practice I expect most users\n(a) trust git to do what they asked and (b) wouldn't notice that\n\"Cloning into /path/to/bar\" meant that it was a bare checkout.\n\n builtin/clone.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 0bedde4..306aacf 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -464,7 +464,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tset_git_dir(make_absolute_path(git_dir));\n \n \tif (0 <= option_verbosity)\n-\t\tprintf(\"Cloning into %s...\\n\", get_git_dir());\n+\t\tprintf(\"Cloning into %s...\\n\", dir);\n \tinit_db(option_template, INIT_DB_QUIET);\n \n \t/*\n-- \n1.7.1.14.gcafbfa\n"},{"id":"141307","messageId":"20100509110221.GA16639@coredump.intra.peff.net","threadId":"23750","inReplyTo":"4BE60E89.8010709@pcharlan.com","subject":"Re: [PATCH/RFC] clone: have progress report mention top level dir, not git dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-09T11:02:21Z","receivedAt":"2010-05-09T11:02:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 08, 2010 at 06:23:21PM -0700, Pete Harlan wrote:\n\n> \"git clone foo bar\" currently reports \"Cloning into\n> /path/to/bar/.git\". Change this message to \"Cloning into bar\" to more\n> closely match the user's expectation.\n\nI am a little torn on this. For most users, it is just another\nimplementation detail that makes git's output more confusing. And it is\nlikely to be the very first git message seen by many people. But at the\nsame time, it is telling you where the repository actually is, which is\nsomething that can help users learn about how git works.\n\nI guess it comes down to how much detail we want to show.\n\n> For a --bare clone the current message prints the top level dir\n> (because that is the git dir), so one could argue in favor of the\n> current message because it confirms for the user whether their\n> checkout was bare or not. But that's only if the user is aware of how\n> it would appear in both cases; I doubt that the existing code intended\n> to make that distinction clear, and in practice I expect most users\n> (a) trust git to do what they asked and (b) wouldn't notice that\n> \"Cloning into /path/to/bar\" meant that it was a bare checkout.\n\nI do think there is some value to this distinction. But we can make it a\nlot less ugly for new users with:\n\n $ git clone /tmp/foo\n Cloning into /tmp/foo...\n\n $ git clone --bare /tmp/foo\n Cloning into bare repository /tmp/foo...\n\nor something like that.\n\n-Peff\n"},{"id":"141327","messageId":"4BE7166A.5030107@pcharlan.com","threadId":"23750","inReplyTo":"20100509110221.GA16639@coredump.intra.peff.net","subject":"[PATCH v2 0/2] clone: simplify progress message","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-05-09T20:09:14Z","receivedAt":"2010-05-09T20:09:14Z","isPatch":true,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 05/09/2010 04:02 AM, Jeff King wrote:\n> On Sat, May 08, 2010 at 06:23:21PM -0700, Pete Harlan wrote:\n> \n>> \"git clone foo bar\" currently reports \"Cloning into\n>> /path/to/bar/.git\". Change this message to \"Cloning into bar\" to more\n>> closely match the user's expectation.\n> \n> I am a little torn on this. For most users, it is just another\n> implementation detail that makes git's output more confusing. And it is\n> likely to be the very first git message seen by many people. But at the\n> same time, it is telling you where the repository actually is, which is\n> something that can help users learn about how git works.\n> \n> I guess it comes down to how much detail we want to show.\n\nFor me it isn't only a matter of detail; I find \"Cloning into\nbar/.git\" misleading, since bar is getting more than a .git directory.\n\n>> For a --bare clone the current message prints the top level dir\n>> (because that is the git dir), so one could argue in favor of the\n>> current message because it confirms for the user whether their\n>> checkout was bare or not. But that's only if the user is aware of how\n>> it would appear in both cases; I doubt that the existing code intended\n>> to make that distinction clear, and in practice I expect most users\n>> (a) trust git to do what they asked and (b) wouldn't notice that\n>> \"Cloning into /path/to/bar\" meant that it was a bare checkout.\n> \n> I do think there is some value to this distinction. But we can make it a\n> lot less ugly for new users with:\n> \n> $ git clone /tmp/foo\n> Cloning into /tmp/foo...\n> \n> $ git clone --bare /tmp/foo\n> Cloning into bare repository /tmp/foo...\n> \n> or something like that.\n\nThank you for looking at this. I agree with you, and have added a\nsecond patch that implements that.\n\nThese two changes modify a progress message introduced a few weeks ago\nin 28ba96ab2. Unless there's a particular reason to report the .git\ndir instead of the top level dir, seeing the top level dir feels more\nnatural to me.\n\nFor a --bare clone the current message prints the top level dir\n(because that is the git dir), so one could argue in favor of the\ncurrent message because it confirms for the user whether their\ncheckout was bare or not. The second patch modifies the message per\nJeff King's suggestion, to say \"Cloning to bare repository bar...\" to\nconvey that information more directly.\n\nPete Harlan (2):\n clone: have progress report mention top level dir, not git dir\n clone: add bare clone to the progress message\n\n builtin/clone.c | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n"},{"id":"141329","messageId":"4BE716A9.9060608@pcharlan.com","threadId":"23750","inReplyTo":"4BE7166A.5030107@pcharlan.com","subject":"[PATCH v2 1/2] clone: have progress report mention top level dir, not git dir","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-05-09T20:10:17Z","receivedAt":"2010-05-09T20:10:17Z","isPatch":true,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"\"git clone foo bar\" currently reports \"Cloning into\n/path/to/bar/.git\". Change this message to \"Cloning into bar\" to more\nclosely match the user's expectation.\n\nSigned-off-by: Pete Harlan \n---\n builtin/clone.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 0bedde4..306aacf 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -464,7 +464,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tset_git_dir(make_absolute_path(git_dir));\n \n \tif (0 <= option_verbosity)\n-\t\tprintf(\"Cloning into %s...\\n\", get_git_dir());\n+\t\tprintf(\"Cloning into %s...\\n\", dir);\n \tinit_db(option_template, INIT_DB_QUIET);\n \n \t/*\n-- \n1.7.1.14.gcafbfa.dirty\n"},{"id":"141330","messageId":"4BE716E0.6040201@pcharlan.com","threadId":"23750","inReplyTo":"4BE7166A.5030107@pcharlan.com","subject":"[PATCH v2 2/2] clone: add bare clone to the progress message","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-05-09T20:11:12Z","receivedAt":"2010-05-09T20:11:12Z","isPatch":true,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"When cloning, we report \"Cloning into foo...\". If the repository is\nbare, say \"Cloning into bare repository foo...\" instead.\n\nSuggested-by: Jeff King \nSigned-off-by: Pete Harlan \n---\n builtin/clone.c | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 306aacf..3a3625b 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -464,7 +464,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tset_git_dir(make_absolute_path(git_dir));\n \n \tif (0 <= option_verbosity)\n-\t\tprintf(\"Cloning into %s...\\n\", dir);\n+\t\tprintf(\"Cloning into %s%s...\\n\",\n+\t\t option_bare ? \"bare repository \" : \"\", dir);\n \tinit_db(option_template, INIT_DB_QUIET);\n \n \t/*\n-- \n1.7.1.14.gcafbfa.dirty\n"},{"id":"141339","messageId":"7vr5lk90yg.fsf@alter.siamese.dyndns.org","threadId":"23750","inReplyTo":"4BE7166A.5030107@pcharlan.com","subject":"Re: [PATCH v2 0/2] clone: simplify progress message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-09T22:15:03Z","receivedAt":"2010-05-09T22:15:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pete Harlan writes:\n\n> On 05/09/2010 04:02 AM, Jeff King wrote:\n>> On Sat, May 08, 2010 at 06:23:21PM -0700, Pete Harlan wrote:\n>> \n>>> \"git clone foo bar\" currently reports \"Cloning into\n>>> /path/to/bar/.git\". Change this message to \"Cloning into bar\" to more\n>>> closely match the user's expectation.\n>> \n>> I am a little torn on this. For most users, it is just another\n>> implementation detail that makes git's output more confusing. And it is\n>> likely to be the very first git message seen by many people. But at the\n>> same time, it is telling you where the repository actually is, which is\n>> something that can help users learn about how git works.\n>> \n>> I guess it comes down to how much detail we want to show.\n>\n> For me it isn't only a matter of detail; I find \"Cloning into\n> bar/.git\" misleading, since bar is getting more than a .git directory.\n\nThat is also misleading, as cloning is done into bar/.git and everything\nelse happens locally as part of the checkout.\n\nI didn't want to go into nitpicky details, but you asked for it ;-)\n\n> Pete Harlan (2):\n> clone: have progress report mention top level dir, not git dir\n> clone: add bare clone to the progress message\n\nI think the squashing these two into one patch makes quite a lot of\nsense. Does any of the existing test need adjustments, by the way?\n"},{"id":"141341","messageId":"4BE74101.20900@pcharlan.com","threadId":"23750","inReplyTo":"7vr5lk90yg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2 0/2] clone: simplify progress message","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-05-09T23:10:57Z","receivedAt":"2010-05-09T23:10:57Z","isPatch":true,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 05/09/2010 03:15 PM, Junio C Hamano wrote:\n> Pete Harlan writes:\n> \n>> On 05/09/2010 04:02 AM, Jeff King wrote:\n>>> On Sat, May 08, 2010 at 06:23:21PM -0700, Pete Harlan wrote:\n>>> \n>>>> \"git clone foo bar\" currently reports \"Cloning into\n>>>> /path/to/bar/.git\". Change this message to \"Cloning into bar\" to more\n>>>> closely match the user's expectation.\n>>> \n>>> I am a little torn on this. For most users, it is just another\n>>> implementation detail that makes git's output more confusing. And it is\n>>> likely to be the very first git message seen by many people. But at the\n>>> same time, it is telling you where the repository actually is, which is\n>>> something that can help users learn about how git works.\n>>> \n>>> I guess it comes down to how much detail we want to show.\n>>\n>> For me it isn't only a matter of detail; I find \"Cloning into\n>> bar/.git\" misleading, since bar is getting more than a .git directory.\n> \n> That is also misleading, as cloning is done into bar/.git and everything\n> else happens locally as part of the checkout.\n> \n> I didn't want to go into nitpicky details, but you asked for it ;-)\n\nFair enough :)\n\n>> Pete Harlan (2):\n>> clone: have progress report mention top level dir, not git dir\n>> clone: add bare clone to the progress message\n> \n> I think the squashing these two into one patch makes quite a lot of\n> sense. Does any of the existing test need adjustments, by the way?\n\nNo, the test (t5601-clone.sh) looks for \"Clon\", so the new message\npasses that just as well.\n\nI could add a new test that ensures that \"bare repository\" shows up in\nthe message when --bare is passed if you think that's worthwhile.\n\n--Pete\n"},{"id":"141346","messageId":"20100510054756.GB13340@coredump.intra.peff.net","threadId":"23750","inReplyTo":"4BE7166A.5030107@pcharlan.com","subject":"Re: [PATCH v2 0/2] clone: simplify progress message","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-10T05:47:56Z","receivedAt":"2010-05-10T05:47:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, May 09, 2010 at 01:09:14PM -0700, Pete Harlan wrote:\n\n> > I guess it comes down to how much detail we want to show.\n> \n> For me it isn't only a matter of detail; I find \"Cloning into\n> bar/.git\" misleading, since bar is getting more than a .git directory.\n\nYeah, I can buy that line of reasoning. Junio's nitpick aside, I think\nmost users perceive the clone process as creating the whole \"bar\"\ndirectory.\n\n> Thank you for looking at this. I agree with you, and have added a\n> second patch that implements that.\n\nThese patches look good to me. I agree with Junio about just squashing\nthem.\n\n-Peff\n"},{"id":"141376","messageId":"4BE7E09F.3040303@drmicha.warpmail.net","threadId":"23750","inReplyTo":"20100510054756.GB13340@coredump.intra.peff.net","subject":"Re: [PATCH v2 0/2] clone: simplify progress message","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-10T10:31:59Z","receivedAt":"2010-05-10T10:31:59Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 10.05.2010 07:47:\n> On Sun, May 09, 2010 at 01:09:14PM -0700, Pete Harlan wrote:\n> \n>>> I guess it comes down to how much detail we want to show.\n>>\n>> For me it isn't only a matter of detail; I find \"Cloning into\n>> bar/.git\" misleading, since bar is getting more than a .git directory.\n> \n> Yeah, I can buy that line of reasoning. Junio's nitpick aside, I think\n> most users perceive the clone process as creating the whole \"bar\"\n> directory.\n> \n>> Thank you for looking at this. I agree with you, and have added a\n>> second patch that implements that.\n> \n> These patches look good to me. I agree with Junio about just squashing\n> them.\n> \n> -Peff\n\nBack from a conference, I'm being late for the party (Which way round is\nbetter? ;) ).\n\nBut I still want to suggest not sacrificing correctness for \"user's\nexpectations\" and rather trying to do combine them. So how about saying\n\nCloning into $GIT_DIR...\nChecking out branch $branch in $WORK_DIR...\n\nwhere the latter happens for non-bare repos only, of course, and\nincidently confirms the use of \"-b\" or of the default.\n\nMichael\n"},{"id":"141401","messageId":"3521b4733b58bfa516303fafc64d87f05760ea02.1273502583.git.git@drmicha.warpmail.net","threadId":"23750","inReplyTo":"4BE7E09F.3040303@drmicha.warpmail.net","subject":"[PATCH] clone: report check out for non-bare clones","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-10T14:46:03Z","receivedAt":"2010-05-10T14:46:03Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"git clone reports $GIT_DIR as the destination of a clone operation,\nwhich is correct but possibly confusing for new users cloning into\nnon-bare repositories.\n\nThus, report additionally the check out process as\n\nchecking out branch $branchname into worktree $worktree\n\nwhich has the additional benefit of confirming the checked out branch\n(as specified by -b, defaulting to master).\n\nIn the case of a detached head, (null) is the branch name.\n\nInspired-by: Pete Harlan \nSigned-off-by: Michael J Gruber \n---\nI mean something like this. Noobs won't use --no-checkout so that a\ncheck out message should help all possibly confused users.\n\n builtin/clone.c | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 4457922..38ca5e8 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -629,6 +629,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\tstruct tree_desc t;\n \t\tint fd;\n \n+\t\tif (0 <= option_verbosity)\n+\t\t\tprintf(\"Checking out branch %s into worktree %s.\\n\",\n+\t\t\t\tskip_prefix(our_head_points_at->name, \"refs/heads/\"),\n+\t\t\t\twork_tree);\n+\n \t\t/* We need to be in the new work tree for the checkout */\n \t\tsetup_work_tree();\n \n-- \n1.7.1.240.geeaa4d\n"},{"id":"141444","messageId":"4BE8954E.3030405@pcharlan.com","threadId":"23750","inReplyTo":"4BE7E09F.3040303@drmicha.warpmail.net","subject":"Re: [PATCH v2 0/2] clone: simplify progress message","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-05-10T23:22:54Z","receivedAt":"2010-05-10T23:22:54Z","isPatch":true,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 05/10/2010 03:31 AM, Michael J Gruber wrote:\n> Jeff King venit, vidit, dixit 10.05.2010 07:47:\n>> On Sun, May 09, 2010 at 01:09:14PM -0700, Pete Harlan wrote:\n>> \n>>>> I guess it comes down to how much detail we want to show.\n>>> \n>>> For me it isn't only a matter of detail; I find \"Cloning into \n>>> bar/.git\" misleading, since bar is getting more than a .git \n>>> directory.\n>> \n>> Yeah, I can buy that line of reasoning. Junio's nitpick aside, I \n>> think most users perceive the clone process as creating the whole \n>> \"bar\" directory.\n>> \n>>> Thank you for looking at this. I agree with you, and have added \n>>> a second patch that implements that.\n>> \n>> These patches look good to me. I agree with Junio about just \n>> squashing them.\n>> \n>> -Peff\n> \n> Back from a conference, I'm being late for the party (Which way\n> round is better? ;) ).\n> \n> But I still want to suggest not sacrificing correctness for \"user's \n> expectations\" and rather trying to do combine them. So how about \n> saying\n> \n> Cloning into $GIT_DIR... Checking out branch $branch in $WORK_DIR...\n> \n> where the latter happens for non-bare repos only, of course, and \n> incidently confirms the use of \"-b\" or of the default.\n> \n> Michael\n\nThanks for looking at this. The patch you posted reports, e.g.:\n\n % git clone foo bar\n Cloning into /tmp/git/bar/.git...\n done.\n Checking out branch master into worktree bar.\n %\n\nI'd like to see \"worktree\" either omitted or replaced with \"working\ndirectory\". Git works on trees, but \"working directory\" is a term\nordinary users understand and \"bar\" is a directory being populated\nwith files so there's nothing wrong with the user thinking of it that\nway.\n\nBut on a different note, I think we don't have to be so verbose. If\nthe user asks for details with -v then be as chatty as we want, but\nfor the most part operations that succeed should do so quietly.\n\nMy original (unsent) patch was based on master from a couple of weeks\nago and was merely going to remove the db-initialization message and\nreplace it with nothing, so a successful local clone would look like:\n\n % git clone foo bar\n %\n\nI don't think it needs to be more complicated than that. And there's\nreal value in silent success: every message output has to be read by\nthe user because it might be an error message.\n\nSince Junio solved the original problem in a different way (still\nreporting a message but making it less scary) I made a patch to make\nhis message more (in my opinion) friendly, but I think output from\nnormal commands should be as simple as possible.\n\nAt my previous job I converted a team of ten or so people from\nSubversion to Git, and virtually everyone on the team besides myself\nconsidered Git difficult to use and not worth the trouble. We didn't\nhave enough time with it (three months) so I couldn't tell if they\never would have come around, but each little thing that a user could\nperceive as complicated adds up.\n\nSo: I'm fine with your patch (with a removed \"worktree\" or replace it\nwith \"working directory\") if writing a thorough message is considered\ndesirable. But my vote is for more simple output (as in my patches),\nor better yet nothing at all unless there's a problem. The user can\nask for progress with -v if they want it.\n\n--Pete\n"},{"id":"141460","messageId":"4BE906CB.3000303@drmicha.warpmail.net","threadId":"23750","inReplyTo":"4BE8954E.3030405@pcharlan.com","subject":"Re: [PATCH v2 0/2] clone: simplify progress message","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-11T07:27:07Z","receivedAt":"2010-05-11T07:27:07Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Pete Harlan venit, vidit, dixit 11.05.2010 01:22:\n> On 05/10/2010 03:31 AM, Michael J Gruber wrote:\n>> Jeff King venit, vidit, dixit 10.05.2010 07:47:\n>>> On Sun, May 09, 2010 at 01:09:14PM -0700, Pete Harlan wrote:\n>>>\n>>>>> I guess it comes down to how much detail we want to show.\n>>>>\n>>>> For me it isn't only a matter of detail; I find \"Cloning into \n>>>> bar/.git\" misleading, since bar is getting more than a .git \n>>>> directory.\n>>>\n>>> Yeah, I can buy that line of reasoning. Junio's nitpick aside, I \n>>> think most users perceive the clone process as creating the whole \n>>> \"bar\" directory.\n>>>\n>>>> Thank you for looking at this. I agree with you, and have added \n>>>> a second patch that implements that.\n>>>\n>>> These patches look good to me. I agree with Junio about just \n>>> squashing them.\n>>>\n>>> -Peff\n>>\n>> Back from a conference, I'm being late for the party (Which way\n>> round is better? ;) ).\n>>\n>> But I still want to suggest not sacrificing correctness for \"user's \n>> expectations\" and rather trying to do combine them. So how about \n>> saying\n>>\n>> Cloning into $GIT_DIR... Checking out branch $branch in $WORK_DIR...\n>>\n>> where the latter happens for non-bare repos only, of course, and \n>> incidently confirms the use of \"-b\" or of the default.\n>>\n>> Michael\n> \n> Thanks for looking at this. The patch you posted reports, e.g.:\n> \n> % git clone foo bar\n> Cloning into /tmp/git/bar/.git...\n> done.\n> Checking out branch master into worktree bar.\n> %\n> \n> I'd like to see \"worktree\" either omitted or replaced with \"working\n> directory\". Git works on trees, but \"working directory\" is a term\n> ordinary users understand and \"bar\" is a directory being populated\n> with files so there's nothing wrong with the user thinking of it that\n> way.\n\n\"working tree\" (short: worktree) is the Git term, core.worktree the name\nof the config variable, GIT_WORK_TREE the name of the environment\nvariable for the directory in which a tree is checked out.\n\n\"working directory\" is the name of the directory which you are in (i.e.\n$(pwd)).\n\nWhile, technically, the wd is the wt during the check out, using wd\nwould introduce users to the wrong terminology.\n\n> But on a different note, I think we don't have to be so verbose. If\n> the user asks for details with -v then be as chatty as we want, but\n> for the most part operations that succeed should do so quietly.\n\nIn fact, we introduced that message not that long ago because until\nthen, only init's message would be displayed to the user (\"Initializing\nempty...\"), which was highly confusing.\n\nThe consensus back then was, without -v nor -q, to have everyday\ncommands be silent on successful operation, and \"infrequent\" commands\nreport progress.\n\nCheers,\nMichael\n"},{"id":"141499","messageId":"7vljbp994c.fsf@alter.siamese.dyndns.org","threadId":"23750","inReplyTo":"3521b4733b58bfa516303fafc64d87f05760ea02.1273502583.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] clone: report check out for non-bare clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-12T01:55:31Z","receivedAt":"2010-05-12T01:55:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> In the case of a detached head, (null) is the branch name.\n\nI think that depends on your particular libc implementation that helpfully\nmakes printf(\"%s\", NULL) not to at least dump core.\n"},{"id":"141514","messageId":"4BEA5FE5.3060503@drmicha.warpmail.net","threadId":"23750","inReplyTo":"7vljbp994c.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] clone: report check out for non-bare clones","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-12T07:59:33Z","receivedAt":"2010-05-12T07:59:33Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 12.05.2010 03:55:\n> Michael J Gruber writes:\n> \n>> In the case of a detached head, (null) is the branch name.\n> \n> I think that depends on your particular libc implementation that helpfully\n> makes printf(\"%s\", NULL) not to at least dump core.\n\nSorry, I didn't know I can't rely on that. I'll change that if going\nthis route (reporting check out) is desirable at all. Is it?\n\nMichael\n"}]}