{"thread":{"id":"30754","subject":"[PATCH] git-status: Show empty directories","startedAt":"2012-06-09T19:40:06Z","lastAt":"2012-06-11T19:00:18Z","messageCount":17,"participants":["Leila Muhtasib","konglu@minatec.inpg.fr","Leila","Thomas Rast","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"193212","messageId":"1339270806-65013-1-git-send-email-muhtasib@gmail.com","threadId":"30754","inReplyTo":null,"subject":"[PATCH] git-status: Show empty directories","fromName":"Leila Muhtasib","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-09T19:40:06Z","receivedAt":"2012-06-09T19:40:06Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"git-status now lists empty directories under the untracked header. Before this\nmodification, git status did not list empty directories. The header changed\nfrom 'Untracked files' to instead display 'Untracked files and directories'.\nA helpful reminder is also added after empty directories indicating they cannot\nbe added/staged if they are empty. git status -u is unchanged, and will still\nonly show untracked files just as before. As a result, no need for\ndocumentation change.\n\nEmpty dirs are work in progress. They result because of one of the following:\nuser forgot to add files to dir, user forgot to clean up dir, user under\nimpression dir is staged and will be committed or is already committed. Last\nitem might occur as some users setup project and dir structures before adding files.\n\nSo this patch servers as a helpful reminder to users that they have an empty dir\nso they can act upon it. Plus it clarifies git behavior to the user that empty\ndirs can't be tracked.\n\nSigned-off-by: Leila Muhtasib <muhtasib@gmail.com>\n---\n\nI ran into this issue myself where I thought my dir was already tracked, and \nwhen I googled and found other people were confused and asking the same question. \nWhy don't empty dirs appear under git status when they aren't tracked? So I came \nup with this patch.\n\nIn my commit message, I compiled a list of arguments in favor of this patch. \nBut I've also thought about arguments against, however I didn't think they were \ncompelling enough to not have this patch. So I've also included my own rebuttal \nbelow :)\n\n1) Direcories can't be tracked, so why show them under untracked?\nBecause it is a helpful reminder. See reasons in the commit message above for \nhow it is helpful. This would make git more user friendly.\nPlus untracked does not mean 'it can be tracked', it just means it's not currently \ntracked by git.\n\n2) Empty directories should be ignored\nIf someone really wants to ignore something, they can put it in the .gitignore \nfile. Otherwise, the benefits above out weight this.\n\n\n wt-status.c |   24 +++++++++++++++++++-----\n 1 files changed, 19 insertions(+), 5 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 9ffc535..81bf1aa 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -184,7 +184,12 @@ static void wt_status_print_other_header(struct wt_status *s,\n \t\t\t\t\t const char *how)\n {\n \tconst char *c = color(WT_STATUS_HEADER, s);\n-\tstatus_printf_ln(s, c, _(\"%s files:\"), what);\n+\n+\tif (s->show_untracked_files == SHOW_NORMAL_UNTRACKED_FILES)\n+\t\tstatus_printf_ln(s, c, _(\"%s files and directories:\"), what);\n+\telse if (s->show_untracked_files == SHOW_ALL_UNTRACKED_FILES)\n+\t\tstatus_printf_ln(s, c, _(\"%s files:\"), what);\n+\n \tif (!advice_status_hints)\n \t\treturn;\n \tstatus_printf_ln(s, c, _(\"  (use \\\"git %s <file>...\\\" to include in what will be committed)\"), how);\n@@ -464,16 +469,25 @@ static void wt_status_collect_untracked(struct wt_status *s)\n \t\treturn;\n \tmemset(&dir, 0, sizeof(dir));\n \tif (s->show_untracked_files != SHOW_ALL_UNTRACKED_FILES)\n-\t\tdir.flags |=\n-\t\t\tDIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;\n+\tdir.flags |=\n+\t  DIR_SHOW_OTHER_DIRECTORIES;\n \tsetup_standard_excludes(&dir);\n \n \tfill_directory(&dir, s->pathspec);\n \tfor (i = 0; i < dir.nr; i++) {\n \t\tstruct dir_entry *ent = dir.entries[i];\n \t\tif (cache_name_is_other(ent->name, ent->len) &&\n-\t\t    match_pathspec(s->pathspec, ent->name, ent->len, 0, NULL))\n-\t\t\tstring_list_insert(&s->untracked, ent->name);\n+\t\t    match_pathspec(s->pathspec, ent->name, ent->len, 0, NULL)) {\n+\t\t\tif (is_empty_dir(ent->name)) {\n+\t\t\t\tstruct strbuf buf_name = STRBUF_INIT;\n+\t\t\t\tstrbuf_addstr(&buf_name, ent->name);\n+\t\t\t\tstrbuf_addstr(&buf_name, \" (empty directories cannot be added)\");\n+\t\t\t\tstring_list_insert(&s->untracked, buf_name.buf);\n+\t\t\t\tstrbuf_release(&buf_name);\n+\t\t\t}\n+\t\t\telse\n+\t\t\t\tstring_list_insert(&s->untracked, ent->name);\n+\t\t}\n \t\tfree(ent);\n \t}\n \n-- \n1.7.7.5 (Apple Git-26)\n"},{"id":"193214","messageId":"20120609221315.Horde.fN5FP3wdC4BP065b3FviijA@webmail.minatec.grenoble-inp.fr","threadId":"30754","inReplyTo":"1339270806-65013-1-git-send-email-muhtasib@gmail.com","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"","fromEmail":"konglu@minatec.inpg.fr","sentAt":"2012-06-09T20:13:15Z","receivedAt":"2012-06-09T20:13:15Z","isPatch":true,"sender":{"key":"konglu@minatec.inpg.fr","avatar":null},"body":"\nLeila Muhtasib <muhtasib@gmail.com> a écrit :\n\n>  wt-status.c |   24 +++++++++++++++++++-----\n>  1 files changed, 19 insertions(+), 5 deletions(-)\n\nDo not forget to also update the test that need 'git\nstatus'. For example, most of the tests in t7508 are\nbroken with your patch (the change is not huge, just\nadding \"and directories\" at the end of \"untracked files:\"\nhere and there and maybe some other minor details).\nOtherwise, the idea seems good to me :).\n\n>  \tfor (i = 0; i < dir.nr; i++) {\n>  \t\tstruct dir_entry *ent = dir.entries[i];\n>  \t\tif (cache_name_is_other(ent->name, ent->len) &&\n> -\t\t    match_pathspec(s->pathspec, ent->name, ent->len, 0, NULL))\n> -\t\t\tstring_list_insert(&s->untracked, ent->name);\n> +\t\t    match_pathspec(s->pathspec, ent->name, ent->len, 0, NULL)) {\n> +\t\t\tif (is_empty_dir(ent->name)) {\n> +\t\t\t\tstruct strbuf buf_name = STRBUF_INIT;\n> +\t\t\t\tstrbuf_addstr(&buf_name, ent->name);\n> +\t\t\t\tstrbuf_addstr(&buf_name, \" (empty directories cannot be added)\");\n> +\t\t\t\tstring_list_insert(&s->untracked, buf_name.buf);\n> +\t\t\t\tstrbuf_release(&buf_name);\n> +\t\t\t}\n> +\t\t\telse\n> +\t\t\t\tstring_list_insert(&s->untracked, ent->name);\n\nThe structure is\n       if (...) {\n              /*code*/\n       } else {\n              /*code*/\n       }\n\nDo not forget braces in the \"else\" part as the firt block needs it.\n"},{"id":"193215","messageId":"CAA3EhHJ9WnisF21iFfsjQKYFSY0t0jFvNV3aBjx0eGFPm8aoGg@mail.gmail.com","threadId":"30754","inReplyTo":"20120609221315.Horde.fN5FP3wdC4BP065b3FviijA@webmail.minatec.grenoble-inp.fr","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-09T21:08:20Z","receivedAt":"2012-06-09T21:08:20Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Sat, Jun 9, 2012 at 4:13 PM,  <konglu@minatec.inpg.fr> wrote:\n>\n> Leila Muhtasib <muhtasib@gmail.com> a écrit :\n>\n>\n>>  wt-status.c |   24 +++++++++++++++++++-----\n>>  1 files changed, 19 insertions(+), 5 deletions(-)\n>\n>\n> Do not forget to also update the test that need 'git\n> status'. For example, most of the tests in t7508 are\n> broken with your patch (the change is not huge, just\n> adding \"and directories\" at the end of \"untracked files:\"\n> here and there and maybe some other minor details).\n> Otherwise, the idea seems good to me :).\n>\n\nThanks! I didn't update the tests. I will do so now.\n\n>\n>>        for (i = 0; i < dir.nr; i++) {\n>>                struct dir_entry *ent = dir.entries[i];\n>>                if (cache_name_is_other(ent->name, ent->len) &&\n>> -                   match_pathspec(s->pathspec, ent->name, ent->len, 0,\n>> NULL))\n>> -                       string_list_insert(&s->untracked, ent->name);\n>> +                   match_pathspec(s->pathspec, ent->name, ent->len, 0,\n>> NULL)) {\n>> +                       if (is_empty_dir(ent->name)) {\n>> +                               struct strbuf buf_name = STRBUF_INIT;\n>> +                               strbuf_addstr(&buf_name, ent->name);\n>> +                               strbuf_addstr(&buf_name, \" (empty\n>> directories cannot be added)\");\n>> +                               string_list_insert(&s->untracked,\n>> buf_name.buf);\n>> +                               strbuf_release(&buf_name);\n>> +                       }\n>> +                       else\n>> +                               string_list_insert(&s->untracked,\n>> ent->name);\n>\n>\n> The structure is\n>      if (...) {\n>             /*code*/\n>      } else {\n>             /*code*/\n>      }\n>\n> Do not forget braces in the \"else\" part as the firt block needs it.\n\nI was under the impression that one liners didn't require parenthesis\naccording to the style guidelines. I didn't realize that if the 'if'\nrequired it, then the else required it. I will make that change and\nremember it for the future. Thanks!\n\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"193216","messageId":"877gvgrxw7.fsf@thomas.inf.ethz.ch","threadId":"30754","inReplyTo":"CAA3EhHJ9WnisF21iFfsjQKYFSY0t0jFvNV3aBjx0eGFPm8aoGg@mail.gmail.com","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-06-09T21:14:16Z","receivedAt":"2012-06-09T21:14:16Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Leila <muhtasib@gmail.com> writes:\n\n>> The structure is\n>>      if (...) {\n>>             /*code*/\n>>      } else {\n>>             /*code*/\n>>      }\n>>\n>> Do not forget braces in the \"else\" part as the firt block needs it.\n>\n> I was under the impression that one liners didn't require parenthesis\n> according to the style guidelines. I didn't realize that if the 'if'\n> required it, then the else required it. I will make that change and\n> remember it for the future. Thanks!\n\nIt's not required, there's plenty of precedent, even one case within\nwt-status.c, of '} else'.  Try running\n\n  git grep '} else$'\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"193217","messageId":"CAA3EhHLzGG2pz27+_k6s92VC+u2S==ADyVMdCawES-=ZFt4fhg@mail.gmail.com","threadId":"30754","inReplyTo":"877gvgrxw7.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-09T21:24:36Z","receivedAt":"2012-06-09T21:24:36Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Sat, Jun 9, 2012 at 5:14 PM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Leila <muhtasib@gmail.com> writes:\n>\n>>> The structure is\n>>>      if (...) {\n>>>             /*code*/\n>>>      } else {\n>>>             /*code*/\n>>>      }\n>>>\n>>> Do not forget braces in the \"else\" part as the firt block needs it.\n>>\n>> I was under the impression that one liners didn't require parenthesis\n>> according to the style guidelines. I didn't realize that if the 'if'\n>> required it, then the else required it. I will make that change and\n>> remember it for the future. Thanks!\n>\n> It's not required, there's plenty of precedent, even one case within\n> wt-status.c, of '} else'.  Try running\n>\n>  git grep '} else$'\n>\n\nI ran the command and was able to see that. Thanks Thomas. I'm fine\nfollowing whichever style you guys prefer.\n"},{"id":"193218","messageId":"20120609234717.Horde.I9rYUXwdC4BP08RlFRO2w_A@webmail.minatec.grenoble-inp.fr","threadId":"30754","inReplyTo":"877gvgrxw7.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"","fromEmail":"konglu@minatec.inpg.fr","sentAt":"2012-06-09T21:47:17Z","receivedAt":"2012-06-09T21:47:17Z","isPatch":true,"sender":{"key":"konglu@minatec.inpg.fr","avatar":null},"body":"\nThomas Rast <trast@student.ethz.ch> a écrit :\n\n> Leila <muhtasib@gmail.com> writes:\n>\n>>> The structure is\n>>>      if (...) {\n>>>             /*code*/\n>>>      } else {\n>>>             /*code*/\n>>>      }\n>>>\n>>> Do not forget braces in the \"else\" part as the firt block needs it.\n>>\n>> I was under the impression that one liners didn't require parenthesis\n>> according to the style guidelines. I didn't realize that if the 'if'\n>> required it, then the else required it. I will make that change and\n>> remember it for the future. Thanks!\n>\n> It's not required, there's plenty of precedent, even one case within\n> wt-status.c, of '} else'.  Try running\n>\n>   git grep '} else$'\n\nIt's not because \"there's plenty of precedent\" that we should not try\nto improve the format of the code. That's why there're coding style\nrules so that we can keep the improvements consistent.\n\nThanks.\n\nLucien Kong\n"},{"id":"193229","messageId":"7vr4tnab9e.fsf@alter.siamese.dyndns.org","threadId":"30754","inReplyTo":"1339270806-65013-1-git-send-email-muhtasib@gmail.com","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-10T07:15:09Z","receivedAt":"2012-06-10T07:15:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leila Muhtasib <muhtasib@gmail.com> writes:\n\n> git-status now lists empty directories under the untracked header. Before this\n> modification, git status did not list empty directories. The header changed\n> from 'Untracked files' to instead display 'Untracked files and directories'.\n> A helpful reminder is also added after empty directories indicating they cannot\n> be added/staged if they are empty. git status -u is unchanged, and will still\n> only show untracked files just as before. As a result, no need for\n> documentation change.\n\nPlease do not write a thick wall of text like this.  State the\nproblem you are trying to solve first, by describing the current\nbehaviour you want to highlight, and explain why you think the\ncurrent behaviour is bad.  Then describe how you propose to solve\nthat issue in a separate paragraph.\n\nFor example:\n\n> git-status now lists empty directories under the untracked header. Before this\n> modification, git status did not list empty directories.\n\nThe above is backwards.\n\n\t\"git status\" lists untracked files and directories full of\n\tuntracked files, but does not list empty directories.  This\n\tis bad for such and such reasons.\n\nThen describe your solution (which should be a short two sentence in\nthis case, because in the problem description you would have justified\nadding \"empty directories\" section).\n\n\tShow empty directories to the \"Untracked\" section as well.\n\tBecause an empty directory by definition does not have\n\tanything that the user could add, suggest the user to create\n\ta file to be committed and then add it.\n\nHaving said all that, I personally doubt this is a useful change.  I\nmay thought of adding a README file to a relatively new project that\ndoes not yet have one while in shower but I haven't even created the\nfile in the working tree.  And I forget about it once I get to the\noffice.  Should the system remind me to create README and then add?\nYour patch would not give me such a reminder once the top-level\ndirectory is populated (because it is no longer empty).  Even if I\nwere planning to add Documentation/README instead, I would get such\na reminder only if the Documentation directory is empty. Once the\ndirectory is populated, I wouldn't get \"create README and then add\".\nWhy should an empty directory so special?\n"},{"id":"193236","messageId":"87haujr15p.fsf@thomas.inf.ethz.ch","threadId":"30754","inReplyTo":"20120609234717.Horde.I9rYUXwdC4BP08RlFRO2w_A@webmail.minatec.grenoble-inp.fr","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-06-10T09:01:22Z","receivedAt":"2012-06-10T09:01:22Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"konglu@minatec.inpg.fr writes:\n\n> Thomas Rast <trast@student.ethz.ch> a écrit :\n>\n>> Leila <muhtasib@gmail.com> writes:\n>>\n>>>> The structure is\n>>>>      if (...) {\n>>>>             /*code*/\n>>>>      } else {\n>>>>             /*code*/\n>>>>      }\n>>>>\n>>>> Do not forget braces in the \"else\" part as the firt block needs it.\n>>>\n>>> I was under the impression that one liners didn't require parenthesis\n>>> according to the style guidelines. I didn't realize that if the 'if'\n>>> required it, then the else required it. I will make that change and\n>>> remember it for the future. Thanks!\n>>\n>> It's not required, there's plenty of precedent, even one case within\n>> wt-status.c, of '} else'.  Try running\n>>\n>>   git grep '} else$'\n>\n> It's not because \"there's plenty of precedent\" that we should not try\n> to improve the format of the code. That's why there're coding style\n> rules so that we can keep the improvements consistent.\n\nYeah, and the rules (Documentation/CodingGuidelines) say\n\n - We avoid using braces unnecessarily.  I.e.\n\n\tif (bla) {\n\t\tx = 1;\n\t}\n\n   is frowned upon.  A gray area is when the statement extends\n   over a few lines, and/or you have a lengthy comment atop of\n   it.  Also, like in the Linux kernel, if there is a long list\n   of \"else if\" statements, it can make sense to add braces to\n   single line blocks.\n\nI'm not the one who wrote them, but I'm taking the last sentence to mean\nthat you should not put the braces unless the omission will break the\nvertical alignment of the 'else if' chain.\n\n\nBTW, there are plenty of cases in git where it is better to stick to the\nexisting style of the file instead of the CodingGuidelines, unless you\nare willing to clean up the file first (and nobody else works on it).\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"193239","messageId":"20120610114615.Horde.Sp1YK3wdC4BP1GznJuNzcNA@webmail.minatec.grenoble-inp.fr","threadId":"30754","inReplyTo":"87haujr15p.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"","fromEmail":"konglu@minatec.inpg.fr","sentAt":"2012-06-10T09:46:15Z","receivedAt":"2012-06-10T09:46:15Z","isPatch":true,"sender":{"key":"konglu@minatec.inpg.fr","avatar":null},"body":"\nThomas Rast <trast@student.ethz.ch> a écrit :\n\n>  - We avoid using braces unnecessarily.  I.e.\n>\n> \tif (bla) {\n> \t\tx = 1;\n> \t}\n>\n>    is frowned upon.  A gray area is when the statement extends\n>    over a few lines, and/or you have a lengthy comment atop of\n>    it.  Also, like in the Linux kernel, if there is a long list\n>    of \"else if\" statements, it can make sense to add braces to\n>    single line blocks.\n>\n> I'm not the one who wrote them, but I'm taking the last sentence to mean\n> that you should not put the braces unless the omission will break the\n> vertical alignment of the 'else if' chain.\n\nI agree with you and that's what I thought. Still\n\nJunio C Hamano <gitster@pobox.com> a écrit :\n\n> Two points on style (also appear elsewhere in this patch):\n>\n> \tif (!\"applying\") {\n>  \t\t...\n> \t} else {\n> \t\tstate->rebase_in_progress = 1;\n> \t}\n>\n>  - \"else\" comes on the same line as closing \"}\" of its \"if\" block;\n>\n>  - if one of if/else if/else chain has multiple statement block, use {}\n>    even for a single statement block in the chain.\n"},{"id":"193263","messageId":"CAA3EhHKORv3n9b4Ln1L36_ETZVjEqrZeutKiK0ML=u3ecrqJ0g@mail.gmail.com","threadId":"30754","inReplyTo":"20120610114615.Horde.Sp1YK3wdC4BP1GznJuNzcNA@webmail.minatec.grenoble-inp.fr","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-10T14:20:28Z","receivedAt":"2012-06-10T14:20:28Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Sun, Jun 10, 2012 at 5:46 AM,  <konglu@minatec.inpg.fr> wrote:\n>\n> Thomas Rast <trast@student.ethz.ch> a écrit :\n>\n>>  - We avoid using braces unnecessarily.  I.e.\n>>\n>>        if (bla) {\n>>                x = 1;\n>>        }\n>>\n>>   is frowned upon.  A gray area is when the statement extends\n>>   over a few lines, and/or you have a lengthy comment atop of\n>>   it.  Also, like in the Linux kernel, if there is a long list\n>>   of \"else if\" statements, it can make sense to add braces to\n>>   single line blocks.\n>>\n>> I'm not the one who wrote them, but I'm taking the last sentence to mean\n>> that you should not put the braces unless the omission will break the\n>> vertical alignment of the 'else if' chain.\n>\n>\n> I agree with you and that's what I thought. Still\n>\n> Junio C Hamano <gitster@pobox.com> a écrit :\n>\n>> Two points on style (also appear elsewhere in this patch):\n>>\n>>        if (!\"applying\") {\n>>                ...\n>>        } else {\n>>                state->rebase_in_progress = 1;\n>>        }\n>>\n>>  - \"else\" comes on the same line as closing \"}\" of its \"if\" block;\n>>\n>>  - if one of if/else if/else chain has multiple statement block, use {}\n>>   even for a single statement block in the chain.\n>\n\nI'm happy to produce a patch to update the documentation if there is\nconsensus to avoid using braces unnecessarily for if statements with\none line, but not in the case that there is {} used in a if/else\nchain. Thomas, Lucien, are you on board?\n"},{"id":"193267","messageId":"CAA3EhHLWDtUeNB+RZA064Omwxh7SEYhSc53U0nuiSTNzioKnug@mail.gmail.com","threadId":"30754","inReplyTo":"7vr4tnab9e.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-10T16:02:39Z","receivedAt":"2012-06-10T16:02:39Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Sun, Jun 10, 2012 at 3:15 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Leila Muhtasib <muhtasib@gmail.com> writes:\n>\n>> git-status now lists empty directories under the untracked header. Before this\n>> modification, git status did not list empty directories. The header changed\n>> from 'Untracked files' to instead display 'Untracked files and directories'.\n>> A helpful reminder is also added after empty directories indicating they cannot\n>> be added/staged if they are empty. git status -u is unchanged, and will still\n>> only show untracked files just as before. As a result, no need for\n>> documentation change.\n>\n> Please do not write a thick wall of text like this.  State the\n> problem you are trying to solve first, by describing the current\n> behaviour you want to highlight, and explain why you think the\n> current behaviour is bad.  Then describe how you propose to solve\n> that issue in a separate paragraph.\n>\n> For example:\n>\n>> git-status now lists empty directories under the untracked header. Before this\n>> modification, git status did not list empty directories.\n>\n> The above is backwards.\n>\n>        \"git status\" lists untracked files and directories full of\n>        untracked files, but does not list empty directories.  This\n>        is bad for such and such reasons.\n>\n> Then describe your solution (which should be a short two sentence in\n> this case, because in the problem description you would have justified\n> adding \"empty directories\" section).\n>\n>        Show empty directories to the \"Untracked\" section as well.\n>        Because an empty directory by definition does not have\n>        anything that the user could add, suggest the user to create\n>        a file to be committed and then add it.\n\nUnderstood, I'll make sure to do that in the future. I appreciate the example.\n\n>\n> Having said all that, I personally doubt this is a useful change.  I\n> may thought of adding a README file to a relatively new project that\n> does not yet have one while in shower but I haven't even created the\n> file in the working tree.  And I forget about it once I get to the\n> office.  Should the system remind me to create README and then add?\n> Your patch would not give me such a reminder once the top-level\n> directory is populated (because it is no longer empty).  Even if I\n> were planning to add Documentation/README instead, I would get such\n> a reminder only if the Documentation directory is empty. Once the\n> directory is populated, I wouldn't get \"create README and then add\".\n> Why should an empty directory so special?\n>\n\nSo there are two separate discussions here:\n1) Should empty dirs be tracked\n\n2) Should empty dirs appear under 'untracked' in git status\n\nThe question 'why are empty dirs special', is issue no 1, which I'm\nalso happy to discuss. The rule empty dirs can't be added in git is\nunintuitive, as people use git to keep track of things - all things.\nSo it's not about an empty dir being special, it's about how people\nuse git to keep track of things. Now why might people want empty dirs\ntracked? 1) People often setup dir structure in projects before adding\nany code. They often want to save that state for themselves or to\nshare it with other team members. 2) Taken from link below: \"Although\nthe directories contain no files, just empty directories, they are\nused by the test suite, so I need them to exist in the working tree.\"\n3) It's about saving state, all of it, including empty dirs (even if\nthey are not useful at the time).\n\nThis issue is often raised:\nhttps://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F\nhttp://stackoverflow.com/questions/115983/how-do-i-add-an-empty-directory-to-a-git-repository/8944077#8944077\nhttp://stackoverflow.com/questions/9072022/why-cant-i-track-these-files-with-git\n\nI'm aware of the workaround to add a README or .gitignore file to the\nempty dir so it can be tracked, but why have a workaround if people\nwant to add empty dirs. If they want an empty one, they want an empty\none without any files in it. And if they don't want an empty one, they\nwant to put something real in it (maybe a README, maybe something\nelse). Thus knowing a dir is empty helps with this point, as the user\ncan do something about it. Leading our discussion to point 2...\n\nNow, let's put discussion no. 1 aside, and tackle the completely\nseparate question \"should empty dirs appear under 'untracked' in git\nstatus\"?\n\nRegardless of whether or not git supports tracking empty dirs, I think\nwe need this feature. There is confusion among people on this topic\n(thus q's on the q&a site). So a helpful message of \"empty dirs cannot\nbe tracked\" will abate that. You bring up a good point with having\nthat message be in the form of a suggestion such as \"empty dir: adding\na file to the dir will allow you to track it\", \"empty dir can't be\ntracked: did you forget to add a file?\", or something of the sorts.\n\nWhy would showing a message about empty dirs in the untracked section help:\n1) Clarifies git's position on the matter, and provides a helpful reminder.\n2) Abates confusion since ppl may think they've already tracked the\ndir (by adding and commit it) and thus it is not appearing under the\nuntracked list.\n3) People use git status to see the state of their working directory.\nFeedback of a dir being empty, because they mistakenly added it and\nforgot to remove it, or forgot to add something to it is helpful.\n\nAnd since untracked means not currently tracked by git, and empty dirs\ncurrently at any given point are untracked, they should appear in this\nlist. So even if you're not sold on discussion no1, I think we need\nthis patch to solve a communication issue, and to serve as a helpful\nreminder which is what git status is all about.\n\nThanks,\nLeila\n"},{"id":"193273","messageId":"20120610201256.Horde.dB69JnwdC4BP1OOoePf1xjA@webmail.minatec.grenoble-inp.fr","threadId":"30754","inReplyTo":"CAA3EhHLWDtUeNB+RZA064Omwxh7SEYhSc53U0nuiSTNzioKnug@mail.gmail.com","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"","fromEmail":"konglu@minatec.inpg.fr","sentAt":"2012-06-10T18:12:56Z","receivedAt":"2012-06-10T18:12:56Z","isPatch":true,"sender":{"key":"konglu@minatec.inpg.fr","avatar":null},"body":"\nLeila <muhtasib@gmail.com> a écrit :\n\n> The question 'why are empty dirs special', is issue no 1, which I'm\n> also happy to discuss. The rule empty dirs can't be added in git is\n> unintuitive, as people use git to keep track of things - all things.\n> So it's not about an empty dir being special, it's about how people\n> use git to keep track of things. Now why might people want empty dirs\n> tracked? 1) People often setup dir structure in projects before adding\n> any code. They often want to save that state for themselves or to\n> share it with other team members.\n\nYup, that kind of situation is not unusual. Thus, having a reminder by\nrunning 'git status' would help. But sharing empty dir with other team\nmembers is another issue, no ? Even with your implementation, the user\nwon't be able to share empty directories.\n\nThanks,\n\nLucien Kong\n"},{"id":"193274","messageId":"CAA3EhHJzyR1pWaEeDp_+xv8LaaxmJfVXi17pNtwW3dAD+9sbFw@mail.gmail.com","threadId":"30754","inReplyTo":"20120610201256.Horde.dB69JnwdC4BP1OOoePf1xjA@webmail.minatec.grenoble-inp.fr","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-10T18:17:02Z","receivedAt":"2012-06-10T18:17:02Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Sun, Jun 10, 2012 at 2:12 PM,  <konglu@minatec.inpg.fr> wrote:\n>\n> Leila <muhtasib@gmail.com> a écrit :\n>\n>\n>> The question 'why are empty dirs special', is issue no 1, which I'm\n>> also happy to discuss. The rule empty dirs can't be added in git is\n>> unintuitive, as people use git to keep track of things - all things.\n>> So it's not about an empty dir being special, it's about how people\n>> use git to keep track of things. Now why might people want empty dirs\n>> tracked? 1) People often setup dir structure in projects before adding\n>> any code. They often want to save that state for themselves or to\n>> share it with other team members.\n>\n>\n> Yup, that kind of situation is not unusual. Thus, having a reminder by\n> running 'git status' would help. But sharing empty dir with other team\n> members is another issue, no ? Even with your implementation, the user\n> won't be able to share empty directories.\n>\n\nYes, there are two issues. I'm advocating for the reminder when\nrunning 'git status'.\n\nSharing empty dirs with other team members is another issue. My\nimplementation does not handle this case.\n\nThanks,\nLeila\n"},{"id":"193310","messageId":"7vtxyh998f.fsf@alter.siamese.dyndns.org","threadId":"30754","inReplyTo":"87haujr15p.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-11T15:08:48Z","receivedAt":"2012-06-11T15:08:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n>>> It's not required, there's plenty of precedent, even one case within\n>>> wt-status.c, of '} else'.  Try running\n>>>\n>>>   git grep '} else$'\n>>\n>> It's not because \"there's plenty of precedent\" that we should not try\n>> to improve the format of the code. That's why there're coding style\n>> rules so that we can keep the improvements consistent.\n>\n> Yeah, and the rules (Documentation/CodingGuidelines) say\n>\n>  - We avoid using braces unnecessarily.  I.e.\n>\n> \tif (bla) {\n> \t\tx = 1;\n> \t}\n>\n>    is frowned upon.  A gray area is when the statement extends\n>    over a few lines, and/or you have a lengthy comment atop of\n>    it.  Also, like in the Linux kernel, if there is a long list\n>    of \"else if\" statements, it can make sense to add braces to\n>    single line blocks.\n>\n> I'm not the one who wrote them, but I'm taking the last sentence to mean\n> that you should not put the braces unless the omission will break the\n> vertical alignment of the 'else if' chain.\n\nThe guidelines are not black-and-white, but the spirit is to suggest\navoiding unnecessary braces around single statement blocks while\nallowing exception when consistency across if/else if/... cascade\nmakes the result easier to read.\n\n> BTW, there are plenty of cases in git where it is better to stick to the\n> existing style of the file instead of the CodingGuidelines, unless you\n> are willing to clean up the file first (and nobody else works on it).\n\nYes.\n"},{"id":"193329","messageId":"7vehpl7pn0.fsf@alter.siamese.dyndns.org","threadId":"30754","inReplyTo":"CAA3EhHLWDtUeNB+RZA064Omwxh7SEYhSc53U0nuiSTNzioKnug@mail.gmail.com","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-11T16:57:23Z","receivedAt":"2012-06-11T16:57:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leila <muhtasib@gmail.com> writes:\n\n>> Having said all that, I personally doubt this is a useful change.  I\n>> may have thought of adding a README file to a relatively new project that\n>> does not yet have one while in shower but I haven't even created the\n>> file in the working tree.  And I forget about it once I get to the\n>> office.  Should the system remind me to create README and then add?\n>> Your patch would not give me such a reminder once the top-level\n>> directory is populated (because it is no longer empty).  Even if I\n>> were planning to add Documentation/README instead, I would get such\n>> a reminder only if the Documentation directory is empty. Once the\n>> directory is populated, I wouldn't get \"create README and then add\".\n>> Why should an empty directory so special?\n>\n> So there are two separate discussions here:\n> 1) Should empty dirs be tracked\n>\n> 2) Should empty dirs appear under 'untracked' in git status\n\nYou are not answering my question by asking either these two\nquestions.\n\nPlease read what you quoted again.  I may have forgotten to create\nand add README\n\n - at the toplevel directory; or\n\n - in the Documentation directory that already has other tracked\n   files; or\n\n - in the Documentation directory that does not have any file yet.\n\nWhy do I get a reminder for only the last case?  Also please realize\nthat at no point in the scenario I am interested in adding an empty\ndirectory.  \"How does one add empty directories\" is irrelevant to my\nquestion.\n\nA more reasonable answer would have been \"the reminder is not about\na yet-to-be-created README file, but is about an empty directory you\nmight have wanted to place something---there is no way for Git to\nguess that you wanted the new file to be README, but at least having\na totally empty directory laying around may be an indication that\nyou wanted to do something intereseting in it but haven't yet\".  If\nthe proposed commit log message justified the behaviour to treat\nonly the third one specially that way, I suspect it may make some\nsense.\n"},{"id":"193347","messageId":"CAA3EhHLDwiCixY2xPRQOsvSv+AAKWUEWo1QgnpZrgDeeMe8wTg@mail.gmail.com","threadId":"30754","inReplyTo":"7vehpl7pn0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-11T18:51:23Z","receivedAt":"2012-06-11T18:51:23Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Mon, Jun 11, 2012 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Leila <muhtasib@gmail.com> writes:\n>\n>>> Having said all that, I personally doubt this is a useful change.  I\n>>> may have thought of adding a README file to a relatively new project that\n>>> does not yet have one while in shower but I haven't even created the\n>>> file in the working tree.  And I forget about it once I get to the\n>>> office.  Should the system remind me to create README and then add?\n>>> Your patch would not give me such a reminder once the top-level\n>>> directory is populated (because it is no longer empty).  Even if I\n>>> were planning to add Documentation/README instead, I would get such\n>>> a reminder only if the Documentation directory is empty. Once the\n>>> directory is populated, I wouldn't get \"create README and then add\".\n>>> Why should an empty directory so special?\n> Please read what you quoted again.  I may have forgotten to create\n> and add README\n>\n>  - at the toplevel directory; or\n>\n>  - in the Documentation directory that already has other tracked\n>   files; or\n>\n>  - in the Documentation directory that does not have any file yet.\n>\n> Why do I get a reminder for only the last case?  Also please realize\n> that at no point in the scenario I am interested in adding an empty\n> directory.  \"How does one add empty directories\" is irrelevant to my\n> question.\n>\n> A more reasonable answer would have been \"the reminder is not about\n> a yet-to-be-created README file, but is about an empty directory you\n> might have wanted to place something---there is no way for Git to\n> guess that you wanted the new file to be README, but at least having\n> a totally empty directory laying around may be an indication that\n> you wanted to do something intereseting in it but haven't yet\".  If\n> the proposed commit log message justified the behaviour to treat\n> only the third one specially that way, I suspect it may make some\n> sense.\n\nI apologize, I misread the scenario and thought you were asking a\ndifferent question.\n\nThe patch/new implementation I put forth reminds you that you have an\nempty dir. The reminder that you have an empty dir  isn't about a\nyet-to-be-created README file, but about an empty directory that you\nmay have wanted to do something interesting in but haven't yet (like\ncreate a README/some other file or delete it even). It servers as\nhelpful reminder to do something with that empty dir. Is that better?\n"},{"id":"193353","messageId":"CAA3EhHLfrb7VV51pEVxsi9ut3zFunbsb=MwqUGi-Yjg3uyT0qQ@mail.gmail.com","threadId":"30754","inReplyTo":"CAA3EhHLDwiCixY2xPRQOsvSv+AAKWUEWo1QgnpZrgDeeMe8wTg@mail.gmail.com","subject":"Re: [PATCH] git-status: Show empty directories","fromName":"Leila","fromEmail":"muhtasib@gmail.com","sentAt":"2012-06-11T19:00:18Z","receivedAt":"2012-06-11T19:00:18Z","isPatch":true,"sender":{"key":"muhtasib@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1618875?v=4"},"body":"On Mon, Jun 11, 2012 at 2:51 PM, Leila <muhtasib@gmail.com> wrote:\n> On Mon, Jun 11, 2012 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Leila <muhtasib@gmail.com> writes:\n>>\n>>>> Having said all that, I personally doubt this is a useful change.  I\n>>>> may have thought of adding a README file to a relatively new project that\n>>>> does not yet have one while in shower but I haven't even created the\n>>>> file in the working tree.  And I forget about it once I get to the\n>>>> office.  Should the system remind me to create README and then add?\n>>>> Your patch would not give me such a reminder once the top-level\n>>>> directory is populated (because it is no longer empty).  Even if I\n>>>> were planning to add Documentation/README instead, I would get such\n>>>> a reminder only if the Documentation directory is empty. Once the\n>>>> directory is populated, I wouldn't get \"create README and then add\".\n>>>> Why should an empty directory so special?\n>> Please read what you quoted again.  I may have forgotten to create\n>> and add README\n>>\n>>  - at the toplevel directory; or\n>>\n>>  - in the Documentation directory that already has other tracked\n>>   files; or\n>>\n>>  - in the Documentation directory that does not have any file yet.\n>>\n>> Why do I get a reminder for only the last case?  Also please realize\n>> that at no point in the scenario I am interested in adding an empty\n>> directory.  \"How does one add empty directories\" is irrelevant to my\n>> question.\n>>\n>> A more reasonable answer would have been \"the reminder is not about\n>> a yet-to-be-created README file, but is about an empty directory you\n>> might have wanted to place something---there is no way for Git to\n>> guess that you wanted the new file to be README, but at least having\n>> a totally empty directory laying around may be an indication that\n>> you wanted to do something intereseting in it but haven't yet\".  If\n>> the proposed commit log message justified the behaviour to treat\n>> only the third one specially that way, I suspect it may make some\n>> sense.\n>\n> I apologize, I misread the scenario and thought you were asking a\n> different question.\n>\n> The patch/new implementation I put forth reminds you that you have an\n> empty dir. The reminder that you have an empty dir  isn't about a\n> yet-to-be-created README file, but about an empty directory that you\n> may have wanted to do something interesting in but haven't yet (like\n> create a README/some other file or delete it even). It servers as\n> helpful reminder to do something with that empty dir. Is that better?\n\nOh and since it's not about the reminder to add a README file, it\ndoesn't do anything for the first 2 cases that you mention. Adding a\nREADME is just an example of a use case for this patch.\n\nThat being said, I like the idea that you put forth about changing the\nwording of the message next to the empty dir to something more\nconstructive or alert like, so the user can take action regarding the\nempty dir.\n"}]}