{"thread":{"id":"33570","subject":"[PATCH] t4202 (log): add test for --follow over a merge","startedAt":"2013-04-22T15:18:32Z","lastAt":"2013-04-23T06:28:21Z","messageCount":2,"participants":["Ramkumar Ramachandra","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"215085","messageId":"1366643912-3942-1-git-send-email-artagnon@gmail.com","threadId":"33570","inReplyTo":null,"subject":"[PATCH] t4202 (log): add test for --follow over a merge","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-22T15:18:32Z","receivedAt":"2013-04-22T15:18:32Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"The --follow feature can be used to follow the history of a file over\na merge commit, and is useful even when the file hasn't been\ncopied/renamed.  Add a test to show off this feature.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n I haven't updated the documentation, because I can't claim to\n understand --follow fully without reading the code (doing that now).\n In the meantime, I'm contributing a patch I wrote out originally as\n an example for Thomas Rast to prove a point.\n\n Where should this go?  What is t4206-log-follow-harder-copies (it\n just has one test which isn't even that special)?  Should we move all\n the --follow tests out of this file and put it in a separate file?\n\n t/t4202-log.sh | 29 +++++++++++++++++++++++++++++\n 1 file changed, 29 insertions(+)\n\ndiff --git a/t/t4202-log.sh b/t/t4202-log.sh\nindex 523c1be..5b041fd 100755\n--- a/t/t4202-log.sh\n+++ b/t/t4202-log.sh\n@@ -168,6 +168,35 @@ test_expect_success 'git log --follow' '\n \n '\n \n+test_expect_success '--follow over merge' '\n+\tgit checkout -b featurebranch\n+\techo foodle >>ichi &&\n+\tgit add ichi &&\n+\ttest_tick &&\n+\tgit commit -m \"add a line to the end of ichi\" &&\n+\techo moodle >unrelated &&\n+\tgit add unrelated &&\n+\ttest_tick &&\n+\tgit commit -m quux &&\n+\tgit checkout master &&\n+\tmv ichi ichi.bak &&\n+\techo gooble >ichi &&\n+\tcat ichi.bak >>ichi &&\n+\tgit add ichi &&\n+\ttest_tick &&\n+\tgit commit -m \"add a line to the beginning of ichi\" &&\n+\tgit merge featurebranch &&\n+\tgit log --follow --oneline ichi >actual &&\n+\tcat >expect <<-\\EOF &&\n+\tdf26551 add a line to the beginning of ichi\n+\t882d8d9 add a line to the end of ichi\n+\t2fbe8c0 third\n+\tf7dab8e second\n+\t3a2fdcb initial\n+\tEOF\n+\ttest_cmp expect actual\n+'\n+\n test_expect_failure 'log pathspec in tree read into prefix' '\n \tgit checkout --orphan subtree &&\n \tgit rm -rf . &&\n-- \n1.8.2.1.546.gea3475a\n"},{"id":"215197","messageId":"20130423062821.GA32683@elie.Belkin","threadId":"33570","inReplyTo":"1366643912-3942-1-git-send-email-artagnon@gmail.com","subject":"Re: [PATCH] t4202 (log): add test for --follow over a merge","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-23T06:28:21Z","receivedAt":"2013-04-23T06:28:21Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRamkumar Ramachandra wrote:\n\n> The --follow feature can be used to follow the history of a file over\n> a merge commit, and is useful even when the file hasn't been\n> copied/renamed.  Add a test to show off this feature.\n\nI can't claim to have followed the discussion, but I don't understand\nthe above.  If the file's name hasn't changed, the most one can hope\nfor is that --follow doesn't hurt, no?\n\n[...]\n> +\tcat >expect <<-\\EOF &&\n> +\tdf26551 add a line to the beginning of ichi\n> +\t882d8d9 add a line to the end of ichi\n> +\t2fbe8c0 third\n> +\tf7dab8e second\n> +\t3a2fdcb initial\n> +\tEOF\n> +\ttest_cmp expect actual\n\nt/README explains:\n\n| As with any programming projects, existing programs are the best\n| source of the information.  However, do _not_ emulate\n| t0000-basic.sh when writing your tests.  The test is special in\n| that it tries to validate the very core of GIT.\n[...]\n|          other tests that simply rely on basic parts of the core\n| GIT working properly should not have that level of intimate\n| knowledge of the core GIT internals.  If all the test scripts\n| hardcoded the object IDs like t0000-basic.sh does, that defeats\n| the purpose of t0000-basic.sh, which is to isolate that level of\n| validation in one place.\n\nHard-coding object names makes it painful to tweak a given test and\ntests that come before it, lest a timestamp or the phase of moon\nchange and cause the object names to drift.   Don't do it, except\nin t0000.\n\nHope that helps,\nJonathan\n"}]}