{"thread":{"id":"49619","subject":"git ls-files --with-tree documentation","startedAt":"2018-10-19T18:33:47Z","lastAt":"2018-10-22T03:22:08Z","messageCount":2,"participants":["Joey Hess","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"360966","messageId":"20181019183335.GA12353@kitenet.net","threadId":"49619","inReplyTo":null,"subject":"git ls-files --with-tree documentation","fromName":"Joey Hess","fromEmail":"id@joeyh.name","sentAt":"2018-10-19T18:33:35Z","receivedAt":"2018-10-19T18:33:47Z","isPatch":false,"sender":{"key":"id@joeyh.name","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"       --with-tree=<tree-ish>\n           When using --error-unmatch to expand the user supplied <file> (i.e.\n           path pattern) arguments to paths, pretend that paths which were\n           removed in the index since the named <tree-ish> are still present.\n           Using this option with -s or -u options does not make any sense.\n\nThis seems to say that it only affects it when --error-unmatch is used,\nbut in fact it goes deeper; for example I can use it to list files that\nare present in either the current work tree or some other branch:\n\njoey@darkstar:/tmp/v> git checkout foo\njoey@darkstar:/tmp/v> git ls-files --with-tree=master\nin-foo\nin-master\njoey@darkstar:/tmp/v> git ls-files\nin-foo\njoey@darkstar:/tmp/v> git ls-tree master \n100644 blob 0242cc10fdf4e9afdfd0928c2a209d4545780168\tin-master\n\nThis is very useful behavior, but I'm not sure if I should rely on it\nbehaving this way in the future, given the documentation.\n\nt/t3060-ls-files-with-tree.sh does indeed test that it\n\"should add entries from named tree\", and it does it without using\n--error-unmatch.\n\nHow about changing the documentation to something like this to make\nmore explicit what it does.\n\n       --with-tree=<tree-ish>\n           Treat all files in the <tree-ish> as if they were present in the index.\n           When using --error-unmatch to expand the user supplied <file> (i.e.\n           path pattern) arguments to paths, this has the effect that paths which were\n           removed in the index since the named <tree-ish> are still present.\n           Using this option with -s or -u options does not make any sense.\n\n-- \nsee shy jo\n"},{"id":"361126","messageId":"xmqq8t2qy8br.fsf@gitster-ct.c.googlers.com","threadId":"49619","inReplyTo":"20181019183335.GA12353@kitenet.net","subject":"Re: git ls-files --with-tree documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-22T03:22:00Z","receivedAt":"2018-10-22T03:22:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joey Hess <id@joeyh.name> writes:\n\n> How about changing the documentation to something like this to make\n> more explicit what it does.\n>\n>        --with-tree=<tree-ish>\n>            Treat all files in the <tree-ish> as if they were present in the index.\n>            When using --error-unmatch to expand the user supplied <file> (i.e.\n>            path pattern) arguments to paths, this has the effect that paths which were\n>            removed in the index since the named <tree-ish> are still present.\n>            Using this option with -s or -u options does not make any sense.\n\nIf <tree-ish> has a file F and the index has a file F/1, I do not\nthink the command can pretend that F is present in the index (which\nrequires it to also pretend that F/1 does not exist), so the above\ndescription is not quite right---the description needs to be\ntightened a bit, I am afraid [*1*].\n\nBut more importantly, given the fact that we needed piecemeal\nfix-ups like 4b4e26d2 (\"Teach ls-files --with-tree=<tree> to work\nwith options other than -c\", 2008-11-16), and the fact that your\ndescription above still mentions \"incompatible with -s\", I strongly\nsuspect that the implementation as-is would still *not* perform the\nway you describe above.  In some modes, it won't pretend as if all\nof <tree-ish> are present in the index.\n\nAnd I do not think I care that much to respond to a bug report that\nclaims the above paragraph describes the way the command ought to\nwork, either, but apparently you do care much more than I do, so\nperhaps you can respond to such bug reports whey they come and I do\nnot have to worry about them too much ;-)\n\n\n[Footnote]\n\n*1* It actually pretends that entries in <tree-ish> are at stage #1,\n    all the originally unmerged entries are at stage #3, and shows\n    entries at stage #0 (i.e. merged entries in the original index)\n    and stage #1 (i.e. from <tree-ish>), but only those that do not\n    have corresponding stage #0 entries.  That is why \"-s\" won't\n    make sense (i.e. from an entry being at stage #3, you cannot\n    tell if it were originally at stage #1, #2 or #3), and \"-u\"\n    won't make sense (i.e. ditto---and there is no good explanation\n    as to why <tree-ish> entries appear at stage #1, other than the\n    real reason: this is only to be able to enumerate all paths that\n    are in <tree-ish> and the index, so that error-unmatch can say\n    \"Ah, that path is in the HEAD so it is not a typo\" even for a\n    path that has been removed from the index when running \"git\n    commit <paths>\").\n\n\n\n"}]}