{"thread":{"id":"4893","subject":"Strange output of 'git diff <revision1>:<file> <revision2>:<file>'","startedAt":"2006-07-15T10:20:15Z","lastAt":"2006-07-16T08:50:00Z","messageCount":4,"participants":["Jakub Narebski","Matthias Lederhofer","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23858","messageId":"e9aff7$nk1$1@sea.gmane.org","threadId":"4893","inReplyTo":null,"subject":"Strange output of 'git diff <revision1>:<file> <revision2>:<file>'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-07-15T10:20:15Z","receivedAt":"2006-07-15T10:20:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"git diff output for files specified by revision is somewhat unexpected. \n\n  $ git diff <revision_1>:<file> <revision_2>:<file>\n\noutputs the following diff metainfo\n\n  diff --git a/<revision_2>:<file> b/<revision_2>:<file>\n  index 5eabe06..2e87de4 100644\n  --- a/<revision_2>:<file>\n  +++ b/<revision_2>:<file>\n\nIs it intended, or is it a bug? Looks like a bug to me...\n\ngit 1.4.0 (git-core-1.4.0-1.fc4 by Fedora Project).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"23859","messageId":"E1G1jgg-0007ds-DP@moooo.ath.cx","threadId":"4893","inReplyTo":"e9aff7$nk1$1@sea.gmane.org","subject":"[PATCH] use the path as name from the revision:path syntax in setup_revisions","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2006-07-15T12:56:02Z","receivedAt":"2006-07-15T12:56:02Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"---\nJakub Narebski <jnareb@gmail.com> wrote:\n> git diff output for files specified by revision is somewhat unexpected. \n> \n>   $ git diff <revision_1>:<file> <revision_2>:<file>\n> \n> outputs the following diff metainfo\n> \n>   diff --git a/<revision_2>:<file> b/<revision_2>:<file>\n>   index 5eabe06..2e87de4 100644\n>   --- a/<revision_2>:<file>\n>   +++ b/<revision_2>:<file>\n> \n> Is it intended, or is it a bug? Looks like a bug to me...\nI guess the revision should not be there.  Here is a patch to remove\nit.\n<matled> is there a name for 'revision:path' to specify a file at a\n         certain revision?\n<jdl> \"That weird syntax, you know.\"\n<matled> get_path_out_of_the_weird_syntax(const char *s)\n<matled> you know :)\n<jdl> That should do it!\nCould someone please come up with a nice name for the function?\nWithout knowing a name for the '<revision>:<path>' syntax I can only\nthink of get_path or similar names and this is much too generic imo.\n---\n cache.h     |    1 +\n revision.c  |    2 ++\n sha1_name.c |   12 ++++++++++++\n 3 files changed, 15 insertions(+), 0 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex d433d46..7da1c5c 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -249,6 +249,7 @@ #define DEFAULT_ABBREV 7\n \n extern int get_sha1(const char *str, unsigned char *sha1);\n extern int get_sha1_hex(const char *hex, unsigned char *sha1);\n+extern char *get_path_out_of_the_weird_syntax(const char *str);\n extern char *sha1_to_hex(const unsigned char *sha1);\t/* static buffer result! */\n extern int read_ref(const char *filename, unsigned char *sha1);\n extern const char *resolve_ref(const char *path, unsigned char *sha1, int);\ndiff --git a/revision.c b/revision.c\nindex 874e349..fbd1458 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -908,6 +908,8 @@ int setup_revisions(int argc, const char\n \t\tif (!seen_dashdash)\n \t\t\tverify_non_filename(revs->prefix, arg);\n \t\tobject = get_reference(revs, arg, sha1, flags ^ local_flags);\n+\t\tif (object->type == OBJ_BLOB || object->type == OBJ_TREE)\n+\t\t\targ = get_path_out_of_the_weird_syntax(arg);\n \t\tadd_pending_object(revs, object, arg);\n \t}\n \tif (show_merge)\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 5fe8e5d..718ce1b 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -543,3 +543,15 @@ int get_sha1(const char *name, unsigned \n \t}\n \treturn ret;\n }\n+\n+/* get the path from sha1:path, :path and :[0-3]:path */\n+char *get_path_out_of_the_weird_syntax(const char *str)\n+{\n+\tif (strlen(str) >= 3 &&\n+\t\tstr[0] == ':' && str[2] == ':' &&\n+\t\tstr[1] >= '0' && str[2] <= '3')\n+\t\treturn((char*)(str+3));\n+\tif (index(str, ':'))\n+\t\treturn index(str, ':')+1;\n+\treturn str;\n+}\n-- \n1.4.1.ga3e6\n"},{"id":"23860","messageId":"E1G1jje-0007ey-OA@moooo.ath.cx","threadId":"4893","inReplyTo":"e9aff7$nk1$1@sea.gmane.org","subject":"[PATCH] array index mixup","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2006-07-15T12:59:06Z","receivedAt":"2006-07-15T12:59:06Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"---\nJakub Narebski <jnareb@gmail.com> wrote:\n> git diff output for files specified by revision is somewhat unexpected. \n> \n>   $ git diff <revision_1>:<file> <revision_2>:<file>\n> \n> outputs the following diff metainfo\n> \n>   diff --git a/<revision_2>:<file> b/<revision_2>:<file>\n>   index 5eabe06..2e87de4 100644\n>   --- a/<revision_2>:<file>\n>   +++ b/<revision_2>:<file>\n> \n> Is it intended, or is it a bug? Looks like a bug to me...\nI dunno if this is really an index mixup or was intended.  If this is\nintended please add a comment what it's for.  (Without this you get\nrename information, perhaps this is the reason.)\n---\n builtin-diff.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-diff.c b/builtin-diff.c\nindex cb38f44..4d43a5c 100644\n--- a/builtin-diff.c\n+++ b/builtin-diff.c\n@@ -136,7 +136,7 @@ static int builtin_diff_blobs(struct rev\n \tstuff_change(&revs->diffopt,\n \t\t     mode, mode,\n \t\t     blob[1].sha1, blob[0].sha1,\n-\t\t     blob[0].name, blob[0].name);\n+\t\t     blob[1].name, blob[0].name);\n \tdiffcore_std(&revs->diffopt);\n \tdiff_flush(&revs->diffopt);\n \treturn 0;\n-- \n1.4.1.ga3e6\n"},{"id":"23874","messageId":"7vejwmj5mv.fsf@assigned-by-dhcp.cox.net","threadId":"4893","inReplyTo":"E1G1jje-0007ey-OA@moooo.ath.cx","subject":"Re: [PATCH] array index mixup","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-16T08:50:00Z","receivedAt":"2006-07-16T08:50:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> I dunno if this is really an index mixup or was intended.  If this is\n> intended please add a comment what it's for.  (Without this you get\n> rename information, perhaps this is the reason.)\n\nThat is exactly the reason -- it was a temporary workaround\nwhich nobody noticed so far.\n\nThe right fix would involve updating diff_resolve_rename_copy so\nthat it does not rely on the comparison of path names (that\nmeans DIFF_PAIR_RENAME() macro needs to change), and instead\nmark the pairs synthesized in diffcore-rename as such, and use\nthat to tell if a pair is a result of rename/copy [*1*].\n\nYour other patch (not the one to change the index of the array\nused for labels, but the one that extracts the pathname out of\nthe syntax to name a blob by path in an arbitrary tree object)\ncould be safely applied when that happens.\n\n\n[Footnote]\n\n*1* If somebody wants to do this, one thing to watch out for is\nmatching up of broken pairs.  If a pair originally broken by\ndiffcore-break (because they were dissimilar enough according to\nthe option given to -B flag) are merged into one by\ndiffcore-rename (because they were similar enough according to\nthe option given to -M flag), we should _not_ say the resulting\npair is renamed.  In general, the threashold for breaking should\nbe lower than diffcore-rename to merge them for a sane use, so\nthis might be a non-issue in practice, though.\n"}]}