{"thread":{"id":"53984","subject":"Why is AuthorDate displayed on git-blame?","startedAt":"2020-08-05T00:19:01Z","lastAt":"2020-08-08T00:35:05Z","messageCount":10,"participants":["נעם סולוביצ'יק","Junio C Hamano","brian m. carlson","Raymond E. Pasco","Noam Soloveichik","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"402874","messageId":"CAAWR3A9po-zMVFdQfDs6R5F_rf0UvSyfByLj-vYZiXLb8+j4Ug@mail.gmail.com","threadId":"53984","inReplyTo":null,"subject":"Why is AuthorDate displayed on git-blame?","fromName":"נעם סולוביצ'יק","fromEmail":"inoamsol@gmail.com","sentAt":"2020-08-05T00:18:43Z","receivedAt":"2020-08-05T00:19:01Z","isPatch":false,"sender":{"key":"inoamsol@gmail.com","avatar":null},"body":"Hey everybody, I wonder about the decision behind git-blame and\ngit-annotate date that is being shown.\n\nIf I understand correctly, the AuthorDate is displayed, and I'd like\nto challenge that decision. Consider the following case:\n\nA feature branch having commits authored last week, but merged to the\nmain branch just today. And to the sake of discussion, let's say that\nthe branch has a bug.\n\nWhen someone encounters the bug on the main branch, he would probably\nwant to know when it was introduced - the date when the bug started\nto affect him. However, git-blame only shows him when the bug was\noriginally authored, in our case - *last-week*, which is confusing\nsince the main branch was working just fine back then.\n\nSo I wonder why was AuthorDate the date chosen to be displayed under\ngit-blame?\n"},{"id":"402876","messageId":"xmqq5z9yq611.fsf@gitster.c.googlers.com","threadId":"53984","inReplyTo":"CAAWR3A9po-zMVFdQfDs6R5F_rf0UvSyfByLj-vYZiXLb8+j4Ug@mail.gmail.com","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-05T00:40:26Z","receivedAt":"2020-08-05T00:40:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"נעם סולוביצ'יק writes:\n\n> A feature branch having commits authored last week, but merged to the\n> main branch just today. And to the sake of discussion, let's say that\n> the branch has a bug.\n>\n> When someone encounters the bug on the main branch, he would probably\n> want to know when it was introduced - the date when the bug started\n> to affect him. However, git-blame only shows him when the bug was\n> originally authored, in our case - *last-week*, which is confusing\n> since the main branch was working just fine back then.\n>\n> So I wonder why was AuthorDate the date chosen to be displayed under\n> git-blame?\n\nQuite honestly, the left-hand side of \"git blame\" output is not all\nthat useful, as the usual workflow is to use \"blame\" to only to\nidentify a commit (or a set of commits) and from there, any detailed\ninformation of problematic commits will be inspected with \"git show\"\nor equivalent, so in that sense, \"git blame -s\" could be the most\nuseful output format.\n\nIt should be trivial to add an option to show the commit date\ninstead, so in that sense, the answer to the immediate question \"why\nauthor date?\" is \"just because we chose to show it; you are welcome\nto send in a patch to add an option to show committer date\". \n\nHowever, your question has another ingredient that is much more\ninteresting. If you are interested only at the level of changes to\nthe primary integration branch, showing either author or committer\ndate of the ultimately responsible individual commit that was\nbrought in by a merge of a topic branch to the integration branch is\nnot useful at all for your purpose. You need to find out which\nmerge brought the change to the integraiton branch and you do not\ncare which individual commit on the side branch that was merged.\n\nIOW, what you would want is a \"git blame --first-parent\".\n\n\n\n\n\n\n"},{"id":"402892","messageId":"20200805015939.GQ6540@camp.crustytoothpaste.net","threadId":"53984","inReplyTo":"CAAWR3A9po-zMVFdQfDs6R5F_rf0UvSyfByLj-vYZiXLb8+j4Ug@mail.gmail.com","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-08-05T01:59:39Z","receivedAt":"2020-08-05T02:00:17Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-08-05 at 00:18:43, נעם סולוביצ'יק wrote:\n> Hey everybody, I wonder about the decision behind git-blame and\n> git-annotate date that is being shown.\n> \n> If I understand correctly, the AuthorDate is displayed, and I'd like\n> to challenge that decision. Consider the following case:\n> \n> A feature branch having commits authored last week, but merged to the\n> main branch just today. And to the sake of discussion, let's say that\n> the branch has a bug.\n> \n> When someone encounters the bug on the main branch, he would probably\n> want to know when it was introduced - the date when the bug started\n> to affect him. However, git-blame only shows him when the bug was\n> originally authored, in our case - *last-week*, which is confusing\n> since the main branch was working just fine back then.\n> \n> So I wonder why was AuthorDate the date chosen to be displayed under\n> git-blame?\n\nI can't speak for the original author of this, and I think Junio's\nanswer explains this well, but I'd like to add an additional thought on\nwhy the current behavior is useful.\n\nFor me, I am primarily interested in using blame to find information\nabout the party most knowledgable about the subsystem or area, or to\nfind a commit that introduced a change (possibly so I can read its\ncommit message or pull request). I'm less likely to use blame to, well,\nblame people. Consequently, it's often helpful for me to know about\nwhen the code was written, since that tells me more about the author and\ntheir situation than the committer information does.\n\nFor a project like Git, the committer information would not be very\ninteresting to me, since Junio, while very competent, is not the expert\nfor every line in the codebase. Since we're displaying the author name,\nwe might as well display the author timestamp as well.\n\nI'm in favor of an option for this, though.\n-- \nbrian m. carlson: Houston, Texas, US\n"},{"id":"402956","messageId":"xmqqa6z9oz2l.fsf@gitster.c.googlers.com","threadId":"53984","inReplyTo":"20200805015939.GQ6540@camp.crustytoothpaste.net","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-05T16:08:18Z","receivedAt":"2020-08-05T20:13:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> .... Since we're displaying the author name,\n> we might as well display the author timestamp as well.\n\nAh, yes, I did forget this important aspect. The date goes with the\nname, so it would be awkward to show committer timestamp together\nwith the author name.\n\n"},{"id":"403028","messageId":"C4PPV24G8ZNK.3IYI2MQ3A262Y@ziyou","threadId":"53984","inReplyTo":"xmqq5z9yq611.fsf@gitster.c.googlers.com","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-08-06T06:57:20Z","receivedAt":"2020-08-06T11:04:55Z","isPatch":false,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"On Tue Aug 4, 2020 at 8:40 PM EDT, Junio C Hamano wrote:\n> IOW, what you would want is a \"git blame --first-parent\".\n\nThis exists (because blame takes rev-list options) and works as expected\n(because blame.c handles this case), but is not documented. We could\ninclude rev-list-options.txt, but this wouldn't be accurate because\nblame does some of its own commit walking. Perhaps the following\nadaptation:\n\n--first-parent::\n\tFollow only the first parent commit upon seeing a merge\n\tcommit. This option can be used to determine when a line\n\twas introduced to a particular integration branch, rather\n\tthan when it was introduced to the history overall.\n"},{"id":"403066","messageId":"6dabe718-6d6e-e76c-677d-f2dc4a5b83be@gmail.com","threadId":"53984","inReplyTo":"C4PPV24G8ZNK.3IYI2MQ3A262Y@ziyou","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Noam Soloveichik","fromEmail":"inoamsol@gmail.com","sentAt":"2020-08-06T15:19:23Z","receivedAt":"2020-08-06T17:36:10Z","isPatch":false,"sender":{"key":"inoamsol@gmail.com","avatar":null},"body":"\nOn 06/08/2020 9:57, Raymond E. Pasco wrote:\n> On Tue Aug 4, 2020 at 8:40 PM EDT, Junio C Hamano wrote: > --first-parent:: Follow only the first parent commit upon seeing a > merge commit. This option can be used to determine when a line was > introduced to a particular integration branch, rather than when it > was introduced to the history overall.\nI want to make sure I understand your proposal correctly -\n--first-parent would still show AuthorDate, but of the\n*merge-commit*, and not the commit that introduced the line of code\nto the history overall.\n\nIf so, it's going to get the job done for commits which are applied\nby a merge-commit. Although I wonder what --first-parent would\ndisplay for commits which are applied *not* by a merge.\n\nConsider the linux kernel, where some of its commits are merge\ncommits from pull requests, and some are applied patches: with\ndifferent AuthorDate and CommitDate. For those commits, AuthorDate\nrepresents the date the patch was originally sent to review, not when\nit was introduced to the integration branch, which is represented by\nthe CommitDate, which leads to inconsistencies.\n"},{"id":"403085","messageId":"xmqq1rkjljus.fsf@gitster.c.googlers.com","threadId":"53984","inReplyTo":"C4PPV24G8ZNK.3IYI2MQ3A262Y@ziyou","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-06T18:17:31Z","receivedAt":"2020-08-06T18:34:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Raymond E. Pasco\" writes:\n\n> Perhaps the following\n> adaptation:\n>\n> --first-parent::\n> \tFollow only the first parent commit upon seeing a merge\n> \tcommit. This option can be used to determine when a line\n> \twas introduced to a particular integration branch, rather\n> \tthan when it was introduced to the history overall.\n\nYup. We somehow forgot to document it when we did 95a4fb0e (blame:\nhandle --first-parent, 2015-09-15). The text reads well.\n\nCare to make it into a patch?\n\nThanks.\n\n"},{"id":"403086","messageId":"C4Q493FC0N34.3GA87TXK6SJPJ@ziyou","threadId":"53984","inReplyTo":"6dabe718-6d6e-e76c-677d-f2dc4a5b83be@gmail.com","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-08-06T18:13:55Z","receivedAt":"2020-08-06T18:36:59Z","isPatch":false,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"On Thu Aug 6, 2020 at 11:19 AM EDT, Noam Soloveichik wrote:\n> I want to make sure I understand your proposal correctly -\n> --first-parent would still show AuthorDate, but of the\n> *merge-commit*, and not the commit that introduced the line of code\n> to the history overall.\n\nTo be clear, I'm not proposing anything but surfacing a useful feature\nthat already exists in the documentation.\n\n> If so, it's going to get the job done for commits which are applied\n> by a merge-commit. Although I wonder what --first-parent would\n> display for commits which are applied *not* by a merge.\n\n--first-parent commands don't care about merges, except that they never\nfollow the second or later parents of a merge. blame just tries to find\nthe earliest commit that had this version of some line in it; if it only\nfollows first parents then that will often end up being a merge (if\nyou're on an integration branch) but doesn't have to be.\n\n> Consider the linux kernel, where some of its commits are merge\n> commits from pull requests, and some are applied patches: with\n> different AuthorDate and CommitDate. For those commits, AuthorDate\n> represents the date the patch was originally sent to review, not when\n> it was introduced to the integration branch, which is represented by\n> the CommitDate, which leads to inconsistencies.\n\nI honestly don't make use of dates in my workflow at all, so I don't\nreally have an opinion on date issues. The author date is marginally\nmore interesting to me, but only marginally and only really in projects\nthat use email (where the author date \"git am\" records is the date on\nthe email the patch came in).\n\nOf course an option to choose which author/date pair (author or\ncommitter) to annotate the file with would be a fine addition benefiting\npeople who do look at the dates. I use first-parent histories all the\ntime, however, and I'd like to see this useful existing blame option\ndocumented.\n"},{"id":"403088","messageId":"20200806185243.27179-1-ray@ameretat.dev","threadId":"53984","inReplyTo":"xmqq1rkjljus.fsf@gitster.c.googlers.com","subject":"[PATCH] blame-options.txt: document --first-parent option","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-08-06T18:52:43Z","receivedAt":"2020-08-06T18:53:07Z","isPatch":true,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"blame/annotate have supported --first-parent since commit 95a4fb0eac\n(\"blame: handle --first-parent\"). This adds a blurb on that option to\nthe documentation.\n\nSigned-off-by: Raymond E. Pasco \n---\n Documentation/blame-options.txt | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt\nindex 5d122db6e9..88750af7ae 100644\n--- a/Documentation/blame-options.txt\n+++ b/Documentation/blame-options.txt\n@@ -36,6 +36,12 @@ include::line-range-format.txt[]\n \tSTART. `git blame --reverse START` is taken as `git blame\n \t--reverse START..HEAD` for convenience.\n \n+--first-parent::\n+\tFollow only the first parent commit upon seeing a merge\n+\tcommit. This option can be used to determine when a line\n+\twas introduced to a particular integration branch, rather\n+\tthan when it was introduced to the history overall.\n+\n -p::\n --porcelain::\n \tShow in a format designed for machine consumption.\n-- \n2.28.0\n\n"},{"id":"403178","messageId":"20200808003500.GA3751874@coredump.intra.peff.net","threadId":"53984","inReplyTo":"xmqq1rkjljus.fsf@gitster.c.googlers.com","subject":"Re: Why is AuthorDate displayed on git-blame?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-08T00:35:00Z","receivedAt":"2020-08-08T00:35:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 06, 2020 at 11:17:31AM -0700, Junio C Hamano wrote:\n\n> \"Raymond E. Pasco\" writes:\n> \n> > Perhaps the following\n> > adaptation:\n> >\n> > --first-parent::\n> > \tFollow only the first parent commit upon seeing a merge\n> > \tcommit. This option can be used to determine when a line\n> > \twas introduced to a particular integration branch, rather\n> > \tthan when it was introduced to the history overall.\n> \n> Yup. We somehow forgot to document it when we did 95a4fb0e (blame:\n> handle --first-parent, 2015-09-15). The text reads well.\n\nMy fault. I think I imagined it would just be included along with other\nrev-list options, but the text above makes it clear why we'd want to\ntalk specifically about how it applies to blame.\n\n-Peff\n"}]}