{"thread":{"id":"8869","subject":"[BUG (or misfeature?)] git checkout and symlinks","startedAt":"2007-07-04T20:35:41Z","lastAt":"2007-07-12T19:01:24Z","messageCount":11,"participants":["Pierre Habouzit","Junio C Hamano","Johannes Schindelin","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46510","messageId":"20070704203541.GA13286@artemis.corp","threadId":"8869","inReplyTo":null,"subject":"[BUG (or misfeature?)] git checkout and symlinks","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-07-04T20:35:41Z","receivedAt":"2007-07-04T20:35:41Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":" if in a branch [branch1] you track the file: dir1/file1.c\nand in the branch [branch2] you track elsewhere/file1.c and dir1 be\nsymlink on elsewhere, then it's not possible to checkout the branch\n[branch1] if your previous checkout was [branch2]. You have to manually\nremove the symlink `dir1` else git complains that checkouting branch1\nwould overwrite dir1/file1.c.\n\n I'm not sure how to fix this, and it's quite painful actually :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"46512","messageId":"7vabubhoxb.fsf@assigned-by-dhcp.cox.net","threadId":"8869","inReplyTo":"20070704203541.GA13286@artemis.corp","subject":"Re: [BUG (or misfeature?)] git checkout and symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-04T20:52:32Z","receivedAt":"2007-07-04T20:52:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> if in a branch [branch1] you track the file: dir1/file1.c\n> and in the branch [branch2] you track elsewhere/file1.c and dir1 be\n> symlink on elsewhere, then it's not possible to checkout the branch\n> [branch1] if your previous checkout was [branch2]. You have to manually\n> remove the symlink `dir1` else git complains that checkouting branch1\n> would overwrite dir1/file1.c.\n>\n> I'm not sure how to fix this, and it's quite painful actually :)\n\nYeah, I think our handling of symlinks in both read-tree and\nmerge-recursive codepath are Ok for symlinks at the leaf level\nbut not for intermediate levels. I think we have some patches\nin the recent git (post 1.5.1) to fix (perhaps some of) the\nissues, though.\n"},{"id":"46513","messageId":"20070704210559.GB13286@artemis.corp","threadId":"8869","inReplyTo":"7vabubhoxb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG (or misfeature?)] git checkout and symlinks","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-07-04T21:05:59Z","receivedAt":"2007-07-04T21:05:59Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jul 04, 2007 at 01:52:32PM -0700, Junio C Hamano wrote:\n> Pierre Habouzit writes:\n> \n> > if in a branch [branch1] you track the file: dir1/file1.c\n> > and in the branch [branch2] you track elsewhere/file1.c and dir1 be\n> > symlink on elsewhere, then it's not possible to checkout the branch\n> > [branch1] if your previous checkout was [branch2]. You have to manually\n> > remove the symlink `dir1` else git complains that checkouting branch1\n> > would overwrite dir1/file1.c.\n> >\n> > I'm not sure how to fix this, and it's quite painful actually :)\n> \n> Yeah, I think our handling of symlinks in both read-tree and\n> merge-recursive codepath are Ok for symlinks at the leaf level\n> but not for intermediate levels. I think we have some patches\n> in the recent git (post 1.5.1) to fix (perhaps some of) the\n> issues, though.\n\n that was with the git in debian unstable, 1.5.2.3 actually. I'll try\nagain with HEAD to see if that's fixed.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"46519","messageId":"20070704222351.GC13286@artemis.corp","threadId":"8869","inReplyTo":"20070704210559.GB13286@artemis.corp","subject":"Re: $ git checkout and symlinks","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-07-04T22:23:51Z","receivedAt":"2007-07-04T22:23:51Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Jul 04, 2007 at 11:05:59PM +0200, Pierre Habouzit wrote:\n> On Wed, Jul 04, 2007 at 01:52:32PM -0700, Junio C Hamano wrote:\n> > Pierre Habouzit writes:\n> > \n> > > if in a branch $ you track the file: dir1/file1.c\n> > > and in the branch $ you track elsewhere/file1.c and dir1 be\n> > > symlink on elsewhere, then it's not possible to checkout the branch\n> > > $. You have to manually\n> > > remove the symlink `dir1` else git complains that checkouting branch1\n> > > would overwrite dir1/file1.c.\n> > >\n> > > I'm not sure how to fix this, and it's quite painful actually :)\n> > \n> > Yeah, I think our handling of symlinks in both read-tree and\n> > merge-recursive codepath are Ok for symlinks at the leaf level\n> > but not for intermediate levels. I think we have some patches\n> > in the recent git (post 1.5.1) to fix (perhaps some of) the\n> > issues, though.\n> \n> that was with the git in debian unstable, 1.5.2.3 actually. I'll try\n> again with HEAD to see if that's fixed.\n\n HEADS does not fixes it either.\n Here is how to reproduce the problem step by step:\n\n$ git init-db \t\t\t\t# init a repo\n\n$ mkdir dir\n$ echo wibble > dir/a\n$ git add a\n$ git commit -a -m'add a' \t\t# have dir/a live in master\n\n$ git checkout -b break\n$ git mv dir new \t\t\t# rename dir into new\n$ ln -s new dir \t\t\t# symlink dir to new\n$ git add dir \t\t\t\t# add the symlink\n$ git commit -a -m 'break things' \t# commit\n\n$ git checkout master\nfatal: Untracked working tree file 'dir/a' would be overwritten by merge.\n\n\n The same is true for current git.git HEAD, or git 1.5.2.x\n\nCheers,\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"47129","messageId":"7vzm22vyin.fsf@assigned-by-dhcp.cox.net","threadId":"8869","inReplyTo":"20070704203541.GA13286@artemis.corp","subject":"Teach read-tree 2-way merge to ignore intermediate symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-12T08:04:16Z","receivedAt":"2007-07-12T08:04:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Earlier in 16a4c61, we taught \"read-tree -m -u\" not to be\nconfused when switching from a branch that has a path frotz/filfre\nto another branch that has a symlink frotz that points at xyzzy/\ndirectory. The fix was incomplete in that it was still confused\nwhen coming back (i.e. switching from a branch with frotz -> xyzzy/\nto another branch with frotz/filfre).\n\nThis fix is rather expensive in that for a path that is created\nwe would need to see if any of the leading component of that\npath exists as a symbolic link in the filesystem (in which case,\nwe know that path itself does not exist, and the fact we already\ndecided to check it out tells us that in the index we already\nknow that symbolic link is going away as there is no D/F\nconflict).\n\nSigned-off-by: Junio C Hamano \n---\n\n Re: [BUG (or misfeature?)] git checkout and symlinks\n\n Pierre Habouzit writes:\n\n > if in a branch [branch1] you track the file: dir1/file1.c\n > and in the branch [branch2] you track elsewhere/file1.c and dir1 be\n > symlink on elsewhere, then it's not possible to checkout the branch\n > [branch1] if your previous checkout was [branch2]. You have to manually\n > remove the symlink `dir1` else git complains that checkouting branch1\n > would overwrite dir1/file1.c.\n >\n > I'm not sure how to fix this, and it's quite painful actually :)\n\n We probably could add a path buffer to cache the last look-up\n made by has_symlink_leading_path(), like the other caller\n does, but this is to give the fix a wider exposure and testing\n early.\n\n t/t2007-checkout-symlink.sh | 50 +++++++++++++++++++++++++++++++++++++++++++\n unpack-trees.c | 3 ++\n 2 files changed, 53 insertions(+), 0 deletions(-)\n create mode 100755 t/t2007-checkout-symlink.sh\n\ndiff --git a/t/t2007-checkout-symlink.sh b/t/t2007-checkout-symlink.sh\nnew file mode 100755\nindex 0000000..0526fce\n--- /dev/null\n+++ b/t/t2007-checkout-symlink.sh\n@@ -0,0 +1,50 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2007 Junio C Hamano\n+\n+test_description='git checkout to switch between branches with symlink<->dir'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\n+\tmkdir frotz &&\n+\techo hello >frotz/filfre &&\n+\tgit add frotz/filfre &&\n+\ttest_tick &&\n+\tgit commit -m \"master has file frotz/filfre\" &&\n+\n+\tgit branch side &&\n+\n+\techo goodbye >nitfol &&\n+\tgit add nitfol\n+\ttest_tick &&\n+\tgit commit -m \"master adds file nitfol\" &&\n+\n+\tgit checkout side &&\n+\n+\tgit rm --cached frotz/filfre &&\n+\tmv frotz xyzzy &&\n+\tln -s xyzzy frotz &&\n+\tgit add xyzzy/filfre frotz &&\n+\ttest_tick &&\n+\tgit commit -m \"side moves frotz/ to xyzzy/ and adds frotz->xyzzy/\"\n+\n+'\n+\n+test_expect_success 'switch from symlink to dir' '\n+\n+\tgit checkout master\n+\n+'\n+\n+rm -fr frotz xyzzy nitfol &&\n+git checkout -f master || exit\n+\n+test_expect_success 'switch from dir to symlink' '\n+\n+\tgit checkout side\n+\n+'\n+\n+test_done\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex cac2411..89dd279 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -495,6 +495,9 @@ static void verify_absent(const char *path, const char *action,\n \tif (o->index_only || o->reset || !o->update)\n \t\treturn;\n \n+\tif (has_symlink_leading_path(path, NULL))\n+\t\treturn;\n+\n \tif (!lstat(path, &st)) {\n \t\tint cnt;\n \n"},{"id":"47130","messageId":"7vsl7uvx8v.fsf_-_@assigned-by-dhcp.cox.net","threadId":"8869","inReplyTo":"7vzm22vyin.fsf@assigned-by-dhcp.cox.net","subject":"git-log --follow?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-12T08:31:44Z","receivedAt":"2007-07-12T08:31:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The message I am following up is a patch to unpack-trees.c,\nwhose basic code structure is Daniel's work, so I wanted to CC\nhim and the easiest way to look his address up was to run\ngit-log on it.\n\nNot so.\n\nThe \"blame -C unpack-trees.c\" output consists of this\ndistribution of origin:\n\n 464 read-tree.c\n 337 unpack-trees.c\n 74 builtin-read-tree.c\n 11 tree.c\n 8 tree.h\n\nand most of the work by Daniel was done when the bulk of code\nwas still in read-tree.c. Naturally the log output of\nunpack-trees.c does not have a single commit by him. \"git log\n-- unpack-trees.c\" would not follow into read-tree.c, but I\nthought \"git log --follow -- unpack-trees.c\" is supposed to; I\ntried it for the first time, but it does not seem to work as\nwell as I hoped.\n\nI think this is just a testament that \"following renames\" is not\nas useful in a real project as people seem to believe, not a\nreal complaint.\n\nWhen 16da134 created unpack-trees.c, it initially moved only\nvery small part of builtin-read-tree.c to it. Later 076b0adc\nmade further code movements from builtin-read-tree.c to\nunpack-trees.c.\n\nAn interesting thing is that builtin-read-tree.c immediately\nbefore 16da134 is much similar to unpack-trees.c in 076b0adc\nthan unpack-trees.c in 16da134, exactly because of this stepwise\ncode movements. I do not think people can argue that \"human\nuser knows he is renaming the file so recording the human\nintention would have helped git a lot better\" in this case, as\nthe human user who made 16da134 did not even intend to do a\nrename.\n"},{"id":"47138","messageId":"Pine.LNX.4.64.0707121142110.4516@racer.site","threadId":"8869","inReplyTo":"7vsl7uvx8v.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: git-log --follow?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-12T10:44:39Z","receivedAt":"2007-07-12T10:44:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Jul 2007, Junio C Hamano wrote:\n\n> The message I am following up is a patch to unpack-trees.c, whose basic \n> code structure is Daniel's work, so I wanted to CC him and the easiest \n> way to look his address up was to run git-log on it.\n> \n> Not so.\n>\n> [...]\n> \n> \"git log -- unpack-trees.c\" would not follow into read-tree.c, but I \n> thought \"git log --follow -- unpack-trees.c\" is supposed to; I tried it \n> for the first time, but it does not seem to work as well as I hoped.\n\nYour lesson as to why following renames is not as useful as some might \nwant to make us believe is duly noted; will use it as back reference \nshould I have to defend that view again.\n\nHowever, I have to wonder why you did not solve your problem this way:\n\n\tgit log --author=Daniel\n\nCiao,\nDscho\n"},{"id":"47143","messageId":"20070712124045.GA4509@artemis.corp","threadId":"8869","inReplyTo":"7vzm22vyin.fsf@assigned-by-dhcp.cox.net","subject":"Re: Teach read-tree 2-way merge to ignore intermediate symlinks","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-07-12T12:40:45Z","receivedAt":"2007-07-12T12:40:45Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Jul 12, 2007 at 01:04:16AM -0700, Junio C Hamano wrote:\n> Earlier in 16a4c61, we taught \"read-tree -m -u\" not to be\n> confused when switching from a branch that has a path frotz/filfre\n> to another branch that has a symlink frotz that points at xyzzy/\n> directory. The fix was incomplete in that it was still confused\n> when coming back (i.e. switching from a branch with frotz -> xyzzy/\n> to another branch with frotz/filfre).\n> \n> This fix is rather expensive in that for a path that is created\n> we would need to see if any of the leading component of that\n> path exists as a symbolic link in the filesystem (in which case,\n> we know that path itself does not exist, and the fact we already\n> decided to check it out tells us that in the index we already\n> know that symbolic link is going away as there is no D/F\n> conflict).\n> \n> Signed-off-by: Junio C Hamano \n\n I confirm this fixes the issue I reported.\n Thanks !\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"47181","messageId":"alpine.LFD.0.999.0707121026080.20061@woody.linux-foundation.org","threadId":"8869","inReplyTo":"7vsl7uvx8v.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: git-log --follow?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-12T17:49:08Z","receivedAt":"2007-07-12T17:49:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Jul 2007, Junio C Hamano wrote:\n> \n> I think this is just a testament that \"following renames\" is not\n> as useful in a real project as people seem to believe, not a\n> real complaint.\n\nYeah. That said, what you wanted would have actually worked with my \noriginal strange patch to \"git blame\", and in particular that also would \nallow you to get a \"log\" for certain lines in the file.\n\nSo something like\n\n\tgit blame -C -Lx,y --log\n\nmay still make sense to give people.\n\nHere's a new version of that patch (I've long since lost the original one, \nplus it probably wouldn't apply anyway, but it was easy to re-generate).\n\nIt doesn't set up the revs thing nicely, so trying to add \"-p\" or \"--stat\" \netc doesn't really get you what you'd want, and \"--decorate\" doesn't work \nsince it doesn't call \"cmd_log_init\".\n\nSo this certainly has some room for improvement, but my point is that \"git \nblame\" actually knows all this, and in many ways does a better job than \n\"git log\" (but a very *different* job!!).\n\nSo \"git log\" gives you the log for a (set of) pathname(s), while with this \npatch, \"git blame --log\" gives you the log for the commits that can be \n*blamed* for the current state of that pathname!\n\nTwo very different things, but both are valid, and interesting things to \ndo, I think. And I really think it's worth doing, if only because it's so \nsimple, and fits so well with the whole \"git blame\" structure!\n\n\t\t\tLinus\n\n---\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex 0519339..8de06d3 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -18,6 +18,7 @@\n #include \"cache-tree.h\"\n #include \"path-list.h\"\n #include \"mailmap.h\"\n+#include \"log-tree.h\"\n \n static char blame_usage[] =\n \"git-blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [-L n,m] [-S ] [-M] [-C] [-C] [--contents ] [--incremental] [commit] [--] file\\n\"\n@@ -34,6 +35,7 @@ static char blame_usage[] =\n \" -L n,m Process only line range n,m, counting from 1\\n\"\n \" -M, -C Find line movements within and across files\\n\"\n \" --incremental Show blame entries as we find them, incrementally\\n\"\n+\" --log Show blame entries as we find them in 'git log' style\\n\"\n \" --contents file Use 's contents as the final image\\n\"\n \" -S revs-file Use revisions from revs-file instead of calling git-rev-list\\n\";\n \n@@ -45,6 +47,7 @@ static int max_score_digits;\n static int show_root;\n static int blank_boundary;\n static int incremental;\n+static int blame_log;\n static int cmd_is_annotate;\n static int xdl_opts = XDF_NEED_MINIMAL;\n static struct path_list mailmap;\n@@ -1431,11 +1434,22 @@ static void write_filename_info(const char *path)\n * The blame_entry is found to be guilty for the range. Mark it\n * as such, and show it in incremental output.\n */\n-static void found_guilty_entry(struct blame_entry *ent)\n+static void found_guilty_entry(struct blame_entry *ent, struct rev_info *rev)\n {\n \tif (ent->guilty)\n \t\treturn;\n \tent->guilty = 1;\n+\tif (blame_log) {\n+\t\tstruct origin *suspect = ent->suspect;\n+\t\tstruct commit *commit = suspect->commit;\n+\n+\t\tif (commit->object.flags & METAINFO_SHOWN)\n+\t\t\treturn;\n+\t\tcommit->object.flags |= METAINFO_SHOWN;\n+\t\tlog_tree_commit(rev, commit);\n+\t\tmaybe_flush_or_die(stdout, \"stdout\");\n+\t\treturn;\n+\t}\n \tif (incremental) {\n \t\tstruct origin *suspect = ent->suspect;\n \n@@ -1505,7 +1519,7 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)\n \t\t/* Take responsibility for the remaining entries */\n \t\tfor (ent = sb->ent; ent; ent = ent->next)\n \t\t\tif (same_suspect(ent->suspect, suspect))\n-\t\t\t\tfound_guilty_entry(ent);\n+\t\t\t\tfound_guilty_entry(ent, revs);\n \t\torigin_decref(suspect);\n \n \t\tif (DEBUG) /* sanity */\n@@ -2204,6 +2218,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \t\t}\n \t\telse if (!strcmp(\"--incremental\", arg))\n \t\t\tincremental = 1;\n+\t\telse if (!strcmp(\"--log\", arg))\n+\t\t\tsave_commit_buffer = incremental = blame_log = 1;\n \t\telse if (!strcmp(\"--score-debug\", arg))\n \t\t\toutput_option |= OUTPUT_SHOW_SCORE;\n \t\telse if (!strcmp(\"-f\", arg) ||\n@@ -2224,7 +2240,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \t\t\targv[unk++] = arg;\n \t}\n \n-\tif (!incremental)\n+\tif (blame_log || !incremental)\n \t\tsetup_pager();\n \n \tif (!blame_move_score)\n@@ -2324,7 +2340,14 @@ int cmd_blame(int argc, const char **argv, const char *prefix)\n \targv[unk] = NULL;\n \n \tinit_revisions(&revs, NULL);\n+\n+\t/* Maybe we should call \"cmd_log_init()\" here instead? */\n+\trevs.always_show_header = 1;\n+\trevs.commit_format = CMIT_FMT_DEFAULT;\n+\trevs.verbose_header = 1;\n+\trevs.abbrev = DEFAULT_ABBREV;\n \tsetup_revisions(unk, argv, &revs, NULL);\n+\n \tmemset(&sb, 0, sizeof(sb));\n \n \t/*\n"},{"id":"47191","messageId":"7vsl7ttq97.fsf@assigned-by-dhcp.cox.net","threadId":"8869","inReplyTo":"alpine.LFD.0.999.0707121026080.20061@woody.linux-foundation.org","subject":"Re: git-log --follow?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-12T18:45:40Z","receivedAt":"2007-07-12T18:45:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 12 Jul 2007, Junio C Hamano wrote:\n>> \n>> I think this is just a testament that \"following renames\" is not\n>> as useful in a real project as people seem to believe, not a\n>> real complaint.\n>\n> Yeah. That said, what you wanted would have actually worked with my \n> original strange patch to \"git blame\", and in particular that also would \n> allow you to get a \"log\" for certain lines in the file.\n\nYeah, I just tried the blame from 'pu' (I have been carrying\nthat original patch from you there). The output is not very\nintuitive in that it talks about each commit but it is not\napparent _why_ the command talks about that commit. Maybe\nadding \"there are the lines in the final image of the blob you\nare blaming that came from this commit\" to the output would make\nthe output easier to read.\n"},{"id":"47193","messageId":"alpine.LFD.0.999.0707121154240.20061@woody.linux-foundation.org","threadId":"8869","inReplyTo":"7vsl7ttq97.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-log --follow?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-12T19:01:24Z","receivedAt":"2007-07-12T19:01:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 12 Jul 2007, Junio C Hamano wrote:\n> \n> Yeah, I just tried the blame from 'pu' (I have been carrying\n> that original patch from you there). The output is not very\n> intuitive in that it talks about each commit but it is not\n> apparent _why_ the command talks about that commit. Maybe\n> adding \"there are the lines in the final image of the blob you\n> are blaming that came from this commit\" to the output would make\n> the output easier to read.\n\nThat doesn't necessarily work, at least not incrementally. The same commit \ncan show up multiple times for *different* 'blame_entry' things, and I \ndon't think we want to show such a commit multiple times, and I also don't \nthink we know what all the blame entries are going to be until the end.\n\nSo right now I use that METAINFO_SHOWN flag to just show the commit once. \nThat makes the log a *lot* more readable.\n\nIn my original patch (the one you apparently have in 'pu'), I did that \ndifferently (and not very well), but maybe that approach lends itself \nbetter to showing some kind of patch.\n\nI think my newer version is likely better.\n\n\t\tLinus\n"}]}