{"thread":{"id":"16865","subject":"[PATCH] ls-tree: add --full-tree option","startedAt":"2008-12-26T00:54:23Z","lastAt":"2008-12-26T21:38:06Z","messageCount":6,"participants":["Junio C Hamano","Johannes Sixt","demerphq"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"98704","messageId":"7v63l7rc1s.fsf@gitster.siamese.dyndns.org","threadId":"16865","inReplyTo":null,"subject":"[PATCH] ls-tree: add --full-tree option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-26T00:54:23Z","receivedAt":"2008-12-26T00:54:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The established behaviour of \"git ls-tree $commit\" run from a subdirectory\n\"sub/dir\" in a work tree is to limit the output to the paths in the\nsubdirectory, and strip off the leading \"sub/dir\" from the output, since\n3c5e846 (ls-tree: major rewrite to do pathspec, 2005-11-26).\n\nThis was a \"usability\" feature made back in the days when the line between\nPorcelain and plumbing was blurry, and in retrospect, it probably was\nmisguided. The behaviour may be what the end user would expect when the\ncommand is run interactively from a subdirectory, but it also means that a\nscripted Porcelain that wants to use the command to list the full contents\nof a tree object has to do cd_to_toplevel (and save the output from\n\"rev-parse --show-prefix\" before doing so, so that it can be used as a\npathspec if it wants to limit its operation to the original subdirectory\nin other commands).\n\nThis new option makes the command operate on the full tree object,\nregardless of where in the work tree it is run from. It also implies the\nbehaviour that is triggered by the existing --full-name option.\n\nSigned-off-by: Junio C Hamano \n---\n * There was a discussion on #git between Ilari and deskin this morning;\n hopefully I captured what they wanted correctly.\n\n I do not care too deeply with this change myself, though...\n\n builtin-ls-tree.c | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-ls-tree.c b/builtin-ls-tree.c\nindex cb61717..c386aa5 100644\n--- a/builtin-ls-tree.c\n+++ b/builtin-ls-tree.c\n@@ -156,6 +156,11 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)\n \t\t\t\tchomp_prefix = 0;\n \t\t\t\tbreak;\n \t\t\t}\n+\t\t\tif (!strcmp(argv[1]+2, \"full-tree\")) {\n+\t\t\t\tls_tree_prefix = prefix = NULL;\n+\t\t\t\tchomp_prefix = 0;\n+\t\t\t\tbreak;\n+\t\t\t}\n \t\t\tif (!prefixcmp(argv[1]+2, \"abbrev=\")) {\n \t\t\t\tabbrev = strtoul(argv[1]+9, NULL, 10);\n \t\t\t\tif (abbrev && abbrev < MINIMUM_ABBREV)\n-- \n1.6.1\n"},{"id":"98712","messageId":"200812260916.45401.j6t@kdbg.org","threadId":"16865","inReplyTo":"7v63l7rc1s.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] ls-tree: add --full-tree option","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2008-12-26T08:16:45Z","receivedAt":"2008-12-26T08:16:45Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Freitag, 26. Dezember 2008, Junio C Hamano wrote:\n> This new option makes the command operate on the full tree object,\n> regardless of where in the work tree it is run from. It also implies the\n> behaviour that is triggered by the existing --full-name option.\n\nWhat's wrong with using 'git ls-tree ${rev}:'?\n\nExcept that it does not work and still silently inserts the subdirectory, \nwhich I consider a serious bug...\n\n-- Hannes\n"},{"id":"98714","messageId":"7vmyejpb6o.fsf@gitster.siamese.dyndns.org","threadId":"16865","inReplyTo":"200812260916.45401.j6t@kdbg.org","subject":"Re: [PATCH] ls-tree: add --full-tree option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-26T08:55:59Z","receivedAt":"2008-12-26T08:55:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> On Freitag, 26. Dezember 2008, Junio C Hamano wrote:\n>> This new option makes the command operate on the full tree object,\n>> regardless of where in the work tree it is run from. It also implies the\n>> behaviour that is triggered by the existing --full-name option.\n>\n> What's wrong with using 'git ls-tree ${rev}:'?\n>\n> Except that it does not work...\n\nHmph... you seem to be describing the exact issue they discussed on #git,\nwhich triggered the patch in the message you are responding to. I am not\nsure what to say to your \"What's wrong with...\".\n"},{"id":"98720","messageId":"9b18b3110812260231u8e81be6n44d3ccf43ac4438b@mail.gmail.com","threadId":"16865","inReplyTo":"7vmyejpb6o.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] ls-tree: add --full-tree option","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2008-12-26T10:31:27Z","receivedAt":"2008-12-26T10:31:27Z","isPatch":true,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2008/12/26 Junio C Hamano :\n> Johannes Sixt writes:\n>\n>> On Freitag, 26. Dezember 2008, Junio C Hamano wrote:\n>>> This new option makes the command operate on the full tree object,\n>>> regardless of where in the work tree it is run from. It also implies the\n>>> behaviour that is triggered by the existing --full-name option.\n>>\n>> What's wrong with using 'git ls-tree ${rev}:'?\n>>\n>> Except that it does not work...\n>\n> Hmph... you seem to be describing the exact issue they discussed on #git,\n> which triggered the patch in the message you are responding to. I am not\n> sure what to say to your \"What's wrong with...\".\n\nAFAIK I started that discussion, and during it we also mentioned that\nit would be very useful to be able to use git ls-files in non\nrecursive mode. As the advantage of using ls-tree, prior to your fix,\nwas that it is the only way to get a list of files for the current\nworking directory and only the current working directory.\n\nSince you have fixed that bug what command does one us to get a list\nof tracked files for the current working directory without recursing\ninto subdirectories? Can we have a switch on ls-files that disables\nrecursion? Please?\n\nCheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"98739","messageId":"49553561.4030902@kdbg.org","threadId":"16865","inReplyTo":"7vmyejpb6o.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] ls-tree: add --full-tree option","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2008-12-26T19:49:53Z","receivedAt":"2008-12-26T19:49:53Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Johannes Sixt writes:\n> \n>> On Freitag, 26. Dezember 2008, Junio C Hamano wrote:\n>>> This new option makes the command operate on the full tree object,\n>>> regardless of where in the work tree it is run from. It also implies the\n>>> behaviour that is triggered by the existing --full-name option.\n>> What's wrong with using 'git ls-tree ${rev}:'?\n>>\n>> Except that it does not work...\n> \n> Hmph... you seem to be describing the exact issue they discussed on #git,\n> which triggered the patch in the message you are responding to. I am not\n> sure what to say to your \"What's wrong with...\".\n\nI'm saying that if a script has to be fixed to use --full-tree, then it \ncan be fixed just as well by appending the colon to the ${rev}.\n\nNot even porcelain 'git show ${rev}:' \"is allowed\" to insert the prefix. \nDscho has argued the case passionately in the past:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/68786/focus=68846\n\nTherefore, plumbing 'ls-tree ${rev}:' shouldn't do that, either.\n\nOTOH, you had yourself argued somewhat in favor of the current ls-tree \nbehavior:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/46232/focus=46400\n\nI'm personally more in line with Dscho, and think that the current \nls-tree behavior is a terrible bug.\n\n-- Hannes\n"},{"id":"98742","messageId":"7veizulirl.fsf@gitster.siamese.dyndns.org","threadId":"16865","inReplyTo":"49553561.4030902@kdbg.org","subject":"Re: [PATCH] ls-tree: add --full-tree option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-26T21:38:06Z","receivedAt":"2008-12-26T21:38:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> I'm saying that if a script has to be fixed to use --full-tree, then\n> it can be fixed just as well by appending the colon to the ${rev}.\n\nI do not agree with your \"just as well\"; an existing script that feeds a\ntree object to the plumbing would be broken by such a change.\n\nBut I think perhaps you were responding to the first paragraph of the\ncommit log message that you omitted from your quote?\n\nJC> The established behaviour of \"git ls-tree $commit\" run from a\nJC> subdirectory \"sub/dir\" in a work tree is to...\n\nIf that is the case, I understand what you meant.\n\nThe patch is about the behaviour of the command for not just $commit but\nany $tree_ish, so \"git ls-tree ${commit}:\" shares the exact same issue\n(i.e. historical background that forbids us from changing the behaviour\nwithout an explicit option, and that --full-tree can be a way to help new\nscripts without breaking existing scripts' expectations).\n\nI've updated the commit log message with s/$commit/$tree_ish/;\n\n> OTOH, you had yourself argued somewhat in favor of the current ls-tree\n> behavior:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/46232/focus=46400\n\nThat's not really \"somewhat in favor\". I can be (and am more often than\nnot) sympathetic without agreeing to the end result. My sympathy extends\nfrom \"I can sort-of-kind-of imagine that it may hurt, and even though I do\nnot think your approach is a way to properly address it at all, I'd agree\nit might be nice to have some solution to the issue\" to \"I do not think it\nis feasible to change this anymore, but I wish we could, too.\"\n\nIn any case, the quoted message was from May 2007, way before v1.6.0 when\nwe learned the hard way that people do not want any change.\n\nI really hate \"take it or leave it\", especially when it is not my itch to\nscratch, but in this case, I think I've spent enough time making myself\nclear that I think (1) that the current behaviour is a result of misguided\nattempt for interactive user expectation, which shouldn't have made to the\nplumbing, (2) that we cannot change the default behaviour now even (1) is\ntrue; and (3) that the only possible approach to help new scripts would be\na new option.\n"}]}