{"thread":{"id":"61276","subject":"Add Commit Summary in blame?","startedAt":"2024-04-05T23:08:11Z","lastAt":"2025-02-18T18:08:10Z","messageCount":4,"participants":["Aleks Todorov","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"492329","messageId":"CAO0eup=KqHe68OkHqYWtDgsTx0cAwg5Y5HSqK4s_BNbZhr8hVw@mail.gmail.com","threadId":"61276","inReplyTo":null,"subject":"Add Commit Summary in blame?","fromName":"Aleks Todorov","fromEmail":"aleks.todorov.1337@gmail.com","sentAt":"2024-04-05T23:07:58Z","receivedAt":"2024-04-05T23:08:11Z","isPatch":false,"sender":{"key":"aleks.todorov.1337@gmail.com","avatar":null},"body":"Hi folks,\n\nWould people be interested in seeing a patch that adds an option to\nsee the commit message summary line in the git blame output? I imagine\nI'm not the first person to come up with this, is there a reason why\nit wasn't already implemented? The porcelain already has it, so the\nchange is trivial.\n\nThanks\n"},{"id":"492338","messageId":"xmqqzfu7s5qg.fsf@gitster.g","threadId":"61276","inReplyTo":"CAO0eup=KqHe68OkHqYWtDgsTx0cAwg5Y5HSqK4s_BNbZhr8hVw@mail.gmail.com","subject":"Re: Add Commit Summary in blame?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-04-06T00:19:03Z","receivedAt":"2024-04-06T00:19:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aleks Todorov writes:\n\n> Would people be interested in seeing a patch that adds an option to\n> see the commit message summary line in the git blame output? I imagine\n> I'm not the first person to come up with this, is there a reason why\n> it wasn't already implemented? The porcelain already has it, so the\n> change is trivial.\n\nI personally do not. The blame output on the left-hand-side is\nalready wide enough to be even annoying.\n\nA patch that might interest me personally would be one that takes\nthe --format option (copy from the log family plus add some that are\nonly useful in \"git blame\", like \"line number\") to allow customizing\nthe left-hand-side of the output, and allows us to reimplement ugly\nhacks^W^W ad-hoc options (like -l, -t, --date, -f, -n, -s, -e) in\nterms of that. With such a feature, of course your \"commit summary\"\nwill come almost for free in the form of --format=%s I would think.\n\nA change that adds even more ad-hoc options is probably not welcome,\nI would have to say.\n\n\n"},{"id":"512493","messageId":"CAO0eup=6NcCdBASxvAxB8moku74zpxAr+MFiV-kkXVfjY1UF=w@mail.gmail.com","threadId":"61276","inReplyTo":"xmqqzfu7s5qg.fsf@gitster.g","subject":"Re: Add Commit Summary in blame?","fromName":"Aleks Todorov","fromEmail":"aleks.todorov.1337@gmail.com","sentAt":"2025-02-16T21:13:04Z","receivedAt":"2025-02-16T21:13:17Z","isPatch":false,"sender":{"key":"aleks.todorov.1337@gmail.com","avatar":null},"body":"I know it's been a while, but thank you for your reply! I was quite interested\nin this format option and have wanted to implement it since. I finally have\nsome free time.\n\nI've written a barebones implementation just to play around with the code and\nsee it work.\n\nBefore I continue, I wanted to know, should we re-implement the git log\nimplementation or refactor it to make it reusable? I lean into the latter,\nhowever if the implementation is shared, that means we need a way to sanitize\nuser input to ensure they are not using flags which are not allowed, and we\nwill also need to pollute the implementation with length specifiers everywhere\nsince each field in the blame output needs to be width-aligned.\n\nSo far, this is what I've been able to output:\n\n > ./git-blame builtin/blame.c -F '%h fname (%an %ad line) '\n\n d48be35ca6f fname (Elijah Newren Tue Mar 21 06:26:07 2023 +0000\nline) #include \"write-or-die.h\"\n cee7f245dca fname (Junio C Hamano Thu Oct 19 16:00:04 2006 -0700 line)\n ce41720cad7 fname (Alex Henrie Thu Apr 2 15:26:56 2015 -0600 line)\nstatic char blame_usage[] = N_(\"git blame [] []\n[] [--] \");\n df8738116f7 fname (Ævar Arnfjörð Bjarmason Thu Oct 13 17:39:20 2022\n+0200 line) static char annotate_usage[] = N_(\"git annotate\n[] [] [] [--] \");\n 5817da01434 fname (Pierre Habouzit Tue Jul 8 15:19:34 2008 +0200 line)\n 5817da01434 fname (Pierre Habouzit Tue Jul 8 15:19:34 2008 +0200\nline) static const char *blame_opt_usage[] = {\n 5817da01434 fname (Pierre Habouzit Tue Jul 8 15:19:34 2008 +0200\nline) blame_usage,\n 5817da01434 fname (Pierre Habouzit Tue Jul 8 15:19:34 2008 +0200 line) \"\",\n 9c9b4f2f8b7 fname (Alex Henrie Tue Jan 13 00:44:47 2015 -0700 line)\n N_(\" are documented in git-rev-list(1)\"),\n 5817da01434 fname (Pierre Habouzit Tue Jul 8 15:19:34 2008 +0200 line) NULL\n 5817da01434 fname (Pierre Habouzit Tue Jul 8 15:19:34 2008 +0200 line) };\n cee7f245dca fname (Junio C Hamano Thu Oct 19 16:00:04 2006 -0700 line)\n\nThis is the code I have, reusing the log impl (avoided formatting existing code\nfor brevity):\n\n diff --git a/builtin/blame.c b/builtin/blame.c\n index c470654c7e..7a7be7b36d 100644\n --- a/builtin/blame.c\n +++ b/builtin/blame.c\n @@ -66,6 +66,7 @@ static int xdl_opts;\n static int abbrev = -1;\n static int no_whole_file_rename;\n static int show_progress;\n +static char *user_format = NULL;\n static char repeated_meta_color[COLOR_MAXLEN];\n static int coloring_mode;\n static struct string_list ignore_revs_file_list = STRING_LIST_INIT_DUP;\n @@ -506,6 +507,17 @@ static void emit_other(struct blame_scoreboard\n*sb, struct blame_entry *ent, int\n putchar('?');\n }\n\n + if (user_format) {\n + struct strbuf sb = STRBUF_INIT;\n + struct pretty_print_context context = {\n + .fmt = CMIT_FMT_USERFORMAT,\n + .abbrev = abbrev,\n + };\n + repo_format_commit_message(the_repository,\n + suspect->commit,\nuser_format,\n + &sb, &context);\n + printf(\"%s\", sb.buf);\n + } else {\n printf(\"%.*s\", (int)(length < GIT_MAX_HEXSZ ? length\n: GIT_MAX_HEXSZ), hex);\n if (opt & OUTPUT_ANNOTATE_COMPAT) {\n const char *name;\n @@ -546,6 +558,7 @@ static void emit_other(struct blame_scoreboard\n*sb, struct blame_entry *ent, int\n printf(\" %*d) \",\n max_digits, ent->lno + 1 + cnt);\n }\n + }\n if (reset)\n fputs(reset, stdout);\n do {\n @@ -905,6 +918,7 @@ int cmd_blame(int argc,\n OPT_BIT('t', NULL, &output_option, N_(\"show raw\ntimestamp (Default: off)\"), OUTPUT_RAW_TIMESTAMP),\n OPT_BIT('l', NULL, &output_option, N_(\"show long\ncommit SHA1 (Default: off)\"), OUTPUT_LONG_OBJECT_NAME),\n OPT_BIT('s', NULL, &output_option, N_(\"suppress\nauthor name and timestamp (Default: off)\"), OUTPUT_NO_AUTHOR),\n + OPT_STRING('F', \"format\", &user_format,\nN_(\"format\"), N_(\"print blame entries in the given \")),\n OPT_BIT('e', \"show-email\", &output_option, N_(\"show\nauthor email instead of name (Default: off)\"), OUTPUT_SHOW_EMAIL),\n OPT_BIT('w', NULL, &xdl_opts, N_(\"ignore whitespace\ndifferences\"), XDF_IGNORE_WHITESPACE),\n OPT_STRING_LIST(0, \"ignore-rev\", &ignore_rev_list,\nN_(\"rev\"), N_(\"ignore when blaming\")),\n"},{"id":"512628","messageId":"xmqqfrkbxh14.fsf@gitster.g","threadId":"61276","inReplyTo":"CAO0eup=6NcCdBASxvAxB8moku74zpxAr+MFiV-kkXVfjY1UF=w@mail.gmail.com","subject":"Re: Add Commit Summary in blame?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-18T18:08:07Z","receivedAt":"2025-02-18T18:08:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aleks Todorov writes:\n\n> ...\n> however if the implementation is shared, that means we need a way to sanitize\n> user input to ensure they are not using flags which are not allowed, and we\n> will also need to pollute the implementation with length specifiers everywhere\n> since each field in the blame output needs to be width-aligned.\n\nI was imagining that the aligning is responsibility of the end-users\nwho give whatever random format strings to the command, if you are\nto reuse the existing helper functions out of the implementation of\nthe \"git log\" family of commands, as % and its friends would be\navailable for free. I admit that it has been forever since I looked\nat the code paths that implement wrapping and padding specifiers\nlast time, and I do not know offhand how cleanly they are written\nand how reusable they are, though.\n\nIf you are doing this to feed some GUI implementation, however, I\nsuspect that a more productive way would be to make the GUI tool\nread from the \"--incremental\" format. But as I do not know your\nmotivation...\n\n"}]}