{"thread":{"id":"3890","subject":"path limiting broken","startedAt":"2006-04-16T12:26:38Z","lastAt":"2006-04-17T02:48:11Z","messageCount":13,"participants":["Johannes Schindelin","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18739","messageId":"Pine.LNX.4.63.0604161411120.15345@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":null,"subject":"path limiting broken","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T12:26:38Z","receivedAt":"2006-04-16T12:26:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nI just tried to find out when certain changes percolated into log-tree.c. \nSo I issued \"git log --cc next log-tree.c\". Wonders of wonders, the \npatches did not contain *anything* about what I tried to find, even if the \nfile contains the key words. Because the path limiting is overeager (I \nfinally found what I looked for in commit f4235f8b):\n\n\tgit-name-rev $(git-rev-list --pretty=oneline \\\n\tf4235f8b2ef875b85ead74ffa199d827f9ee9d8d..next log-tree.c | \\\n\tsed \"s/ .*$//\")\n\nyields\n\n\tcb8f64b4e3f263c113b7a2f156af74b810e969ff next^2\n\tcd2bdc5309461034e5cc58e1d3e87535ed9e093b next~10^2~2\n\nwhile without path limiting,\n\n\tgit-name-rev $(git-whatchanged.sh --pretty=oneline \\\n\tf4235f8b2ef875b85ead74ffa199d827f9ee9d8d^..next log-tree.c | \\\n\tsed -n \"s/^diff-tree \\([^ ]*\\).*$/\\1/p\")\n\nI get\n\n\tcb8f64b4e3f263c113b7a2f156af74b810e969ff next^2\n\tc5ccd8be43df4b916752a176512a9adaf3b94df9 next~4^2\n\tf4235f8b2ef875b85ead74ffa199d827f9ee9d8d next~6^2\n\t183df63940bf92ea626af64d0057165b8aad24f6 next~8^2\n\tcd2bdc5309461034e5cc58e1d3e87535ed9e093b next~10^2~2\n\nI am not intelligent enough to find out why there are three revisions \nwhich get culled.\n\nIdeas?\n\nCiao,\nDscho\n"},{"id":"18740","messageId":"Pine.LNX.4.64.0604160850230.3701@g5.osdl.org","threadId":"3890","inReplyTo":"Pine.LNX.4.63.0604161411120.15345@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: path limiting broken","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-16T16:06:28Z","receivedAt":"2006-04-16T16:06:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> \n> I am not intelligent enough to find out why there are three revisions \n> which get culled.\n> \n> Ideas?\n\nPath limiting by default looks at all parents of a merge, and if any of \nthem is identical to the child (within the path limiter), it will pick \n_that_ parent, and that parent only, and drop all other parents.\n\n(If there are multiple identical parents, it will pick the first one).\n\nFor example, if you do\n\n\t\t HEAD\n\t\t   |\n\t\t   a\n\t\t  / \\\n\t\t b   c\n\t\t |  /|\n\t\t | / d\n\t\t |/  |\n\t\t e   f\n\t\t |  /\n\t\t g /\n\t\t |/\n\t\t h\n\nand the file was modified in commit \"b\" and nowhere else, then think about \nwhat the final history should look like.. Since it was modified in \"b\", \nit's going to be the same in \"a\" and \"b\", so the path limiting will \ntotally drop the whole \"c\" subtree, and will only ever look at the tree \na->b->e->g->h.\n\nAfter that, it will simplify the history by dropping commits that don't \nchange the path, and the whole history will end up being just \"b\".\n\nWhich is exactly what you want.\n\nNow, realize that if the exact _same_ change is done in \"f\", the same \nthing will happen. \"f\" will never be shown, because \"f\" simply isn't \ninteresting. We picked up the same change in \"b\", and while the merge \"a\" \nhad _both_ parents identical in the file, it would pick only the first \none. So we'll never even _look_ at \"f\".\n\nNow, this is _important_. Pruning merges is really fundamental to giving a \nreasonable file history, and not just a performance optimization. If the \nsame change came from two branches, we really don't care who did it: we'll \nhit _one_ of the changes even after pruning. But yes, it could miss the \nother one.\n\nHere's a patch to show what an unpruned history ends up looking like.\n\nWith this patch applied, try the following:\n\n\tgitk -- ls-tree.c &\n\tgitk --no-prune-merges -- ls-tree.c &\n\nand compare the two. You'll see _immediately_ why I think merge pruning is \nnot just a good idea, it's something we _have_ to do.\n\n\t\tLinus\n----\ndiff --git a/revision.c b/revision.c\nindex 0505f3f..25338b6 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -291,7 +291,7 @@ static void try_to_simplify_commit(struc\n \t\tparse_commit(p);\n \t\tswitch (rev_compare_tree(revs, p->tree, commit->tree)) {\n \t\tcase REV_TREE_SAME:\n-\t\t\tif (p->object.flags & UNINTERESTING) {\n+\t\t\tif (revs->no_merge_pruning || (p->object.flags & UNINTERESTING)) {\n \t\t\t\t/* Even if a merge with an uninteresting\n \t\t\t\t * side branch brought the entire change\n \t\t\t\t * we are interested in, we do not want\n@@ -640,6 +640,10 @@ int setup_revisions(int argc, const char\n \t\t\t\trevs->unpacked = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--no-prune-merges\")) {\n+\t\t\t\trevs->no_merge_pruning = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\t*unrecognized++ = arg;\n \t\t\tleft++;\n \t\t\tcontinue;\ndiff --git a/revision.h b/revision.h\nindex 8970b57..a116305 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -26,6 +26,7 @@ struct rev_info {\n \t/* Traversal flags */\n \tunsigned int\tdense:1,\n \t\t\tno_merges:1,\n+\t\t\tno_merge_pruning:1,\n \t\t\tremove_empty_trees:1,\n \t\t\tlifo:1,\n \t\t\ttopo_order:1,\n"},{"id":"18741","messageId":"Pine.LNX.4.63.0604161835410.17985@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":"Pine.LNX.4.64.0604160850230.3701@g5.osdl.org","subject":"Re: path limiting broken","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T16:45:29Z","receivedAt":"2006-04-16T16:45:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Apr 2006, Linus Torvalds wrote:\n\n> On Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> > \n> > I am not intelligent enough to find out why there are three revisions \n> > which get culled.\n> \n> Path limiting by default looks at all parents of a merge, and if any of \n> them is identical to the child (within the path limiter), it will pick \n> _that_ parent, and that parent only, and drop all other parents.\n\nThat's okay.\n\nBut you missed my point. The file log-tree.c had some opt handling. I \nchanged it (as can be seen in my patch for combined diffstat), so the \nmerge did not go well with next, which removed that code.\n\nSo I tried to be clever and find the (non-merge) commit where this \nhappened. With what you describe, I should have hit *exactly one* commit \nremoving the code.\n\nBut I hit *exactly none* with \"git log --cc master log-tree.c\".\n\nCiao,\nDscho\n"},{"id":"18742","messageId":"Pine.LNX.4.63.0604161905010.18184@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":"Pine.LNX.4.64.0604160850230.3701@g5.osdl.org","subject":"Re: path limiting broken","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T17:05:07Z","receivedAt":"2006-04-16T17:05:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\njust to make it clearer what I want:\n\n\tgit-whatchanged -p next | grep parse_whatchanged\n\nas well as\n\n\tgit log -p next | grep parse_whatchanged\n\ndo not find that any line like\n\n\tint parse_whatchanged_opt(int ac, [...]\n\nwas removed, but they find that this line was added. However, in the \nworking tree (which has a fresh checkout of next), there is no such line \nin log-tree.c. So I really would like to know where it vanished!\n\nCiao,\nDscho\n"},{"id":"18743","messageId":"Pine.LNX.4.64.0604161000550.3701@g5.osdl.org","threadId":"3890","inReplyTo":"Pine.LNX.4.63.0604161835410.17985@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: path limiting broken","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-16T17:07:14Z","receivedAt":"2006-04-16T17:07:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> \n> But you missed my point. The file log-tree.c had some opt handling. I \n> changed it (as can be seen in my patch for combined diffstat), so the \n> merge did not go well with next, which removed that code.\n> \n> So I tried to be clever and find the (non-merge) commit where this \n> happened. With what you describe, I should have hit *exactly one* commit \n> removing the code.\n> \n> But I hit *exactly none* with \"git log --cc master log-tree.c\".\n\nDo you have the tree somewhere?\n\nIn the current git tree, there really _is_ just one commit that touches \nlog-tree.c in \"master\". And \"git log log-tree.c\" picks that out without \ntrouble.\n\nDid you mean to do\n\n\tgit log --cc next log-tree.c\n\ninstead, perhaps? (Note the \"next\" branch specifier) That definitely shows \nthree commits, including very much the one that moves the common option \nparsing to revision.c (do \"git log --cc --full-diff next log-tree.c\" if \nyou want to see the whole diff whenever something touches log-tree.c).\n\nMaybe I'm still missing something, but it seems to do the right thing \nfor me..\n\n\t\tLinus\n"},{"id":"18744","messageId":"Pine.LNX.4.63.0604161911530.18261@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":"Pine.LNX.4.64.0604161000550.3701@g5.osdl.org","subject":"Re: path limiting broken (NOT)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T17:27:17Z","receivedAt":"2006-04-16T17:27:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Apr 2006, Linus Torvalds wrote:\n\n> On Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> > \n> > But you missed my point. The file log-tree.c had some opt handling. I \n> > changed it (as can be seen in my patch for combined diffstat), so the \n> > merge did not go well with next, which removed that code.\n> > \n> > So I tried to be clever and find the (non-merge) commit where this \n> > happened. With what you describe, I should have hit *exactly one* commit \n> > removing the code.\n> > \n> > But I hit *exactly none* with \"git log --cc master log-tree.c\".\n> \n> Do you have the tree somewhere?\n\nI have no quick way to publish it, if you mean that.\n\n> In the current git tree, there really _is_ just one commit that touches \n> log-tree.c in \"master\". And \"git log log-tree.c\" picks that out without \n> trouble.\n\nIt is my master. Not Junio's.\n\nThe problem seems to be that the current next does not have the code. But \nwhen I last merged, it had it. So basically, I have a problem here that I \nthought \"git log --cc\" can solve, but it doesn't.\n\n\"git log -cc\" is good to find out when code *that is present now* has \ncrept in, but it is no good to find out when code that was in commit \nsuch-and-such, and is no longer in commit such-and-that, has been culled.\n\nPity.\n\nThanks for your help,\nDscho\n"},{"id":"18745","messageId":"Pine.LNX.4.63.0604161931530.19020@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":"Pine.LNX.4.64.0604161000550.3701@g5.osdl.org","subject":"Re: path limiting broken","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T17:39:09Z","receivedAt":"2006-04-16T17:39:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nme again.\n\nI finally found the commit which removed parse_whatchanged_opt() from \nlog-tree.c by\n\n\tgit-rev-list 4a617..next | while read commit; do \\\n\t\techo $commit; \\\n\t\tgit diff $commit^..$commit log-tree.c | \\\n\t\t\tgrep parse_whatchanged; \\\n\tdone | less\n\nwhere obviously 4a617 is the commit I last merged with. The winner is: \n\n\t43f934aa90... Merge branch 'lt/logopt' into next\n\nHowever, the combined diff of that commit does not show it, while the diff \nto the first parent does:\n\n\tgit-show --cc 43f934aa90 | grep parse_whatchanged\n\nshows nothing (-c -p shows half of the truth), while\n\n\tgit-diff 43f934aa90^..43f934aa90 | grep parse_whatchanged\n\nshows something, and \n\n\tgit-diff 43f934aa90^2..43f934aa90 | grep parse_whatchanged\n\nagain does not.\n\nTime to understand the combined diff logic, I guess...\n\nCiao,\nDscho\n"},{"id":"18746","messageId":"Pine.LNX.4.64.0604161034290.3701@g5.osdl.org","threadId":"3890","inReplyTo":"Pine.LNX.4.63.0604161905010.18184@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: path limiting broken","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-16T17:51:50Z","receivedAt":"2006-04-16T17:51:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> \n> just to make it clearer what I want:\n> \n> \tgit-whatchanged -p next | grep parse_whatchanged\n> \n> as well as\n> \n> \tgit log -p next | grep parse_whatchanged\n> \n> do not find that any line like\n> \n> \tint parse_whatchanged_opt(int ac, [...]\n> \n> was removed, but they find that this line was added. However, in the \n> working tree (which has a fresh checkout of next), there is no such line \n> in log-tree.c. So I really would like to know where it vanished!\n\nIt was removed by merge 43f934aa: \"Merge branch 'lt/logopt' into next\".\n\nThe \"parse_whatchanged_opt()\" function never existed in that lt/logopt \nbranch, and merging it (manually, I assume) it doesn't exist in the result \neither.\n\nGeneral hint: if you don't find it in \"--cc\", then that means that it's \nalmost certainly a merge. \"--cc\" will only find things that _clash_, ie \nthe end result is different from either of the branches (and in this case, \nit wasn't different, since parse_whatchanged_opt() simply didn't exist in \nthe branch that was merged).\n\nNow, finding things in merges can be a bit painful, but the sure-fire safe \nway is the old one: use \"-m -p\" to show _all_ sides of a merge as a diff. \nThat's a really inconvenient format for reading, but it literally shows \nall changes to all parents.\n\nAgain, \"git log log-tree.c\" actually does do the right thing: the current \nstate of \"log-tree.c\" really has _all_ of its history coming from the \nlt/logopt branch, which is why when you do\n\n\tgit log -m -p log-tree.c | grep int parse_whatchanged_opt\n\nyou won't get any result at all: the _current_ state of log-tree.c really \nhas no history what-so-ever that involved parse_whatchanged_opt. That may \nsound strange, but it really is very true. Doing a \"gitk log-tree.c\" shows \nwhat the real history of the contents of that file is.\n\nAnd this actually comes back to a very fundamental git issue: git tracks \n_contents_. It doesn't care one whit if there was another branch that had \nsome other history for that file: if that other branch didn't affect the \ncontents of the file, then that other branch simply doesn't exist as far \nas that particular file history is concerned. It only exists as a \"bigger\" \nissue.\n\nBut that \"-m -p\" thing can be useful when you do want to see the bigger \nissue. As might \"--no-prune-merges\".\n\n\t\tLinus\n"},{"id":"18748","messageId":"Pine.LNX.4.64.0604161052310.3701@g5.osdl.org","threadId":"3890","inReplyTo":"Pine.LNX.4.63.0604161931530.19020@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: path limiting broken","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-16T17:58:50Z","receivedAt":"2006-04-16T17:58:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> \n> I finally found the commit which removed parse_whatchanged_opt() from \n> log-tree.c by\n> \n> \tgit-rev-list 4a617..next | while read commit; do \\\n> \t\techo $commit; \\\n> \t\tgit diff $commit^..$commit log-tree.c | \\\n> \t\t\tgrep parse_whatchanged; \\\n> \tdone | less\n\nHeh. You really should learn about \"-m -p\", which does the above, but \nbetter (it compares against _all_ parents - you would have missed the \nthing _again_ if the \"lt/logopt\" branch had been the main branch ;)\n\n> However, the combined diff of that commit does not show it, while the diff \n> to the first parent does:\n> \n> \tgit-show --cc 43f934aa90 | grep parse_whatchanged\n\nCombined merges really only show conflicts where the different parents do \nsomething different from the end result. Since the whole file was taken \nfrom the lt/logopt branch, even\n\n\tgit show -c 43f934aa90\n\nwon't show that \"log-tree.c\" file AT ALL, because there was no content \nconflict: the whole file was taken from one branch, unmodified. \n\nIf you want to see all changes against all parents, you really do need \n\"-m -p\" (or just \"-m\", which will show the raw diffs, and which will \nshow how the file changes from one parent, but not the other).\n\nNote that NORMALLY, you'd really never want to use \"-m -p\". It's a very \nvery inconvenient format, since normally you want to see only the stuff \nthat changed wrt the end result.\n\nSo \"--cc\" really does ignore everything that is irrelevant for the end \nresult, and in this case you are very much trying to find somethign that \nis totally irrelevant for the end result, since the function you look for \nhad never even _existed_ in the file as far as the end result goes..\n\n\t\tLinus\n"},{"id":"18749","messageId":"Pine.LNX.4.63.0604162006050.19560@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":"Pine.LNX.4.64.0604161052310.3701@g5.osdl.org","subject":"Re: path limiting broken","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T18:09:24Z","receivedAt":"2006-04-16T18:09:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Apr 2006, Linus Torvalds wrote:\n\n> On Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> > \n> > I finally found the commit which removed parse_whatchanged_opt() from \n> > log-tree.c by\n> > \n> > \tgit-rev-list 4a617..next | while read commit; do \\\n> > \t\techo $commit; \\\n> > \t\tgit diff $commit^..$commit log-tree.c | \\\n> > \t\t\tgrep parse_whatchanged; \\\n> > \tdone | less\n> \n> Heh. You really should learn about \"-m -p\", which does the above, but \n> better (it compares against _all_ parents - you would have missed the \n> thing _again_ if the \"lt/logopt\" branch had been the main branch ;)\n\nSomehow I forgot. Probably because I don't like the format either.\n\n> [...] even\n> \n> \tgit show -c 43f934aa90\n> \n> won't show that \"log-tree.c\" file AT ALL, because there was no content \n> conflict: the whole file was taken from one branch, unmodified. \n\nThere's another reason it does not show it. ATM, you have to add \"-p\" to \nthe command line, or \"-c\" will not show *any* patch, let alone a combined \none.\n\n> So \"--cc\" really does ignore everything that is irrelevant for the end \n> result, and in this case you are very much trying to find somethign that \n> is totally irrelevant for the end result, since the function you look for \n> had never even _existed_ in the file as far as the end result goes..\n\nThanks for all your help, but in this case it was not irrelevant. Because \nI *had* the function in my working copy. And I had changed it. So I had to \nfind out where to move the change.\n\nAgain, thanks a bunch,\nDscho\n"},{"id":"18750","messageId":"Pine.LNX.4.64.0604161117360.3701@g5.osdl.org","threadId":"3890","inReplyTo":"Pine.LNX.4.63.0604162006050.19560@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: path limiting broken","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-16T18:27:15Z","receivedAt":"2006-04-16T18:27:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> \n> There's another reason it does not show it. ATM, you have to add \"-p\" to \n> the command line, or \"-c\" will not show *any* patch, let alone a combined \n> one.\n\nOh, it will show the \"raw\" patch, which is often very useful. I've grown \nquite fond of it, because it shows what happened on a bigger level, \nwithout showing the details within a file (\"--name-status\" makes it more \nreadable, but I'm too lazy to type it, so I often just look at the raw \ngit patch).\n\n> Thanks for all your help, but in this case it was not irrelevant. Because \n> I *had* the function in my working copy. And I had changed it. So I had to \n> find out where to move the change.\n\nRight, but it was irrelevant as far as \"top-of-head\" was concerned (which \nis all that \"git log\" shows you - it doesn't care about your working \ntree).\n\nThe fact that it _had_ been relevant in the state you used to be at is not \nsomething \"git log\" and friends know or care about.\n\nNow, I'm not disputing that we might want to make it easier to see what \n_had_ been relevant at some earlier time. But you'd have to specify that \nearlier time somehow. I assume you had tried to do a \"git rebase\", and the \nproblem with that is that git rebase really doesn't help you at all when \nthings go wrong, exactly because \"rebase\" - by design - screws up the \nhistory and loses that information for you.\n\nIf your problem state had been as a result of a \"git merge\", you'd \nactually have had much better tools available to you, exactly because \nmerge doesn't screw up history, so you've got both sides of the merge you \ncan look at (HEAD and MERGE_HEAD, and \"git diff --ours\" and \"--theirs\").\n\nThat said, even \"rebase\" will help somewhat. You've got \"ORIG_HEAD\" to \nuse, and that should help at least a _bit_. In particular, you can do\n\n\tgitk ORIG_HEAD.. \n\nto see all the changes you rebased across. But right now you'd have to \nfall back on the \"-m -p\" thing if you wanted to see it all..\n\n\t\tLinus\n"},{"id":"18758","messageId":"Pine.LNX.4.63.0604170138470.824@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3890","inReplyTo":"Pine.LNX.4.64.0604161117360.3701@g5.osdl.org","subject":"Re: path limiting broken","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-16T23:49:07Z","receivedAt":"2006-04-16T23:49:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Apr 2006, Linus Torvalds wrote:\n\n> On Sun, 16 Apr 2006, Johannes Schindelin wrote:\n> > \n> > Thanks for all your help, but in this case it was not irrelevant. Because \n> > I *had* the function in my working copy. And I had changed it. So I had to \n> > find out where to move the change.\n> \n> Right, but it was irrelevant as far as \"top-of-head\" was concerned (which \n> is all that \"git log\" shows you - it doesn't care about your working \n> tree).\n> \n> The fact that it _had_ been relevant in the state you used to be at is not \n> something \"git log\" and friends know or care about.\n> \n> Now, I'm not disputing that we might want to make it easier to see what \n> _had_ been relevant at some earlier time. But you'd have to specify that \n> earlier time somehow.\n\nSince quite some time, I wanted to have a way to git-rev-list just the \nrevs between commit1 and commit2, i.e. all commits which are ancestors of \ncommit2, and which have commit1 as ancestor. With this, my task would have \nbeen more than simple.\n\n> I assume you had tried to do a \"git rebase\", and the problem with that \n> is that git rebase really doesn't help you at all when things go wrong, \n> exactly because \"rebase\" - by design - screws up the history and loses \n> that information for you.\n\nNope. Was a merge.\n\n> If your problem state had been as a result of a \"git merge\", you'd \n> actually have had much better tools available to you, exactly because \n> merge doesn't screw up history, so you've got both sides of the merge you \n> can look at (HEAD and MERGE_HEAD, and \"git diff --ours\" and \"--theirs\").\n\nThat outputs too much. I really wanted to find just the commit which \nremoved the function, in order to know where the code was moved to.\n\nORIG_HEAD would not help, because that commit is not an ancestor.\n\n> [...] In particular, you can do\n> \n> \tgitk ORIG_HEAD.. \n\n... and it will say\n\n\tError: expected integer but got \"\"\n\t    while executing\n\t\"clock format $d -format \"%Y-%m-%d %H:%M:%S \"\"\n\t    (procedure \"formatdate\" line 2)\n\t    invoked from within\n\t\"formatdate $date\"\n\t    (procedure \"drawcmittext\" line 28)\n\t    invoked from within\n\t\"drawcmittext $id $row $col $rmx\"\n\t    (procedure \"drawcmitrow\" line 41)\n\t    invoked from within\n\t\"drawcmitrow $row\"\n\t    (procedure \"showstuff\" line 35)\n\t    invoked from within\n\t\"showstuff $canshow\"\n\t    (procedure \"layoutmore\" line 15)\n\t    invoked from within\n\t\"layoutmore\"\n\t    (procedure \"getcommitlines\" line 91)\n\t    invoked from within\n\t\"getcommitlines file7\"\n\nSorry, I am too tired now to investigate, have been working already to \nlong. Tomorrow's another day.\n\nCiao,\nDscho\n"},{"id":"18763","messageId":"Pine.LNX.4.64.0604161943360.3701@g5.osdl.org","threadId":"3890","inReplyTo":"Pine.LNX.4.63.0604170138470.824@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: path limiting broken","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-17T02:48:11Z","receivedAt":"2006-04-17T02:48:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 17 Apr 2006, Johannes Schindelin wrote:\n> \n> Since quite some time, I wanted to have a way to git-rev-list just the \n> revs between commit1 and commit2, i.e. all commits which are ancestors of \n> commit2, and which have commit1 as ancestor. With this, my task would have \n> been more than simple.\n\nYes. However, it's not trivial.\n\nIn fact, what you want is not what you claim you want. To be useful in \ngeneral, you have to _also_ handle the case of \"commit2\" not beign a \nstrict ancestor of \"commit1\". So what you actually want to do is\n\n - calculate the merge-head of cmit1 and cmit2 (and if there are multiple, \n   pick some \"best\" one).\n - pick the shortest path from the merge-head to the cmit1 (and, with a \n   flag, also pick the path from merge-head to cmit2 - sometimes you want \n   to see the whole path from one to the other, sometimes you might want \n   to see just the path from the last common point).\n\nI suspect it ends up being not _that_ different from calculating the \nbisection point, but I haven't thought it through entirely.\n\n\t\tLinus\n"}]}