{"thread":{"id":"32802","subject":"Why git-whatchanged shows a commit touching every file, but git-log doesn't?","startedAt":"2013-01-31T19:09:35Z","lastAt":"2013-01-31T19:34:34Z","messageCount":2,"participants":["Constantine A. Murenin","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"208390","messageId":"CAPKkNb49FUgLxZxHmQJoqccQ1XVcFYbYF8kYDp0+Y27cmi56fg@mail.gmail.com","threadId":"32802","inReplyTo":null,"subject":"Why git-whatchanged shows a commit touching every file, but git-log doesn't?","fromName":"Constantine A. Murenin","fromEmail":"mureninc@gmail.com","sentAt":"2013-01-31T19:09:35Z","receivedAt":"2013-01-31T19:09:35Z","isPatch":false,"sender":{"key":"mureninc@gmail.com","avatar":null},"body":"Hi,\n\nDragonFly BSD uses git as its SCM, with one single repository and\nbranch for both the kernel and the whole userland.\n\nOn 2011-11-26 (1322296064), someone did a commit that somehow touched\nevery single file in the repository, even though most of the files\nwere not modified one bit.\n\nThat's the offending commit from 2011-11-26:\n\nhttp://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/86d7f5d305c6adaa56ff4582ece9859d73106103\nhttps://github.com/DragonFlyBSD/DragonFlyBSD/commit/86d7f5d305c6adaa56ff4582ece9859d73106103\n\nSince then, with some tools, if you look at file history for any file\nanywhere in the repo, you can see that all files were changed on\n2011-11-26 with that commit, but it's only shown in some tools, and\nnot shown in others.\n\n\nFor example, the bogus 2011-11-26 commit is not shown with the following:\n\n * git log sys/sys/sensors.h\n\n * https://github.com/DragonFlyBSD/DragonFlyBSD/commits/master/sys/sys/sensors.h\n\n\nHowever, the bogus commit is [erroneously] shown with the following:\n\n% git whatchanged --pretty=%at sys/sys/sensors.h | cat\n1322296064\n\n:000000 100644 0000000... 554cfc2... A  sys/sys/sensors.h\n1191329821\n\n:000000 100644 0000000... 554cfc2... A  sys/sys/sensors.h\n%\n\nNotice how the file was ]A]dded once again at 1322296064 without ever\nbeing deleted, and that the dst sha1 is the same for both the latest\nand the immediately prior revision of the file.\n\n\nGitweb, unlike github, would also show the erroneous commit from 2011-11:\n\nhttp://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/sys/sys/sensors.h\n\n\nAnother, more representative example, which shows that src sha1 (field\nnames are documented in git-diff-tree(1)) is always \"0000000...\" in\nsuch bogus touch-all commits (even though it makes little sense when\nyou consider that the files were never deleted and still have the same\ndst sha1):\n\n% git whatchanged --pretty=%at sys/sys/sysctl.h | head -9\n1322296064\n\n:000000 100644 0000000... 6659977... A  sys/sys/sysctl.h\n1296826445\n\n:100644 100644 94b8d96... 6659977... M  sys/sys/sysctl.h\n1292413105\n\n:100644 100644 8c9deaa... 94b8d96... M  sys/sys/sysctl.h\n%\n\n\nSo, my questions are as follows:\n\n* How was it possible for all these files to be added without first\nbeing deleted in the first place? Was / is it a bug in git (during a\ncommit) to allow something like that?\n\n* Why do some tools compact such bogus commits out (and hide them from\nthe user), but some don't?\n\n* Is there a way to make git-whatchanged and gitweb ignore such bogus\ncommits on files that weren't actually modified, just as git-log and\ngithub already do?\n\n\nP.S. I've asked this question on\nhttp://stackoverflow.com/q/14632828/1122270, if anyone wants a cookie.\n\n\nBest regards,\nConstantine.\n"},{"id":"208393","messageId":"20130131193434.GG27340@google.com","threadId":"32802","inReplyTo":"CAPKkNb49FUgLxZxHmQJoqccQ1XVcFYbYF8kYDp0+Y27cmi56fg@mail.gmail.com","subject":"Re: Why git-whatchanged shows a commit touching every file, but git-log doesn't?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-31T19:34:34Z","receivedAt":"2013-01-31T19:34:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Constantine,\n\nConstantine A. Murenin wrote:\n\n> DragonFly BSD uses git as its SCM, with one single repository and\n> branch for both the kernel and the whole userland.\n>\n> On 2011-11-26 (1322296064), someone did a commit that somehow touched\n> every single file in the repository, even though most of the files\n> were not modified one bit.\n\n\"gitk --simplify-by-decoration\" might provide some insight.\n\nIn the dragonfly history, it seems that imports of a packages typically\nproceed in two steps:\n\n 1. First, the upstream code is imported as a new \"initial commit\"\n    with no history:\n\n\tcd ~/src\n\tgit init gcc-4.7.2-import\n\tcd gcc-4.7.2-import\n\ttar -xf /path/to/gcc-4.7.2\n\tmkdir contrib\n\tmv gcc-4.7.2 contrib/gcc-4.7\n\tgit add .\n\tgit commit -m 'Import gcc-4.7.2 to new vendor branch'\n\n 2. Next, that code is incorporated into dragonfly.\n\n\tcd ~/src/dragonfly\n\tgit fetch ../gcc-4.7.2-import master:refs/heads/vendor/GCC47\n\tgit merge vendor/GCC47\n\trm -fr ../gcc-4.7.2-import\n\nUnfortunately in the commit you mentioned, someone made a mistake.\nInstead of importing a single new upstream package, the author\nimported the entire dragonfly tree as a new vendor branch.  Oops.\n\nThe effects might be counterintuitive:\n\n * tools like \"git blame\" and path-limited \"git log\" get a choice:\n   when looking at the merge that pulled in a copy of dragonfly into\n   the existing dragonfly codebase, either parent is an equally\n   sensible from blame's point of view as an explanation of the origin\n   of this code.  I think both prefer the first parent here, making them\n   happen to produce the \"right\" result.\n\n * tools like \"git show\" that describe what change a commit made\n   get a choice: when looking at a parentless commit, the diff that\n   brings a project into existence may or may not be interesting,\n   depending on the situation.\n\n   See\n   http://thread.gmane.org/gmane.comp.version-control.git/182571/focus=182577\n   for more about that.\n\nBut at its heart, this is just an instance of \"lie when creating your\nhistory and history-mining tools will lie back to you.\" :)\n\nHoping that clarifies a little,\nJonathan\n"}]}