{"thread":{"id":"30522","subject":"ls-tree and wildcards","startedAt":"2012-05-12T15:07:41Z","lastAt":"2012-05-15T15:35:23Z","messageCount":6,"participants":["Ryan McCue","Nguyen Thai Ngoc Duy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"191456","messageId":"4FAE7CBD.3020605@rotorised.com","threadId":"30522","inReplyTo":null,"subject":"ls-tree and wildcards","fromName":"Ryan McCue","fromEmail":"lists@rotorised.com","sentAt":"2012-05-12T15:07:41Z","receivedAt":"2012-05-12T15:07:41Z","isPatch":false,"sender":{"key":"lists@rotorised.com","avatar":null},"body":"Good evening folks,\n\nI'm attempting to grab relevant information for files in a tree matching \na given pattern with wildcards. The help for ls-tree indicates that it \ncan accept a pattern of files to match, however I'm not able to see that.\n\n$ git ls-tree origin/master\n...\n100644 blob 8c391e8fb44a38e1389a710ebf8af79612e592a6    screenshot-1.png\n100644 blob ecb7159c1c02567e9cd5da83c254c538d331f733    screenshot-2.png\n100644 blob f58eea7e27f98c01038262b823aa73ccd64cb01e    screenshot-3.png\n100644 blob 07e64def408145660cee657a46947077374762cc    screenshot-4.png\n$ git ls-tree origin/master screenshot*\n$\n\n(I've also tried quoting to ensure it's not bash playing up)\n\nIs there some issue with the command I'm issuing? The documentation \nseems to indicate that I should be getting back the files which match \nthe pattern.\n\nThanks,\n\n-- \nRyan McCue\n<http://ryanmccue.info/>\n"},{"id":"191457","messageId":"CACsJy8A73D_39ND-aqF0nECcKqjLHeqvEJ_XbT3BJd-0cLV1Nw@mail.gmail.com","threadId":"30522","inReplyTo":"4FAE7CBD.3020605@rotorised.com","subject":"Re: ls-tree and wildcards","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-05-12T15:40:49Z","receivedAt":"2012-05-12T15:40:49Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 12, 2012 at 10:07 PM, Ryan McCue <lists@rotorised.com> wrote:\n> Good evening folks,\n>\n> I'm attempting to grab relevant information for files in a tree matching a\n> given pattern with wildcards. The help for ls-tree indicates that it can\n> accept a pattern of files to match, however I'm not able to see that.\n>\n> $ git ls-tree origin/master\n> ...\n> 100644 blob 8c391e8fb44a38e1389a710ebf8af79612e592a6    screenshot-1.png\n> 100644 blob ecb7159c1c02567e9cd5da83c254c538d331f733    screenshot-2.png\n> 100644 blob f58eea7e27f98c01038262b823aa73ccd64cb01e    screenshot-3.png\n> 100644 blob 07e64def408145660cee657a46947077374762cc    screenshot-4.png\n> $ git ls-tree origin/master screenshot*\n> $\n>\n> (I've also tried quoting to ensure it's not bash playing up)\n>\n> Is there some issue with the command I'm issuing? The documentation seems to\n> indicate that I should be getting back the files which match the pattern.\n\nI don't think it ever does. There's a mention of \"patterns\" in ls-tree\nman page, which is misleading. We have the facilities to do that now\n(\"lstree -r patterns\" actually) but that might break backward\ncompatibility. For now I guess you can just do\n\nGIT_INDEX_FILE=/tmp/some-temporary-index git read-tree origin/master\nGIT_INDEX_FILE=/tmp/some-temporary-index ls-files <patterns>\n\nA question that might help us understand your use case and give a\nbetter advice, or improve the system: why do you need that?\n-- \nDuy\n"},{"id":"191458","messageId":"4FAE85EA.3050807@rotorised.com","threadId":"30522","inReplyTo":"CACsJy8A73D_39ND-aqF0nECcKqjLHeqvEJ_XbT3BJd-0cLV1Nw@mail.gmail.com","subject":"Re: ls-tree and wildcards","fromName":"Ryan McCue","fromEmail":"lists@rotorised.com","sentAt":"2012-05-12T15:46:50Z","receivedAt":"2012-05-12T15:46:50Z","isPatch":false,"sender":{"key":"lists@rotorised.com","avatar":null},"body":"Nguyen Thai Ngoc Duy wrote:\n> I don't think it ever does. There's a mention of \"patterns\" in ls-tree\n> man page, which is misleading.\n\nAha, I thought this might be the case. Thanks, I'll grep ls-tree then.\n\n> A question that might help us understand your use case and give a\n> better advice, or improve the system: why do you need that?\n\nI need to be able to get all files starting with a certain string \n(\"screenshot-\" in this case) with certain extensions (\"png\", \"jpg\", \n\"jpeg\" or \"gif\" in this case). Passing into grep will do the trick, but \na single command is my preferred option if it exists.\n\nI don't mind this not existing in git (given that piping into grep will \nwork just as well), but reading \"patterns\" on the man page made me think \nit may exist. I think the wording of that should probably be changed to \navoid confusion.\n\nThanks for the response.\n-- \nRyan McCue\n<http://ryanmccue.info/>\n"},{"id":"191503","messageId":"7vbolqiuh1.fsf@alter.siamese.dyndns.org","threadId":"30522","inReplyTo":"4FAE7CBD.3020605@rotorised.com","subject":"Re: ls-tree and wildcards","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-14T16:43:38Z","receivedAt":"2012-05-14T16:43:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan McCue <lists@rotorised.com> writes:\n\n> Good evening folks,\n>\n> I'm attempting to grab relevant information for files in a tree\n> matching a given pattern with wildcards. The help for ls-tree\n> indicates that it can accept a pattern of files to match,...\n\nThere are two uses of \"pattern\" there, and the former is probably OK but\nthe latter is indeed misleading.  Back when we wrote this command, there\nwere two distinct \"pathspec\" families, and ls-tree belong to the one with\n\"diff\" family that did *not* take anything but \"leading path pattern\" (the\nother one from \"ls-files\" and \"grep\" family allowed wildcards).  Giving a\nwildcard to the command in the \"ls-tree/diff\" family was never supported.\n\nLater Nguyen and others started working on unifying the two separate\n\"pathspec\" semantics and we are probably halfway there.  Many of the\ncommands from \"diff/log\" family now can take wildcard (there may be new\nbugs in the codepaths, though), but \"ls-tree\" has not been converted.\n"},{"id":"191545","messageId":"CACsJy8AdoOcUxq+pmhAPxiPAiQc60aCLf7Jt31YFW4+6OHZEEg@mail.gmail.com","threadId":"30522","inReplyTo":"7vbolqiuh1.fsf@alter.siamese.dyndns.org","subject":"Re: ls-tree and wildcards","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-05-15T11:29:53Z","receivedAt":"2012-05-15T11:29:53Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, May 14, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Later Nguyen and others started working on unifying the two separate\n> \"pathspec\" semantics and we are probably halfway there.  Many of the\n> commands from \"diff/log\" family now can take wildcard (there may be new\n> bugs in the codepaths, though), but \"ls-tree\" has not been converted.\n\nDo we break backward compatibility by teaching ls-tree new pathspec\nsemantics? I guess directories with wildcards in the name are rare,\nthe chance of someone doing \"ls-tree a*\" is low. But I may miss\nsomething.\n-- \nDuy\n"},{"id":"191554","messageId":"7vd365foec.fsf@alter.siamese.dyndns.org","threadId":"30522","inReplyTo":"CACsJy8AdoOcUxq+pmhAPxiPAiQc60aCLf7Jt31YFW4+6OHZEEg@mail.gmail.com","subject":"Re: ls-tree and wildcards","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-15T15:35:23Z","receivedAt":"2012-05-15T15:35:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:\n\n> On Mon, May 14, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Later Nguyen and others started working on unifying the two separate\n>> \"pathspec\" semantics and we are probably halfway there.  Many of the\n>> commands from \"diff/log\" family now can take wildcard (there may be new\n>> bugs in the codepaths, though), but \"ls-tree\" has not been converted.\n>\n> Do we break backward compatibility by teaching ls-tree new pathspec\n> semantics? I guess directories with wildcards in the name are rare,\n> the chance of someone doing \"ls-tree a*\" is low. But I may miss\n> something.\n\nIf you change ls-tree to use its paths arguments as pathspec, you will\nbreak backward compatibility.\n\nBut nobody stops us from _adding_ an option to ls-tree to tell it to\nswitch between the two, i.e.\n\n\tgit ls-tree HEAD -- '*.c'\n\tgit ls-tree --pathspec HEAD -- '*.c'\n\nThe former will use the traditional \"leading path match only\" while the\nlatter uses the (to-be) unified \"pathspec\" semantics.\n\nInternally, the implementation could very well do something like this\nafter parsing the options:\n\n\tif (!opt_pathspec)\n        \tprefix \":(noglob)\" to all paths args\n\nand use the updated code with magic pathspec support to handle both cases.\n"}]}