{"thread":{"id":"34025","subject":"Can `git blame` show the date that each line was merged?","startedAt":"2013-06-04T13:39:45Z","lastAt":"2013-06-04T17:44:20Z","messageCount":5,"participants":["Matt McClure","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"219370","messageId":"CAJELnLEiK1C9PeimSwDoJoy=wFbFF0+KoK3jhXSAV4b2DsBKqw@mail.gmail.com","threadId":"34025","inReplyTo":null,"subject":"Can `git blame` show the date that each line was merged?","fromName":"Matt McClure","fromEmail":"matthewlmcclure@gmail.com","sentAt":"2013-06-04T13:39:45Z","receivedAt":"2013-06-04T13:39:45Z","isPatch":false,"sender":{"key":"matthewlmcclure@gmail.com","avatar":"https://gravatar.com/avatar/a8cde96b0594204c8d4c48baa51c983af37dedfa2b7a846e27547b8d63d46e7c?d=mp&s=160"},"body":"Can `git blame` show the date that each line was merged to the current\nbranch rather than the date it was committed?\n\nAside: in some trial and error I notice this oddity:\n\n    $ git blame --merges\n    usage: git blame [options] [rev-opts] [rev] [--] file\n\n        [rev-opts] are documented in git-rev-list(1)\n    ...\n\n    $ git help rev-list | grep -F -e --merges\n                        [ --merges ]\n           --merges\n               --min-parents=2 is the same as --merges.\n--max-parents=0 gives all\n\n\n-- \nMatt McClure\nhttp://matthewlmcclure.com\nhttp://www.mapmyfitness.com/profile/matthewlmcclure\n"},{"id":"219374","messageId":"20130604155605.GA15953@sigill.intra.peff.net","threadId":"34025","inReplyTo":"CAJELnLEiK1C9PeimSwDoJoy=wFbFF0+KoK3jhXSAV4b2DsBKqw@mail.gmail.com","subject":"Re: Can `git blame` show the date that each line was merged?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-04T15:56:05Z","receivedAt":"2013-06-04T15:56:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 04, 2013 at 09:39:45AM -0400, Matt McClure wrote:\n\n> Can `git blame` show the date that each line was merged to the current\n> branch rather than the date it was committed?\n\nNot exactly. Git does not record when a commit entered a particular\nbranch (or what the \"ours\" branch was called during a merge).  If you\nfollow a topic branch workflow in which an integrator merges each branch\ninto master, then following the first parent of each merge will show the\ncommits directly on master.\n\nYou can see this in action in git.git, which follows such a workflow, by\ndoing \"git log --first-parent\", which shows only the commits created\ndirectly on master (mostly merges of topics, with a few trivial fixups\ninterspersed).\n\nSimilarly, you should be able to do \"git blame --first-parent foo.c\" to\npass blame only along the first-parent lines. Unfortunately, while\n\"blame\" uses the regular revision code to parse its options, it does its\nown traversal and does not respect each option. However, the patch to\nteach it about --first-parent is pretty trivial:\n\ndiff --git a/builtin/blame.c b/builtin/blame.c\nindex 57a487e..0fb67af 100644\n--- a/builtin/blame.c\n+++ b/builtin/blame.c\n@@ -1199,6 +1199,8 @@ static int num_scapegoats(struct rev_info *revs, struct commit *commit)\n {\n \tint cnt;\n \tstruct commit_list *l = first_scapegoat(revs, commit);\n+\tif (revs->first_parent_only)\n+\t\treturn l ? 1 : 0;\n \tfor (cnt = 0; l; l = l->next)\n \t\tcnt++;\n \treturn cnt;\n\n(though I suspect it would interact oddly with the \"--reverse\" option,\nand we would want to either declare them mutually exclusive or figure\nout some sane semantics).\n\n> Aside: in some trial and error I notice this oddity:\n> \n>     $ git blame --merges\n>     usage: git blame [options] [rev-opts] [rev] [--] file\n> \n>         [rev-opts] are documented in git-rev-list(1)\n>     ...\n\nYour problem is not the presence of \"--merges\" here, but that you forgot\nthe necessary \"file\" argument. Try \"git blame --merges foo.c\".\n\nHowever, this suffers from the same problem as --first-parent, in that\nit is accepted but not respected. Doing so would not be impossible, but\nit is a little more than the two-liner above.\n\n-Peff\n"},{"id":"219384","messageId":"CAJELnLFy_by_7qmEqAyaNxV128ASN5VYoewwftWEt3ege3++zA@mail.gmail.com","threadId":"34025","inReplyTo":"20130604155605.GA15953@sigill.intra.peff.net","subject":"Re: Can `git blame` show the date that each line was merged?","fromName":"Matt McClure","fromEmail":"matthewlmcclure@gmail.com","sentAt":"2013-06-04T17:26:59Z","receivedAt":"2013-06-04T17:26:59Z","isPatch":false,"sender":{"key":"matthewlmcclure@gmail.com","avatar":"https://gravatar.com/avatar/a8cde96b0594204c8d4c48baa51c983af37dedfa2b7a846e27547b8d63d46e7c?d=mp&s=160"},"body":"On Tue, Jun 4, 2013 at 11:56 AM, Jeff King <peff@peff.net> wrote:\n>> Aside: in some trial and error I notice this oddity:\n>>\n>>     $ git blame --merges\n>>     usage: git blame [options] [rev-opts] [rev] [--] file\n>>\n>>         [rev-opts] are documented in git-rev-list(1)\n>>     ...\n>\n> Your problem is not the presence of \"--merges\" here, but that you forgot\n> the necessary \"file\" argument. Try \"git blame --merges foo.c\".\n\nOops. Thanks.\n\n\n-- \nMatt McClure\nhttp://matthewlmcclure.com\nhttp://www.mapmyfitness.com/profile/matthewlmcclure\n"},{"id":"219385","messageId":"7vfvwx9461.fsf@alter.siamese.dyndns.org","threadId":"34025","inReplyTo":"20130604155605.GA15953@sigill.intra.peff.net","subject":"Re: Can `git blame` show the date that each line was merged?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-04T17:28:06Z","receivedAt":"2013-06-04T17:28:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> diff --git a/builtin/blame.c b/builtin/blame.c\n> index 57a487e..0fb67af 100644\n> --- a/builtin/blame.c\n> +++ b/builtin/blame.c\n> @@ -1199,6 +1199,8 @@ static int num_scapegoats(struct rev_info *revs, struct commit *commit)\n>  {\n>  \tint cnt;\n>  \tstruct commit_list *l = first_scapegoat(revs, commit);\n> +\tif (revs->first_parent_only)\n> +\t\treturn l ? 1 : 0;\n>  \tfor (cnt = 0; l; l = l->next)\n>  \t\tcnt++;\n>  \treturn cnt;\n>\n> (though I suspect it would interact oddly with the \"--reverse\" option,\n> and we would want to either declare them mutually exclusive or figure\n> out some sane semantics).\n\nIt is entirely unclear who the first child is, so I tend to think\nthat they have to be mutually exclusive.\n\n>> Aside: in some trial and error I notice this oddity:\n>> \n>>     $ git blame --merges\n>>     usage: git blame [options] [rev-opts] [rev] [--] file\n>> \n>>         [rev-opts] are documented in git-rev-list(1)\n>>     ...\n>\n> Your problem is not the presence of \"--merges\" here, but that you forgot\n> the necessary \"file\" argument. Try \"git blame --merges foo.c\".\n>\n> However, this suffers from the same problem as --first-parent, in that\n> it is accepted but not respected. Doing so would not be impossible, but\n> it is a little more than the two-liner above.\n\nWhat the command does when it \"respects\" it is unclear to me.\nIn a history like this:\n\n---A---B---C\n    \\       \\\n     E---F---G---H\n\nand starting at H, pretend everything that happened in, B, C, E and\nF since A was done by G?  Who gets the blame for what A or H did?\n"},{"id":"219389","messageId":"20130604174420.GA25318@sigill.intra.peff.net","threadId":"34025","inReplyTo":"7vfvwx9461.fsf@alter.siamese.dyndns.org","subject":"Re: Can `git blame` show the date that each line was merged?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-04T17:44:20Z","receivedAt":"2013-06-04T17:44:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 04, 2013 at 10:28:06AM -0700, Junio C Hamano wrote:\n\n> > (though I suspect it would interact oddly with the \"--reverse\" option,\n> > and we would want to either declare them mutually exclusive or figure\n> > out some sane semantics).\n> \n> It is entirely unclear who the first child is, so I tend to think\n> that they have to be mutually exclusive.\n\nThat's my thinking, too, but I didn't want to rule out somebody thinking\nof something clever.\n\n> > Your problem is not the presence of \"--merges\" here, but that you forgot\n> > the necessary \"file\" argument. Try \"git blame --merges foo.c\".\n> >\n> > However, this suffers from the same problem as --first-parent, in that\n> > it is accepted but not respected. Doing so would not be impossible, but\n> > it is a little more than the two-liner above.\n> \n> What the command does when it \"respects\" it is unclear to me.\n> In a history like this:\n> \n> ---A---B---C\n>     \\       \\\n>      E---F---G---H\n> \n> and starting at H, pretend everything that happened in, B, C, E and\n> F since A was done by G?  Who gets the blame for what A or H did?\n\nIn general, I would expect \"git blame\" with revision arguments to behave\nas if it was fed the history graph (including parent rewriting). So in\nthis case, I would think it would blame everything before G on G\n(assuming there are no merges before A), and everything in H would be\n\"not yet committed\".\n\nThat being said, we do not seem to rewrite parents for min/max parent\ncases even in \"git log\". I'm not sure why, nor can I seem to provoke it\nwith simplification options. So maybe I am missing something clever.\n\n-Peff\n"}]}