נעם סולוביצ'יק <inoamsol@xxxxxxxxx> writes: > A feature branch having commits authored last week, but merged to the > main branch just today. And to the sake of discussion, let's say that > the branch has a bug. > > When someone encounters the bug on the main branch, he would probably > want to know when it was introduced - the date when the bug started > to affect him. However, git-blame only shows him when the bug was > originally authored, in our case - *last-week*, which is confusing > since the main branch was working just fine back then. > > So I wonder why was AuthorDate the date chosen to be displayed under > git-blame? Quite honestly, the left-hand side of "git blame" output is not all that useful, as the usual workflow is to use "blame" to only to identify a commit (or a set of commits) and from there, any detailed information of problematic commits will be inspected with "git show" or equivalent, so in that sense, "git blame -s" could be the most useful output format. It should be trivial to add an option to show the commit date instead, so in that sense, the answer to the immediate question "why author date?" is "just because we chose to show it; you are welcome to send in a patch to add an option to show committer date". However, your question has another ingredient that is much more interesting. If you are interested only at the level of changes to the primary integration branch, showing either author or committer date of the ultimately responsible individual commit that was brought in by a merge of a topic branch to the integration branch is not useful at all for your purpose. You need to find out which merge brought the change to the integraiton branch and you do not care which individual commit on the side branch that was merged. IOW, what you would want is a "git blame --first-parent".
