{"thread":{"id":"3913","subject":"[RFC] get_sha1() shorthands for blob/tree objects","startedAt":"2006-04-18T23:45:16Z","lastAt":"2006-04-25T08:46:21Z","messageCount":24,"participants":["Linus Torvalds","Martin Langhoff","Shawn Pearce","Junio C Hamano","Ray Lehtiniemi","Andreas Ericsson","Uwe Zeisberger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18834","messageId":"Pine.LNX.4.64.0604181627101.3701@g5.osdl.org","threadId":"3913","inReplyTo":null,"subject":"[RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-18T23:45:16Z","receivedAt":"2006-04-18T23:45:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n[ NOTE! The reason I put \"RFC\" in the subject rather than \"PATCH\" is that \n I'm not 100% sure this isn't just a \"shiny object\" of mine rather than a \n really useful thing to do. What do people think? Have you ever wanted to \n access individual files in some random revision? Do you think this is \n useful? I think it's cool and _may_ be useful, but I'm not going to \n really push this patch. Consider it a throw-away patch unless somebody \n else finds it intriguing enough.. ]\n\nThis is a fairly straightforward patch to allow \"get_sha1()\" to also have \nshorthands for tree and blob objects.\n\nThe syntax is very simple and intuitive: you can specify a tree or a blob \nby simply specifying :, and get_sha1() will do the SHA1 \nlookup from the tree for you.\n\nYou can currently do it with \"git ls-tree \" and parsing the \noutput, but that's actually pretty awkward.\n\nWith this, you can do something like\n\n\tgit cat-file blob v1.2.4:Makefile\n\nto get the contents of \"Makefile\" at revision v1.2.4.\n\nNow, this isn't necessarily something you really need all that often, but \nthe concept itself is actually pretty powerful. We could, for example, \nallow things like\n\n\tgit diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n\nto see the difference between two arbitrary files in two arbitrary \nrevisions. To do that, the only thing we'd have to do is to make \ngit-diff-tree accept two blobs to diff, in addition to the two trees it \nnow expects.\n\n[ IOW, don't get me wrong: the get_sha1() parsing is just the first step, \n and does _not_ allow that \"git diff\" syntax to work yet. It parses the \n object names fine, but git-diff-tree will currently exit with a \"fatal: \n unable to read source tree\" error message because the objects aren't \n tree objects ]\n\n\t\t\tLinus\n---\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 4f92e12..0cd1139 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -3,6 +3,7 @@ #include \"tag.h\"\n #include \"commit.h\"\n #include \"tree.h\"\n #include \"blob.h\"\n+#include \"diff.h\"\n \n static int find_short_object_filename(int len, const char *name, unsigned char *sha1)\n {\n@@ -449,12 +450,76 @@ static int get_sha1_1(const char *name, \n \treturn get_short_sha1(name, len, sha1, 0);\n }\n \n+static int get_tree_entry(const unsigned char *, const char *, unsigned char *);\n+\n+static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result)\n+{\n+\tint namelen = strlen(name);\n+\twhile (t->size) {\n+\t\tconst char *entry;\n+\t\tconst unsigned char *sha1;\n+\t\tint entrylen, cmp;\n+\t\tunsigned mode;\n+\n+\t\tsha1 = tree_entry_extract(t, &entry, &mode);\n+\t\tupdate_tree_entry(t);\n+\t\tentrylen = strlen(entry);\n+\t\tif (entrylen > namelen)\n+\t\t\tcontinue;\n+\t\tcmp = memcmp(name, entry, entrylen);\n+\t\tif (cmp > 0)\n+\t\t\tcontinue;\n+\t\tif (cmp < 0)\n+\t\t\tbreak;\n+\t\tif (entrylen == namelen) {\n+\t\t\tmemcpy(result, sha1, 20);\n+\t\t\treturn 0;\n+\t\t}\n+\t\tif (name[entrylen] != '/')\n+\t\t\tcontinue;\n+\t\tif (!S_ISDIR(mode))\n+\t\t\tbreak;\n+\t\tif (++entrylen == namelen) {\n+\t\t\tmemcpy(result, sha1, 20);\n+\t\t\treturn 0;\n+\t\t}\n+\t\treturn get_tree_entry(sha1, name + entrylen, result);\n+\t}\n+\treturn -1;\n+}\n+\n+static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1)\n+{\n+\tint retval;\n+\tvoid *tree;\n+\tstruct tree_desc t;\n+\n+\ttree = read_object_with_reference(tree_sha1, tree_type, &t.size, NULL);\n+\tif (!tree)\n+\t\treturn -1;\n+\tt.buf = tree;\n+\tretval = find_tree_entry(&t, name, sha1);\n+\tfree(tree);\n+\treturn retval;\n+}\n+\n /*\n * This is like \"get_sha1_basic()\", except it allows \"sha1 expressions\",\n * notably \"xyz^\" for \"parent of xyz\"\n */\n int get_sha1(const char *name, unsigned char *sha1)\n {\n+\tint ret;\n+\n \tprepare_alt_odb();\n-\treturn get_sha1_1(name, strlen(name), sha1);\n+\tret = get_sha1_1(name, strlen(name), sha1);\n+\tif (ret < 0) {\n+\t\tconst char *cp = strchr(name, ':');\n+\t\tif (cp) {\n+\t\t\tunsigned char tree_sha1[20];\n+\t\t\tif (!get_sha1_1(name, cp-name, tree_sha1))\n+\t\t\t\treturn get_tree_entry(tree_sha1, cp+1, sha1);\n+\t\t}\n+\t}\n+\treturn ret;\n }\n"},{"id":"18838","messageId":"46a038f90604181714j6fce1867wc17952d898f8e7ae@mail.gmail.com","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181627101.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-04-19T00:14:27Z","receivedAt":"2006-04-19T00:14:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/19/06, Linus Torvalds wrote:\n\n> What do people think? Have you ever wanted to\n> access individual files in some random revision? Do you think this is\n> useful?\n\nDefinitely, I've several times had to go through contortions to do\nthis easily, and I've ended up turning to gitweb often to quickly see\nthe state of a file at a given revision.\n\n> With this, you can do something like\n>\n> git cat-file blob v1.2.4:Makefile\n>\n> to get the contents of \"Makefile\" at revision v1.2.4.\n>\n> Now, this isn't necessarily something you really need all that often, but\n> the concept itself is actually pretty powerful. We could, for example,\n> allow things like\n>\n> git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n\nThese two examples are more than enough -- I buy ;-)\n\n\nmartin\n"},{"id":"18841","messageId":"20060419002159.GD8915@spearce.org","threadId":"3913","inReplyTo":"46a038f90604181714j6fce1867wc17952d898f8e7ae@mail.gmail.com","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-04-19T00:21:59Z","receivedAt":"2006-04-19T00:21:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Not that my voice carries much weight, but a coworker has been\nasking for this feature to be added to pg for months. I've just\nbeen too lazy to get around to writing the shell code to do it.\nMaking it part of git cat-file seems like a good idea, making it\nusable by other tools like git diff just rocks. :-)\n\nI think its a very worthwhile addition.\n\nMartin Langhoff wrote:\n> On 4/19/06, Linus Torvalds wrote:\n> \n> > What do people think? Have you ever wanted to\n> > access individual files in some random revision? Do you think this is\n> > useful?\n> \n> Definitely, I've several times had to go through contortions to do\n> this easily, and I've ended up turning to gitweb often to quickly see\n> the state of a file at a given revision.\n> \n> > With this, you can do something like\n> >\n> > git cat-file blob v1.2.4:Makefile\n> >\n> > to get the contents of \"Makefile\" at revision v1.2.4.\n> >\n> > Now, this isn't necessarily something you really need all that often, but\n> > the concept itself is actually pretty powerful. We could, for example,\n> > allow things like\n> >\n> > git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n> \n> These two examples are more than enough -- I buy ;-)\n\n-- \nShawn.\n"},{"id":"18842","messageId":"7vy7y2csv8.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181627101.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-19T00:27:07Z","receivedAt":"2006-04-19T00:27:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> [ NOTE! The reason I put \"RFC\" in the subject rather than \"PATCH\" is that \n> I'm not 100% sure this isn't just a \"shiny object\" of mine rather than a \n> really useful thing to do. What do people think? Have you ever wanted to \n> access individual files in some random revision? Do you think this is \n> useful? I think it's cool and _may_ be useful, but I'm not going to \n> really push this patch. Consider it a throw-away patch unless somebody \n> else finds it intriguing enough.. ]\n\nYes, I wanted to do this myself for a while. The only issue I\nmight have is what the separator character between rev and path\nshould be.\n"},{"id":"18843","messageId":"Pine.LNX.4.64.0604181735480.3701@g5.osdl.org","threadId":"3913","inReplyTo":"7vy7y2csv8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T00:44:13Z","receivedAt":"2006-04-19T00:44:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Junio C Hamano wrote:\n> \n> Yes, I wanted to do this myself for a while. The only issue I\n> might have is what the separator character between rev and path\n> should be.\n\nI didn't put a lot of thought into it, but using ':' not only is pretty \nvisually pleasing, it also means that shell completion automatically works \nat least on bash, even without any git-specific completion rules.\n\nThat's not true for a lot of other special characters: colon really is \nspecial, exactly because it has been used for things like PATH separators, \netc.\n\nI'm a total filename completion junkie - I simply cannot type in a \nfilename any more. I'll literally press to complete even short \nfilenames, just because it gives me that nice confirmation of the \nexistence of the filename (ie I've typed it all in, and the adds the \nspace after the filename).\n\nSo to me, ':' is just clearly superior. I can't think of any other \nseparator that works with filename completion and has no shell issues, \n_and_ looks logical.\n\nAnd I thought we already disallowed ':' in branch names because cogito \nuses them for the strange : syntax.. \n\n\t\tLinus\n"},{"id":"18844","messageId":"Pine.LNX.4.64.0604181745410.3701@g5.osdl.org","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181735480.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T00:47:50Z","receivedAt":"2006-04-19T00:47:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Linus Torvalds wrote:\n> \n> And I thought we already disallowed ':' in branch names because cogito \n> uses them for the strange : syntax.. \n\nBtw, pathnames with ':' in them aren't a problem. It's only revision\nnames that can't have ':' in them and still be used together with this \nsyntax.\n\nIf you have a pathname with ':', it's fine to do\n\n\tgit cat-file v1.2.4:pathname:with:colon\n\nbecause the magic revision parsing only cares about the _first_ colon, and \nwill split that into \"v1.2.4\" and \"pathname:with:colon\" without ever even \nlooking at the other ones.\n\n\t\tLinus\n"},{"id":"18845","messageId":"7vpsjecriu.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181627101.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-19T00:56:09Z","receivedAt":"2006-04-19T00:56:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> \tgit diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n\nThis is interesting.\n\nYet to be born \"internal diff\". Should I start one, or are you\nalready hacking on it?\n"},{"id":"18846","messageId":"Pine.LNX.4.64.0604181805080.3701@g5.osdl.org","threadId":"3913","inReplyTo":"7vpsjecriu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T01:16:10Z","receivedAt":"2006-04-19T01:16:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n> > \tgit diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n> \n> This is interesting.\n> \n> Yet to be born \"internal diff\". Should I start one, or are you\n> already hacking on it?\n\nI'm not working on it, but I might get back to it if nobody else beats me \nto it.\n\nProbably not in the next few days, though, so if you feel the urge, please \ndo look into it.\n\nAnyway, the above syntax would actually work even with the current \nexternal diff, because with my suggested patch we get:\n\n git-rev-parse v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n\nresulting in\n\n\t01c73bdd08e075d650e58664650bcd7fe1cd1551\n\t^a2455b0f8ff1582248b0678b9c85b2f064d972c4\n\n(which are just the SHA1's for the object), and then the external diff \nwill just see that it's two commits, so it decides to just feed them \ndirectly into git-diff-tree.\n\nSo if we added the test for \"are the objects two commits\" to git-diff-tree \nand diffed them directly, it would all \"just work\".\n\nBut you're certainly correct in stating that it would be _cleaner_ to do \nit with a internal \"git diff\" command. Everything should be perfectly set \nup by just calling the regular \"setup_revisions()\", and looking at the \n\"rev.pending_objects\" list.\n\nNow, the thing that an internal \"git diff\" could do better is to notice \nwhen it gets _one_ blob revision, and one filename, ie we could do\n\n\tgit diff v0.99.6:git-commit-script git-commit.sh\n\nwhich parses as one SHA1 of a blob (put onto the rev.pending_objects \nlist), and one filename (in the rev.prune_data array). We could decide to \nautomatically do the \"right thing\" for that case too.\n\n\t\tLinus\n"},{"id":"18847","messageId":"Pine.LNX.4.64.0604181816460.3701@g5.osdl.org","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181805080.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T01:19:14Z","receivedAt":"2006-04-19T01:19:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Linus Torvalds wrote:\n> \n> So if we added the test for \"are the objects two commits\" to git-diff-tree \n> and diffed them directly, it would all \"just work\".\n\nThat \"two commits\" should obviously be \"two blobs\".\n\n\"Dave, my mind is going.. I can feel it..\"\n\n\t\tLinus\n"},{"id":"18848","messageId":"200604181920.35223.rayl@shawcable.com","threadId":"3913","inReplyTo":"20060419002159.GD8915@spearce.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Ray Lehtiniemi","fromEmail":"rayl@shawcable.com","sentAt":"2006-04-19T01:20:34Z","receivedAt":"2006-04-19T01:20:34Z","isPatch":false,"sender":{"key":"rayl@shawcable.com","avatar":null},"body":"\none more lightweight vote in favor.... such a feature would eliminate a few \nshell scripts i cobbled together which essentially allow me to say\n\n git diff 8a6352:path/to/module 5f3461:moved/and/hacked/copy\n\n\nOn Tuesday 18 April 2006 18:21, Shawn Pearce wrote:\n> Not that my voice carries much weight, but a coworker has been\n> asking for this feature to be added to pg for months. I've just\n> been too lazy to get around to writing the shell code to do it.\n> Making it part of git cat-file seems like a good idea, making it\n> usable by other tools like git diff just rocks. :-)\n>\n> I think its a very worthwhile addition.\n>\n> Martin Langhoff wrote:\n> > On 4/19/06, Linus Torvalds wrote:\n> > > What do people think? Have you ever wanted to\n> > > access individual files in some random revision? Do you think this is\n> > > useful?\n> >\n> > Definitely, I've several times had to go through contortions to do\n> > this easily, and I've ended up turning to gitweb often to quickly see\n> > the state of a file at a given revision.\n> >\n> > > With this, you can do something like\n> > >\n> > > git cat-file blob v1.2.4:Makefile\n> > >\n> > > to get the contents of \"Makefile\" at revision v1.2.4.\n> > >\n> > > Now, this isn't necessarily something you really need all that often,\n> > > but the concept itself is actually pretty powerful. We could, for\n> > > example, allow things like\n> > >\n> > > git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh\n> >\n> > These two examples are more than enough -- I buy ;-)\n"},{"id":"18849","messageId":"7vd5fecpyd.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181805080.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-19T01:30:02Z","receivedAt":"2006-04-19T01:30:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Now, the thing that an internal \"git diff\" could do better is to notice \n> when it gets _one_ blob revision, and one filename, ie we could do\n>\n> \tgit diff v0.99.6:git-commit-script git-commit.sh\n>\n> which parses as one SHA1 of a blob (put onto the rev.pending_objects \n> list), and one filename (in the rev.prune_data array). We could decide to \n> automatically do the \"right thing\" for that case too.\n\nThe \"right thing\" is ambiguous, I am afraid.\n\nI think it would be natural to interpret the request as a diff\nbetween the blob from v0.99.6 and a random working tree file, \nwhich may not even exist in the index.\n\nHowever I suspect what you are getting at is to act as if the\nuser said:\n\n\tgit diff v0.99.6:git-commit-script HEAD:git-commit.sh\n\nOh, another possibility is to act as if the user said\n\n\tgit diff v0.99.6:this :git-commit.sh\n\nwhere \"(empty):\" would stand for \"look up in the index, not in a\ntree\".\n\nI think these are all valid interpretations and there are useful\nuse cases (admittably the last one is \"diff-cache --cached\").\n\nUnfortunatly, I do not think this parses well:\n\n\tgit diff git-commit.sh v0.99.6:git-commit-script\n\nbut you could always say:\n\n\tgit diff -R v0.99.6:git-commit-script git-commit.sh\n"},{"id":"18850","messageId":"Pine.LNX.4.64.0604181836400.3701@g5.osdl.org","threadId":"3913","inReplyTo":"7vd5fecpyd.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T01:43:00Z","receivedAt":"2006-04-19T01:43:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Junio C Hamano wrote:\n\n> > \tgit diff v0.99.6:git-commit-script git-commit.sh\n> >\n> > which parses as one SHA1 of a blob (put onto the rev.pending_objects \n> > list), and one filename (in the rev.prune_data array). We could decide to \n> > automatically do the \"right thing\" for that case too.\n> \n> The \"right thing\" is ambiguous, I am afraid.\n> \n> I think it would be natural to interpret the request as a diff\n> between the blob from v0.99.6 and a random working tree file, \n> which may not even exist in the index.\n\nActually, it's not ambiguous. Just take the named file. If you want to \ndiff it against HEAD:, you should just say so.\n\nNow, if you _really_ want to be difficult, there's a third option: to diff \nit against the named file as named in the index. \"git diff\" does have the \n\"--cached\" option that would make that case unambiguous too, of course.\n\nIe:\n\n (a) diff against the current HEAD:\n\n\tgit diff v0.99.6:git-commit-script HEAD:git-commit.sh\n\n (b) diff against the current index contents for \"git-commit.sh\":\n\n\tgit diff --cached v0.99.6:git-commit-script git-commit.sh\n\n (c) diff against a random file (which may not even be in the index):\n\n\tgit diff v0.99.6:git-commit-script git-commit.sh\n\nare all sensible operations, and unambiguous.\n\nThe only real downside is that the nice \"a..b\" syntax doesn't work for \nthem, except fot the very first case. That syntax requires both sides to \nbe SHA1 names (and while the \"index\" case could be a SHA1 name, we have no \nway to say so).\n\n> Oh, another possibility is to act as if the user said\n> \n> \tgit diff v0.99.6:this :git-commit.sh\n> \n> where \"(empty):\" would stand for \"look up in the index, not in a\n> tree\".\n\nThat would possibly be a nice extension, yes. But I really did mean \n\"random file, possibly not even in the index\".\n\n> Unfortunatly, I do not think this parses well:\n> \n> \tgit diff git-commit.sh v0.99.6:git-commit-script\n\nCorrect. As you point out, that would have to be done with -R.\n\n\t\t\tLinus\n"},{"id":"18852","messageId":"46a038f90604182051n4a16ee9atd2577d658befc335@mail.gmail.com","threadId":"3913","inReplyTo":"7vd5fecpyd.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-04-19T03:51:47Z","receivedAt":"2006-04-19T03:51:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"\n What about support for diffing a subtree?\n\n git diff v2.2:net/appletalk v2.9:net/appletalk-ng\n\n\n\ncheers,\n\n\nmartin\n"},{"id":"18853","messageId":"Pine.LNX.4.64.0604182056390.3701@g5.osdl.org","threadId":"3913","inReplyTo":"46a038f90604182051n4a16ee9atd2577d658befc335@mail.gmail.com","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T03:58:18Z","receivedAt":"2006-04-19T03:58:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Apr 2006, Martin Langhoff wrote:\n>\n> \n> What about support for diffing a subtree?\n> \n> git diff v2.2:net/appletalk v2.9:net/appletalk-ng\n> \n> \n\nDid you try it? It works as-is with that patch. Exactly because it will \ncall git-diff-tree with the two SHA1's, and since they are now trees (and \nnot blobs) git-diff-tree will do the right thing.\n\nAnd no, I didn't actually test it. But it really _should_ work with that \ntrivial diff, including with the \"a..b\" format.\n\n\t\tLinus\n"},{"id":"18854","messageId":"7v8xq2ciws.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181836400.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-19T04:02:11Z","receivedAt":"2006-04-19T04:02:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Actually, it's not ambiguous. Just take the named file. If you want to \n> diff it against HEAD:, you should just say so.\n>\n> Now, if you _really_ want to be difficult, there's a third option: to diff \n> it against the named file as named in the index. \"git diff\" does have the \n> \"--cached\" option that would make that case unambiguous too, of course.\n>\n> Ie:\n>\n> (a) diff against the current HEAD:\n>\n> \tgit diff v0.99.6:git-commit-script HEAD:git-commit.sh\n>\n> (b) diff against the current index contents for \"git-commit.sh\":\n>\n> \tgit diff --cached v0.99.6:git-commit-script git-commit.sh\n>\n> (c) diff against a random file (which may not even be in the index):\n>\n> \tgit diff v0.99.6:git-commit-script git-commit.sh\n>\n> are all sensible operations, and unambiguous.\n\nA small fry in the ointment. What should the parts that are\noutput with --name-only say for such a diff?\n\nBlob references like v0.99.6:git-commit-script are resolved by\nthe extended SHA1 interpreter, and all what the caller of\nsetup_revisions() can see and feed the diff machinery with has\nare their object names. Something like this is a possibility,\nbut is ugly.\n\n diff --git a/a2455b0... b/01c73bd...\n index a2455b0..01c73bd 100644\n --- a/a2455b0...\n +++ b/01c73bd...\n @@ -1,118 +1,509 @@\n #!/bin/sh\n #\n # Copyright (c) 2005 Linus Torvalds\n +# Copyright (c) 2006 Junio C Hamano\n +\n +USAGE='[-a] [-s] [-v] [--no-verify] [-m ...\n +SUBDIRECTORY_OK=Yes\n ...\n"},{"id":"18855","messageId":"Pine.LNX.4.64.0604182101360.3701@g5.osdl.org","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604182056390.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T04:04:04Z","receivedAt":"2006-04-19T04:04:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Linus Torvalds wrote:\n> \n> And no, I didn't actually test it. But it really _should_ work with that \n> trivial diff, including with the \"a..b\" format.\n\nOk, tested and verified.\n\nOn the kernel:\n\n\tgit diff v2.6.13:drivers/block/..HEAD:block/ -- ll_rw_blk.c\n\nactually does the right thing - it shows the diff for ll_rw_blk.c which \ngot moved from drivers/block/ into block/ between 2.6.13 and current.\n\nNote that the \"--\" is required, since ll_rw_blk.c doesn't exist in the \ntop-level directory where we run the command (but does exist in the git \ntrees that we have specified manually with the new shorthand).\n\n\t\tLinus\n"},{"id":"18856","messageId":"Pine.LNX.4.64.0604182108070.3701@g5.osdl.org","threadId":"3913","inReplyTo":"7v8xq2ciws.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T04:14:01Z","receivedAt":"2006-04-19T04:14:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Apr 2006, Junio C Hamano wrote:\n> \n> A small fry in the ointment. What should the parts that are\n> output with --name-only say for such a diff?\n\nI have no idea, I have to say ;)\n\n> Blob references like v0.99.6:git-commit-script are resolved by\n> the extended SHA1 interpreter, and all what the caller of\n> setup_revisions() can see and feed the diff machinery with has\n> are their object names.\n\nActually, the names are there. The object list has the \"->name\" field \n(used to do the name-based sorting), and we actually even fill it in for \nthe stuff we pass in as arguments. See the \"add_pending_object()\" calls \nin setup_revisions().\n\nWe just don't use them right now. We _could_.\n\n> Something like this is a possibility, but is ugly.\n> \n> diff --git a/a2455b0... b/01c73bd...\n> index a2455b0..01c73bd 100644\n> --- a/a2455b0...\n> +++ b/01c73bd...\n\nYes. But if you look at the object list name (in the \"pending_object\" \nthing), you _could_ actually get this to be something like\n\n\tdiff --git v0.99.6:git-commit-script git-commit.sh\n\tindex a2455b0..01c73bd 100644\n\t--- v0.99.6:git-commit-script\n\t+++ git-commit.sh\n\nwhich would be much prettier, although I'm not saying it's necessarily \nworth it. I'm just saying that it's _possible_ with the cmd line parsing \ninfrastructure we have now.\n\n\t\tLinus\n"},{"id":"18862","messageId":"4445F1B0.4060105@op5.se","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181745410.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-19T08:15:44Z","receivedAt":"2006-04-19T08:15:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> On Tue, 18 Apr 2006, Linus Torvalds wrote:\n> \n>>And I thought we already disallowed ':' in branch names because cogito \n>>uses them for the strange : syntax.. \n> \n> \n> Btw, pathnames with ':' in them aren't a problem. It's only revision\n> names that can't have ':' in them and still be used together with this \n> syntax.\n> \n> If you have a pathname with ':', it's fine to do\n> \n> \tgit cat-file v1.2.4:pathname:with:colon\n> \n> because the magic revision parsing only cares about the _first_ colon, and \n> will split that into \"v1.2.4\" and \"pathname:with:colon\" without ever even \n> looking at the other ones.\n> \n\nExcept that you'll have to explicitly state HEAD:pathname:with:colon, or \ndoes it try finding a file with the argument verbatim first?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"18876","messageId":"Pine.LNX.4.64.0604190742240.3701@g5.osdl.org","threadId":"3913","inReplyTo":"4445F1B0.4060105@op5.se","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T14:44:56Z","receivedAt":"2006-04-19T14:44:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Apr 2006, Andreas Ericsson wrote:\n> \n> Except that you'll have to explicitly state HEAD:pathname:with:colon, or does\n> it try finding a file with the argument verbatim first?\n\nIf you have a pathname:with:colon and you _just_ want to use it as a \npathname, you'd do one of either:\n\n - use \"--\" to separate the pathnames from the revision info. That always \n works.\n - even without the \"--\", if the first part of the pathname:with:colon (ie \n the \"pathname\" part) cannot be looked up as a SHA1 tag, then the\n pathname:with:colon is left alone and seen as a normal file.\n\nSo \"--\" is always the dis-ambiguator. But it almost certainly will never \nbe needed.\n\n\t\tLinus\n"},{"id":"18892","messageId":"7v3bg96xsv.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604182108070.3701@g5.osdl.org","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-19T21:49:20Z","receivedAt":"2006-04-19T21:49:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 18 Apr 2006, Junio C Hamano wrote:\n>> \n>> A small fry in the ointment. What should the parts that are\n>> output with --name-only say for such a diff?\n>\n> I have no idea, I have to say ;)\n\nAnother small one ;-). Bare blobs do not have modes, so diffcore\nneeds to be told \"do not bother comparing mode for this pair\".\n"},{"id":"18894","messageId":"Pine.LNX.4.64.0604191453030.3701@g5.osdl.org","threadId":"3913","inReplyTo":"7v3bg96xsv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1() shorthands for blob/tree objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T21:57:54Z","receivedAt":"2006-04-19T21:57:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Apr 2006, Junio C Hamano wrote:\n>\n> Linus Torvalds writes:\n> \n> > On Tue, 18 Apr 2006, Junio C Hamano wrote:\n> >> \n> >> A small fry in the ointment. What should the parts that are\n> >> output with --name-only say for such a diff?\n> >\n> > I have no idea, I have to say ;)\n> \n> Another small one ;-). Bare blobs do not have modes, so diffcore\n> needs to be told \"do not bother comparing mode for this pair\".\n\nTrue, but sad.\n\nWe clearly _do_ have the mode when we look it up using the tree:name \nshorthand, so it's a bit sad that we drop it on the floor like that.\n\nWe could do something like with the \"name\" part - squirrel the mode away \nfor users that could use it, and use the special mode of 0 as \"unknown\" \nfor when somebody really does give a pure SHA1 number (short or full).\n\nBut I suspect most people simply don't care, so dropping the mode might \njust be the right thing to do. Especially if we do know that we _could_ \nget the mode if people really really care and complain some day in the \nfuture..\n\n(The logic being: 640kB really _is_ enough for everybody, if you just know \nthat you can extend on it in the future without undue pain when people \ncomplain)\n\n\t\t\tLinus\n"},{"id":"18982","messageId":"7v7j5iph7f.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"Pine.LNX.4.64.0604181627101.3701@g5.osdl.org","subject":"[RFC] get_sha1(): :path and :[0-3]:path to extract from index.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-22T00:49:40Z","receivedAt":"2006-04-22T00:49:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[ NOTE! The reason I put \"RFC\" in the subject rather than \"PATCH\" is that \n I'm not 100% sure this isn't just a \"shiny object\" of mine rather than a \n really useful thing to do. What do people think? Have you ever wanted to \n access individual files in some random revision? Do you think this is \n useful? I think it's cool and _may_ be useful, but I'm not going to \n really push this patch. Consider it a throw-away patch unless somebody \n else finds it intriguing enough.. ]\n\nThis is a fairly straightforward patch to allow \"get_sha1()\" to\nalso have shorthands for blob objects in the current index.\n\nThe syntax is very simple and intuitive: you can specify a blob\nfrom the current index by simply specifying :: or\n:, and get_sha1() will do the SHA1 lookup from the index\nfor you.\n\nYou can currently do it with \"git ls-files -s \" and parsing the \noutput, but that's actually pretty awkward.\n\nWith this, you can do something like\n\n\tgit cat-file blob :3:Makefile\n\nto get the contents of \"Makefile\" from their version during a\nconflicted merge.\n\nThis does not do trees like : version does. We could\ndo that by writing out a temporary tree object if we wanted to,\nbut that would smudge the object database, so I refrained from\ndoing that as part of this patch. If we did that,\n\n\tgit diff-tree :2: :3:\n\nwould be an inefficient equivalent to \"git diff-stages 2 3\".\n\n---\n sha1_name.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++--------\n 1 files changed, 46 insertions(+), 8 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 345935b..ec5cd2c 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -458,17 +458,55 @@ int get_sha1(const char *name, unsigned \n {\n \tint ret;\n \tunsigned unused;\n+\tint namelen = strlen(name);\n+\tconst char *cp;\n \n \tprepare_alt_odb();\n-\tret = get_sha1_1(name, strlen(name), sha1);\n-\tif (ret < 0) {\n-\t\tconst char *cp = strchr(name, ':');\n-\t\tif (cp) {\n-\t\t\tunsigned char tree_sha1[20];\n-\t\t\tif (!get_sha1_1(name, cp-name, tree_sha1))\n-\t\t\t\treturn get_tree_entry(tree_sha1, cp+1, sha1,\n-\t\t\t\t\t\t &unused);\n+\tret = get_sha1_1(name, namelen, sha1);\n+\tif (!ret)\n+\t\treturn ret;\n+\t/* sha1:path --> object name of path in ent sha1\n+\t * :path -> object name of path in index\n+\t * :[0-3]:path -> object name of path in index at stage\n+\t */\n+\tif (name[0] == ':') {\n+\t\tint stage = 0;\n+\t\tstruct cache_entry *ce;\n+\t\tint pos;\n+\t\tif (namelen < 3 ||\n+\t\t name[2] != ':' ||\n+\t\t name[1] < '0' || '3' < name[1])\n+\t\t\tcp = name + 1;\n+\t\telse {\n+\t\t\tstage = name[1] - '0';\n+\t\t\tcp = name + 3;\n \t\t}\n+\t\tnamelen = namelen - (cp - name);\n+\t\tif (!active_cache)\n+\t\t\tread_cache();\n+\t\tif (active_nr < 0)\n+\t\t\treturn -1;\n+\t\tpos = cache_name_pos(cp, namelen);\n+\t\tif (pos < 0)\n+\t\t\tpos = -pos - 1;\n+\t\twhile (pos < active_nr) {\n+\t\t\tce = active_cache[pos];\n+\t\t\tif (ce_namelen(ce) != namelen ||\n+\t\t\t memcmp(ce->name, cp, namelen))\n+\t\t\t\tbreak;\n+\t\t\tif (ce_stage(ce) == stage) {\n+\t\t\t\tmemcpy(sha1, ce->sha1, 20);\n+\t\t\t\treturn 0;\n+\t\t\t}\n+\t\t}\n+\t\treturn -1;\n+\t}\n+\tcp = strchr(name, ':');\n+\tif (cp) {\n+\t\tunsigned char tree_sha1[20];\n+\t\tif (!get_sha1_1(name, cp-name, tree_sha1))\n+\t\t\treturn get_tree_entry(tree_sha1, cp+1, sha1,\n+\t\t\t\t\t &unused);\n \t}\n \treturn ret;\n }\n-- \n1.3.0.g6082\n"},{"id":"19085","messageId":"20060425083724.GA1663@informatik.uni-freiburg.de","threadId":"3913","inReplyTo":"7v7j5iph7f.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] get_sha1(): :path and :[0-3]:path to extract from index.","fromName":"Uwe Zeisberger","fromEmail":"zeisberg@informatik.uni-freiburg.de","sentAt":"2006-04-25T08:37:24Z","receivedAt":"2006-04-25T08:37:24Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> [ NOTE! The reason I put \"RFC\" in the subject rather than \"PATCH\" is that \n> I'm not 100% sure this isn't just a \"shiny object\" of mine rather than a \n> really useful thing to do. What do people think? Have you ever wanted to \n> access individual files in some random revision? Do you think this is \n> useful? I think it's cool and _may_ be useful, but I'm not going to \n> really push this patch. Consider it a throw-away patch unless somebody \n> else finds it intriguing enough.. ]\n> \n> This is a fairly straightforward patch to allow \"get_sha1()\" to\n> also have shorthands for blob objects in the current index.\nI sometimes want to have something like that:\n\n\tuzeisberger@io:~/gsrc/linux-2.6$ git cat-file blob v2.6.16:Makefile\n\nThat is not a shortcut for objects in the current index, but for blobs\nin written trees.\n\nIt's easy to hack a script that does that. Something like that[1]:\n\n\n\t#! /bin/sh\n\n\teval `echo ${1} | sed 's/\\\\(.*\\\\):\\\\(.*\\\\)/commit=\\\"\\\\1^{}\\\"; file=\\\"\\\\2\\\"/'`\n\n\ttree=`git cat-file commit ${commit} | sed -n 's/tree //p'`\n\n\tblob=`git ls-tree -r ${tree} | awk \"\\\\\\$4 == \\\\\"${file}\\\\\" { print \\\\\\$3 }\"`\n\n\tgit cat-file blob ${blob}\n\n\nBut if the rev-parser could handle that, that would be much finer. Or\nis there already a way to do this that I don't know?\n\nBest regards\nUwe\n\n[1] It's not tested and probably fails if there are some \"bad\"\ncharacters in ${1} and could be implemented in a much cleverer way.\n\n-- \nUwe Zeisberger\n\nhttp://www.google.com/search?q=0+degree+Celsius+in+kelvin\n"},{"id":"19088","messageId":"7vr73myrdu.fsf@assigned-by-dhcp.cox.net","threadId":"3913","inReplyTo":"20060425083724.GA1663@informatik.uni-freiburg.de","subject":"Re: [RFC] get_sha1(): :path and :[0-3]:path to extract from index.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-25T08:46:21Z","receivedAt":"2006-04-25T08:46:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Uwe Zeisberger writes:\n\n>> This is a fairly straightforward patch to allow \"get_sha1()\" to\n>> also have shorthands for blob objects in the current index.\n>\n> I sometimes want to have something like that:\n>\n> \tuzeisberger@io:~/gsrc/linux-2.6$ git cat-file blob v2.6.16:Makefile\n>\n> That is not a shortcut for objects in the current index, but for blobs\n> in written trees.\n\nThat's already present in the \"master\". You are responding to a\nwrong message ;-).\n"}]}