{"thread":{"id":"6306","subject":"[PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","startedAt":"2007-01-09T14:03:08Z","lastAt":"2007-01-10T00:54:43Z","messageCount":6,"participants":["Johannes Schindelin","Alex Riesen","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"31242","messageId":"Pine.LNX.4.63.0701091502030.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6306","inReplyTo":null,"subject":"[PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-09T14:03:08Z","receivedAt":"2007-01-09T14:03:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nIf the cache tree is not up-to-date, it will be updated first. So, now\n\n        $ git show :Documentation/\n\nwill in effect show what files/directories are in the index' version\nof the directory Documentation. The commands\n\n        $ git show :/\n        $ git show :\n\nare equivalent and show the index' idea of the root directory.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n\t'tis a resend of an earlier patch, but without support for the\n\tbogus \":.\" as equivalent to \":/\".\n\n\tI find this feature highly convenient when I just want to see\n\twhat files the index contains.\n\n sha1_name.c |   20 +++++++++++++++++++-\n 1 files changed, 19 insertions(+), 1 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 6d7cd78..6baa7a4 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -5,6 +5,7 @@\n #include \"blob.h\"\n #include \"tree-walk.h\"\n #include \"refs.h\"\n+#include \"cache-tree.h\"\n \n static int find_short_object_filename(int len, const char *name, unsigned char *sha1)\n {\n@@ -532,7 +533,7 @@ int get_sha1(const char *name, unsigned char *sha1)\n \t */\n \tif (name[0] == ':') {\n \t\tint stage = 0;\n-\t\tstruct cache_entry *ce;\n+\t\tstruct cache_entry *ce = NULL;\n \t\tint pos;\n \t\tif (namelen < 3 ||\n \t\t    name[2] != ':' ||\n@@ -561,6 +562,23 @@ int get_sha1(const char *name, unsigned char *sha1)\n \t\t\t}\n \t\t\tpos++;\n \t\t}\n+\t\tif (namelen > 0 && cp[namelen - 1] == '/')\n+\t\t\tnamelen--;\n+\t\tif (namelen == 0 || (ce && ce_namelen(ce) > namelen &&\n+\t\t\t\t\tce->name[namelen] == '/' &&\n+\t\t\t\t\t!memcmp(ce->name, cp, namelen))) {\n+\t\t\tstruct cache_tree *tree =\n+\t\t\t\tcache_tree_find(active_cache_tree, cp);\n+\t\t\tif (!cache_tree_fully_valid(tree)) {\n+\t\t\t\tret = cache_tree_update(active_cache_tree,\n+\t\t\t\t\t\tactive_cache, active_nr, 0, 0);\n+\t\t\t\tif (ret < 0)\n+\t\t\t\t\treturn ret;\n+\t\t\t\ttree = cache_tree_find(active_cache_tree, cp);\n+\t\t\t}\n+\t\t\thashcpy(sha1, tree->sha1);\n+\t\t\treturn 0;\n+\t\t}\n \t\treturn -1;\n \t}\n \tfor (cp = name, bracket_depth = 0; *cp; cp++) {\n"},{"id":"31260","messageId":"81b0412b0701090925p158e87an14da5cde33436f30@mail.gmail.com","threadId":"6306","inReplyTo":"Pine.LNX.4.63.0701091502030.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-09T17:25:13Z","receivedAt":"2007-01-09T17:25:13Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/9/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> \t'tis a resend of an earlier patch, but without support for the\n> \tbogus \":.\" as equivalent to \":/\".\n\nThanks :)\n\n> \tI find this feature highly convenient when I just want to see\n> \twhat files the index contains.\n\nI find it very useful too.\n"},{"id":"31311","messageId":"7vodp7iwzu.fsf@assigned-by-dhcp.cox.net","threadId":"6306","inReplyTo":"Pine.LNX.4.63.0701091502030.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-09T23:47:01Z","receivedAt":"2007-01-09T23:47:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> \t'tis a resend of an earlier patch, but without support for the\n> \tbogus \":.\" as equivalent to \":/\".\n>\n> \tI find this feature highly convenient when I just want to see\n> \twhat files the index contains.\n\nI do not understand; do you mean ls-files?\n\nIn any case, I wonder if this does a sane thing if you asked\n\"git show :3:t/\" on a fully merged index.\n\n> @@ -561,6 +562,23 @@ int get_sha1(const char *name, unsigned char *sha1)\n>  \t\t\t}\n>  \t\t\tpos++;\n>  \t\t}\n> +\t\tif (namelen > 0 && cp[namelen - 1] == '/')\n> +\t\t\tnamelen--;\n> +\t\tif (namelen == 0 || (ce && ce_namelen(ce) > namelen &&\n> +\t\t\t\t\tce->name[namelen] == '/' &&\n> +\t\t\t\t\t!memcmp(ce->name, cp, namelen))) {\n\nI may be misreading the code, but what does ce point at?  Does\nthis get the index sort order correctly?  For example, would\nthis work?\n\n\t$ echo >t- && git add t-\n        $ git show :t\n\t$ git show :t/\n\n> +\t\t\tstruct cache_tree *tree =\n> +\t\t\t\tcache_tree_find(active_cache_tree, cp);\n> +\t\t\tif (!cache_tree_fully_valid(tree)) {\n> +\t\t\t\tret = cache_tree_update(active_cache_tree,\n> +\t\t\t\t\t\tactive_cache, active_nr, 0, 0);\n> +\t\t\t\tif (ret < 0)\n> +\t\t\t\t\treturn ret;\n\nThis gracefully errs out when the index is unmerged but fails to\npretend the index knows about trees, if the unmerged part of\nindex is outside the directory the user specified.\n\nIn short, I am not sure if it is worth it, and especially if the\nmotivation is to pretend as if the index contains trees, I would\nbe opposed to it.  The index does _not_ contain trees, and\ncache-tree is a pure optimization for the next write-tree.\nNothing more.\n\nIf it (pretending as if the index contains trees) is just a\nmeans to achieve something else worthy, I would not necessarily\noppose to that goal, but I do not see what it is, and I do not\nknow if the approach is right...\n"},{"id":"31321","messageId":"Pine.LNX.4.63.0701100108460.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6306","inReplyTo":"7vodp7iwzu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-10T00:22:44Z","receivedAt":"2007-01-10T00:22:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > \t'tis a resend of an earlier patch, but without support for the\n> > \tbogus \":.\" as equivalent to \":/\".\n> >\n> > \tI find this feature highly convenient when I just want to see\n> > \twhat files the index contains.\n> \n> I do not understand; do you mean ls-files?\n\nIt is the same as ls-files, except \"show\" is shorter, is labeled as \nporcelain, easier to remember, _and_ it runs the pager automatically.\n\n> In any case, I wonder if this does a sane thing if you asked\n> \"git show :3:t/\" on a fully merged index.\n\nNo. That slipped through. The code will just ignore the stage (if \nspecified) for trees.\n\n> > @@ -561,6 +562,23 @@ int get_sha1(const char *name, unsigned char *sha1)\n> >  \t\t\t}\n> >  \t\t\tpos++;\n> >  \t\t}\n> > +\t\tif (namelen > 0 && cp[namelen - 1] == '/')\n> > +\t\t\tnamelen--;\n> > +\t\tif (namelen == 0 || (ce && ce_namelen(ce) > namelen &&\n> > +\t\t\t\t\tce->name[namelen] == '/' &&\n> > +\t\t\t\t\t!memcmp(ce->name, cp, namelen))) {\n> \n> I may be misreading the code, but what does ce point at?  Does\n> this get the index sort order correctly?\n\nIt is still at what cache_name_pos(cp, namelen) pointed to, or NULL if \nthe entry does not exist (e.g. there is no cache entry, or all cache \nentries are lexicographically smaller).\n\n> For example, would this work?\n> \n> \t$ echo >t- && git add t-\n>         $ git show :t\n> \t$ git show :t/\n\nI think so: The code explicitely checks for a trailing '/'. (See second \nlast line of the hunk you quoted.)\n\n> > +\t\t\tstruct cache_tree *tree =\n> > +\t\t\t\tcache_tree_find(active_cache_tree, cp);\n> > +\t\t\tif (!cache_tree_fully_valid(tree)) {\n> > +\t\t\t\tret = cache_tree_update(active_cache_tree,\n> > +\t\t\t\t\t\tactive_cache, active_nr, 0, 0);\n> > +\t\t\t\tif (ret < 0)\n> > +\t\t\t\t\treturn ret;\n> \n> This gracefully errs out when the index is unmerged but fails to\n> pretend the index knows about trees, if the unmerged part of\n> index is outside the directory the user specified.\n\nThat is correct. But in that case, we cannot sanely ask the question \"what \nwould the tree object look like if we committed right now?\"\n\n> In short, I am not sure if it is worth it, and especially if the \n> motivation is to pretend as if the index contains trees, I would be \n> opposed to it.  The index does _not_ contain trees, and cache-tree is a \n> pure optimization for the next write-tree. Nothing more.\n\nWell, it _is_ the method to construct tree objects for committing them.\n\n> If it (pretending as if the index contains trees) is just a means to \n> achieve something else worthy, I would not necessarily oppose to that \n> goal, but I do not see what it is, and I do not know if the approach is \n> right...\n\nI wanted to have it for teaching purposes. And maybe a little bit for \ncompleteness.\n\nBut then it turned out that I even use it before committing, like when I \nask \"what files would be in my next revision?\" It is not a question \narising daily, but sometimes it is interesting to see _before_ committing \nthem. (Note that I am not only interested in the _modified_ files.)\n\nBut if you feel strongly about that feature, don't take the patch.\n\nCiao,\nDscho\n"},{"id":"31326","messageId":"7vtzyzhg47.fsf@assigned-by-dhcp.cox.net","threadId":"6306","inReplyTo":"Pine.LNX.4.63.0701100108460.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-10T00:36:56Z","receivedAt":"2007-01-10T00:36:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> It is still at what cache_name_pos(cp, namelen) pointed to, or NULL if \n> the entry does not exist (e.g. there is no cache entry, or all cache \n> entries are lexicographically smaller).\n>\n>> For example, would this work?\n>> \n>> \t$ echo >t- && git add t-\n>>         $ git show :t\n>> \t$ git show :t/\n>\n> I think so: The code explicitely checks for a trailing '/'. (See second \n> last line of the hunk you quoted.)\n\nThe comment was not about the trailing / version, but the one without.\nHave you tried them?  \n\n>> > +\t\t\tstruct cache_tree *tree =\n>> > +\t\t\t\tcache_tree_find(active_cache_tree, cp);\n>> > +\t\t\tif (!cache_tree_fully_valid(tree)) {\n>> > +\t\t\t\tret = cache_tree_update(active_cache_tree,\n>> > +\t\t\t\t\t\tactive_cache, active_nr, 0, 0);\n>> > +\t\t\t\tif (ret < 0)\n>> > +\t\t\t\t\treturn ret;\n>> \n>> This gracefully errs out when the index is unmerged but fails to\n>> pretend the index knows about trees, if the unmerged part of\n>> index is outside the directory the user specified.\n>\n> That is correct. But in that case, we cannot sanely ask the question \"what \n> would the tree object look like if we committed right now?\"\n\nBut that is not the question you are asking.  \"git-ls-files t/\"\ndoes work even though you still have cache.h unmerged in the\nindex.\n\n> But then it turned out that I even use it before committing, like when I \n> ask \"what files would be in my next revision?\" It is not a question \n> arising daily, but sometimes it is interesting to see _before_ committing \n> them. (Note that I am not only interested in the _modified_ files.)\n\nSo it really is about being able to say show while you mean ls-files.\n\nI am not opposed to that goal at all.  I think it makes it\neasier to type.  But I think using cache-tree is a wrong\napproach.\n"},{"id":"31331","messageId":"Pine.LNX.4.63.0701100151230.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6306","inReplyTo":"7vtzyzhg47.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-10T00:54:43Z","receivedAt":"2007-01-10T00:54:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > It is still at what cache_name_pos(cp, namelen) pointed to, or NULL if \n> > the entry does not exist (e.g. there is no cache entry, or all cache \n> > entries are lexicographically smaller).\n> >\n> >> For example, would this work?\n> >> \n> >> \t$ echo >t- && git add t-\n> >>         $ git show :t\n> >> \t$ git show :t/\n> >\n> > I think so: The code explicitely checks for a trailing '/'. (See second \n> > last line of the hunk you quoted.)\n> \n> The comment was not about the trailing / version, but the one without.\n> Have you tried them?\n\nOf course not! I had the impression that cache_name_pos() just _had_ to \nfind the correct spot, but of course you are right: it does not.\n\n> >> > +\t\t\tstruct cache_tree *tree =\n> >> > +\t\t\t\tcache_tree_find(active_cache_tree, cp);\n> >> > +\t\t\tif (!cache_tree_fully_valid(tree)) {\n> >> > +\t\t\t\tret = cache_tree_update(active_cache_tree,\n> >> > +\t\t\t\t\t\tactive_cache, active_nr, 0, 0);\n> >> > +\t\t\t\tif (ret < 0)\n> >> > +\t\t\t\t\treturn ret;\n> >> \n> >> This gracefully errs out when the index is unmerged but fails to\n> >> pretend the index knows about trees, if the unmerged part of\n> >> index is outside the directory the user specified.\n> >\n> > That is correct. But in that case, we cannot sanely ask the question \"what \n> > would the tree object look like if we committed right now?\"\n> \n> But that is not the question you are asking.  \"git-ls-files t/\"\n> does work even though you still have cache.h unmerged in the\n> index.\n\nAh! I retract that. I did _not_ want the recursive file list. I wanted the \nequivalent of HEAD:t/ _after_ a commit.\n\n> > But then it turned out that I even use it before committing, like when I \n> > ask \"what files would be in my next revision?\" It is not a question \n> > arising daily, but sometimes it is interesting to see _before_ committing \n> > them. (Note that I am not only interested in the _modified_ files.)\n> \n> So it really is about being able to say show while you mean ls-files.\n> \n> I am not opposed to that goal at all.  I think it makes it\n> easier to type.  But I think using cache-tree is a wrong\n> approach.\n\nWell, you are the master.\n\nCiao,\nDscho\n"}]}