{"thread":{"id":"30599","subject":"Interpretation of '/' changed sparse-checkout","startedAt":"2012-05-23T13:40:16Z","lastAt":"2012-05-25T10:21:10Z","messageCount":4,"participants":["Caleb Marchent","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"191979","messageId":"loom.20120521T183651-286@post.gmane.org","threadId":"30599","inReplyTo":null,"subject":"Interpretation of '/' changed sparse-checkout","fromName":"Caleb Marchent","fromEmail":"cmarchent@aminocom.com","sentAt":"2012-05-23T13:40:16Z","receivedAt":"2012-05-23T13:40:16Z","isPatch":false,"sender":{"key":"cmarchent@aminocom.com","avatar":null},"body":"I have a system where I checkout by default everything except one directory. \nThen the rules in the top-level sources can selectivly reintroduce \nsubdirectories as required for the build target.\nI have deployed, using git 1.7.2.5, a set of git trees which use the following \nsparse-checkout rules to achieve this.\n\n/\n!exclude/\nexclude/reinclude\n\nI have however discovered that if the reincluded directory is the same as the \nfirst part of any other path then that path will also be checked out.\n\n/\n!exlcude\nexclude/wanted\n\nwill checkout both:\n\nexclude/wanted\nexclude/wanted_not\n\nThis appears to have bee fixed in git 1.7.10.2 but from that version of git \nonwards using '/' to request everything and then exclude a specific directory \nfrom it no longer works.\n\nWhile I have been able to contrive the same effect with recent versions of git \nusing the following updated sparse-checkout rules\n\n/*\n!exclude/\nexclude/reinclude\n\nEven with this work-around there are two problems:\n\n1) If I have a path: exclude/reinclude/exclude, this will now be exluded where I \nwould expect it to be included as it was with 1.7.2.5\n\n2) I have a large number of deployed trees across a number of machines that have \nthe existing format which will break when git operations are performed after a \nupgrade to the latest git.\n\nI believe that the interpretation of '/' should be 'everything in the repo', \nfrom which later rules can exclude. I think this is a bug in recent versions of \ngit. I have been working on some ideas for a fix to the git code based along \nthese lines. Can anyone confirm if my analysis is correct or provide an \nalternate solution?\n\nAlso I would like to know if anyone knows the solution to point 1) above as this \nalso blocks upgrading to the latest version of git.\n"},{"id":"191980","messageId":"loom.20120523T160215-390@post.gmane.org","threadId":"30599","inReplyTo":"loom.20120521T183651-286@post.gmane.org","subject":"Re: Interpretation of '/' changed sparse-checkout","fromName":"Caleb Marchent","fromEmail":"cmarchent@aminocom.com","sentAt":"2012-05-23T14:09:24Z","receivedAt":"2012-05-23T14:09:24Z","isPatch":false,"sender":{"key":"cmarchent@aminocom.com","avatar":null},"body":"Caleb Marchent <cmarchent <at> aminocom.com> writes:\n\nCorrected cut-paste errors on first submission, seems I missed a bunch of \nterminating '/' when hand-copying the text in from the sparse-checkout files :-( \nSorry.\n\nI have a system where I checkout by default everything except one directory. \nThen the rules in the top-level sources can selectivly reintroduce \nsubdirectories as required for the build target.\nI have deployed, using git 1.7.2.5, a set of git trees which use the following \nsparse-checkout rules to achieve this.\n\n/\n!exclude/\nexclude/reinclude/\n\n\nI have however discovered that if the reincluded directory is the same as the \nfirst part of any other path then that path will also be checked out.\n \n/\n!exlcude/\nexclude/wanted/\n\n \nwill checkout both:\n\nexclude/wanted/\nexclude/wanted_not/\n\n\nThis appears to have bee fixed in git 1.7.10.2 but from that version of git \nonwards using '/' to request everything and then exclude a specific directory \nfrom it no longer works.\n \nWhile I have been able to contrive the same effect with recent versions of git \nusing the following updated sparse-checkout rules\n \n/*\n!exclude/\nexclude/reinclude/\n\n \nEven with this work-around there are two problems:\n\n1) If I have a path: exclude/reinclude/exclude, this will now be exluded where \nI would expect it to be included as it was with 1.7.2.5\n \n2) I have a large number of deployed trees across a number of machines that \nhave the existing format which will break when git operations are performed \nafter a upgrade to the latest git.\n \nI believe that the interpretation of '/' should be 'everything in the repo', \nfrom which later rules can exclude. I think this is a bug in recent versions \nof git. I have been working on some ideas for a fix to the git code based along \nthese lines. Can anyone confirm if my analysis is correct or provide an \nalternate solution?\n \nAlso I would like to know if anyone knows the solution to point 1) above as \nthis also blocks upgrading to the latest version of git.\n \n \n"},{"id":"192079","messageId":"20120524142858.GA10938@do","threadId":"30599","inReplyTo":"loom.20120523T160215-390@post.gmane.org","subject":"Re: Interpretation of '/' changed sparse-checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-05-24T14:28:58Z","receivedAt":"2012-05-24T14:28:58Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nOn Wed, May 23, 2012 at 02:09:24PM +0000, Caleb Marchent wrote:\n> Caleb Marchent <cmarchent <at> aminocom.com> writes:\n> \n> Corrected cut-paste errors on first submission, seems I missed a bunch of \n> terminating '/' when hand-copying the text in from the sparse-checkout files :-( \n> Sorry.\n> \n> I have a system where I checkout by default everything except one directory. \n> Then the rules in the top-level sources can selectivly reintroduce \n> subdirectories as required for the build target.\n> I have deployed, using git 1.7.2.5, a set of git trees which use the following \n> sparse-checkout rules to achieve this.\n> \n> /\n> !exclude/\n> exclude/reinclude/\n> \n> \n> I have however discovered that if the reincluded directory is the same as the \n> first part of any other path then that path will also be checked out.\n>  \n> /\n> !exlcude/\n> exclude/wanted/\n> \n>  \n> will checkout both:\n> \n> exclude/wanted/\n> exclude/wanted_not/\n> \n> \n> This appears to have bee fixed in git 1.7.10.2 but from that version of git \n> onwards using '/' to request everything and then exclude a specific directory \n> from it no longer works.\n\nAs a user I agree that \"/\" should mean \"everything under the sky\" and\nyour use case should work (i.e. it is broken in 1.7.10.2). If you can\nbuild git, you can try the patch below. I'll submit a patch for\ninclusion to git later (perhaps with optimization for this special case).\n\n-- 8< --\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex bcee99c..188c196 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -838,7 +838,8 @@ static int clear_ce_flags_dir(struct cache_entry **cache, int nr,\n \tint dtype = DT_DIR;\n \tint ret = excluded_from_list(prefix, prefix_len, basename, &dtype, el);\n \n-\tprefix[prefix_len++] = '/';\n+\tif (prefix_len)\n+\t\tprefix[prefix_len++] = '/';\n \n \t/* If undecided, use matching result of parent dir in defval */\n \tif (ret < 0)\n@@ -953,10 +954,12 @@ static int clear_ce_flags(struct cache_entry **cache, int nr,\n \t\t\t    struct exclude_list *el)\n {\n \tchar prefix[PATH_MAX];\n-\treturn clear_ce_flags_1(cache, nr,\n-\t\t\t\tprefix, 0,\n-\t\t\t\tselect_mask, clear_mask,\n-\t\t\t\tel, 0);\n+\t*prefix = '\\0';\n+\treturn clear_ce_flags_dir(cache, nr,\n+\t\t\t\t  prefix, 0,\n+\t\t\t\t  \"\",\n+\t\t\t\t  select_mask, clear_mask,\n+\t\t\t\t  el, 0);\n }\n \n /*\n\n-- 8< --\n\n>  \n> While I have been able to contrive the same effect with recent versions of git \n> using the following updated sparse-checkout rules\n>  \n> /*\n> !exclude/\n> exclude/reinclude/\n> \n>  \n> Even with this work-around there are two problems:\n> \n> 1) If I have a path: exclude/reinclude/exclude, this will now be exluded where \n> I would expect it to be included as it was with 1.7.2.5\n>  \n> 2) I have a large number of deployed trees across a number of machines that \n> have the existing format which will break when git operations are performed \n> after a upgrade to the latest git.\n>  \n> I believe that the interpretation of '/' should be 'everything in the repo', \n> from which later rules can exclude. I think this is a bug in recent versions \n> of git. I have been working on some ideas for a fix to the git code based along \n> these lines. Can anyone confirm if my analysis is correct or provide an \n> alternate solution?\n>  \n> Also I would like to know if anyone knows the solution to point 1) above as \n> this also blocks upgrading to the latest version of git.\n\n-- \nDuy\n"},{"id":"192159","messageId":"loom.20120525T120226-506@post.gmane.org","threadId":"30599","inReplyTo":"20120524142858.GA10938@do","subject":"Re: Interpretation of '/' changed sparse-checkout","fromName":"Caleb Marchent","fromEmail":"cmarchent@aminocom.com","sentAt":"2012-05-25T10:21:10Z","receivedAt":"2012-05-25T10:21:10Z","isPatch":false,"sender":{"key":"cmarchent@aminocom.com","avatar":null},"body":"Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:\n\n> \n> As a user I agree that \"/\" should mean \"everything under the sky\" and\n> your use case should work (i.e. it is broken in 1.7.10.2). If you can\n> build git, you can try the patch below. I'll submit a patch for\n> inclusion to git later (perhaps with optimization for this special case).\n> \n\nMany Thanks Duy!, that patch works so please do submit the patch.\n\n\nThat just leaves the other issue I noted in my original posting - if I \nexclude a path from the top-level with a 1.7.2.5 format sparse-checkout\n file, git 1.7.10.2 will exclude a sub-directory with the same name:\n\n/\n!exclude/\n\nUnfortunately (for me), I think this is correct behaviour of 1.7.10.2 \nbecause in 1.7.10.2 you can now do: \n\n/\n!/exclude/\n/exlucde/reinclude/\n\nwhich makes sense and correctly excludes \"/exclude\", but not \n\"/exclude/reinclude/exclude\". The flexibility to have:\n\n/\n!CVS/\n\nor something like that is required; so I don't believe should be changed?\n"}]}