{"thread":{"id":"48001","subject":"[PATCH] Support long format for log-based submodule diff","startedAt":"2018-03-07T21:11:49Z","lastAt":"2018-04-02T19:35:50Z","messageCount":7,"participants":["Robert Dailey","Junio C Hamano","Stefan Beller"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"341231","messageId":"20180307211140.19272-1-rcdailey@gmail.com","threadId":"48001","inReplyTo":null,"subject":"[PATCH] Support long format for log-based submodule diff","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2018-03-07T21:11:40Z","receivedAt":"2018-03-07T21:11:49Z","isPatch":true,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"I am experimenting with a version of submodule diff (using log style)\nthat prints the commits brought in from merges, while excluding the\nmerge commits themselves. This is useful in cases where a merge commit's\nsummary does not fully explain the changes being merged (for example,\nfor longer-lived branches).\n\nI could have gone through the effort to make this more configurable, but\nbefore doing that level of work I wanted to get some discussion going to\nunderstand first if this is a useful change and second how it should be\nconfigured. For example, we could allow:\n\n$ git diff --submodule=long-log\n\nOr a supplementary option such as:\n\n$ git diff --submodule=log --submodule-log-detail=(long|short)\n\nI'm not sure what makes sense here. I welcome thoughts/discussion and\nwill provide follow-up patches.\n\nSigned-off-by: Robert Dailey <rcdailey@gmail.com>\n---\n submodule.c | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/submodule.c b/submodule.c\nindex 2967704317..a0a62ad7bd 100644\n--- a/submodule.c\n+++ b/submodule.c\n@@ -428,7 +428,8 @@ static int prepare_submodule_summary(struct rev_info *rev, const char *path,\n \tinit_revisions(rev, NULL);\n \tsetup_revisions(0, NULL, rev, NULL);\n \trev->left_right = 1;\n-\trev->first_parent_only = 1;\n+\trev->max_parents = 1;\n+\trev->first_parent_only = 0;\n \tleft->object.flags |= SYMMETRIC_LEFT;\n \tadd_pending_object(rev, &left->object, path);\n \tadd_pending_object(rev, &right->object, path);\n-- \n2.13.1.windows.2\n\n"},{"id":"341232","messageId":"xmqqefkvzhqq.fsf@gitster-ct.c.googlers.com","threadId":"48001","inReplyTo":"20180307211140.19272-1-rcdailey@gmail.com","subject":"Re: [PATCH] Support long format for log-based submodule diff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-07T21:41:01Z","receivedAt":"2018-03-07T21:41:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Dailey <rcdailey.lists@gmail.com> writes:\n\n> I could have gone through the effort to make this more configurable, but\n> before doing that level of work I wanted to get some discussion going to\n> understand first if this is a useful change and second how it should be\n> configured. For example, we could allow:\n>\n> $ git diff --submodule=long-log\n>\n> Or a supplementary option such as:\n>\n> $ git diff --submodule=log --submodule-log-detail=(long|short)\n>\n> I'm not sure what makes sense here. I welcome thoughts/discussion and\n> will provide follow-up patches.\n\nMy quick looking around reveals that prepare_submodule_summary() is\ncalled only by show_submodule_summary(), which in turn is called\nonly from builtin_diff() in a codepath like this:\n\n\tif (o->submodule_format == DIFF_SUBMODULE_LOG &&\n\t    (!one->mode || S_ISGITLINK(one->mode)) &&\n\t    (!two->mode || S_ISGITLINK(two->mode))) {\n\t\tshow_submodule_summary(o, one->path ? one->path : two->path,\n\t\t\t\t&one->oid, &two->oid,\n\t\t\t\ttwo->dirty_submodule);\n\t\treturn;\n\t} else if (o->submodule_format == DIFF_SUBMODULE_INLINE_DIFF &&\n\t\t   (!one->mode || S_ISGITLINK(one->mode)) &&\n\t\t   (!two->mode || S_ISGITLINK(two->mode))) {\n\t\tshow_submodule_inline_diff(o, one->path ? one->path : two->path,\n\t\t\t\t&one->oid, &two->oid,\n\t\t\t\ttwo->dirty_submodule);\n\t\treturn;\n\t}\n\nIt looks like introducing a new value to o->submodule_format (enum\ndiff_submodule_format defined in diff.h) would be one natural way to\nextend this codepath, at least to me from a quick glance.\n\nIt also looks to me that the above may become far easier to read if\nthe common \"are we dealing with a filepair <one, two> that involves\nsubmodules?\" check in the above if/else if cascade is factored out,\nperhaps like this as a preliminary clean-up step, before adding a\nnew value:\n\n\tif ((!one->mode || S_ISGITLINK(one->mode)) &&\n\t    (!two->mode || S_ISGITLINK(two->mode))) {\n\t\tswitch (o->submodule_format) {\n\t\tcase DIFF_SUBMODULE_LOG:\n\t\t\t... do the \"log\" thing ...\n\t\t\treturn;\n\t\tcase DIFF_SUBMODULE_INLINE_DIFF:\n\t\t\t... do the \"inline\" thing ...\n\t\t\treturn;\n\t\tdefault:\n\t\t\tbreak;\n\t\t}\n\t}\n\nThen the place to add a new format would be trivially obvious,\ni.e. just add a new case arm to call a new function to give the\nsummary.\n"},{"id":"341332","messageId":"CAGZ79kZk7N4zQUS1eMFMPTuPPuo5ViOeLj5hQHV=E+A=OO+D0w@mail.gmail.com","threadId":"48001","inReplyTo":"20180307211140.19272-1-rcdailey@gmail.com","subject":"Re: [PATCH] Support long format for log-based submodule diff","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-03-09T08:53:22Z","receivedAt":"2018-03-09T08:53:29Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Mar 7, 2018 at 1:11 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:\n> I am experimenting with a version of submodule diff (using log style)\n> that prints the commits brought in from merges, while excluding the\n> merge commits themselves. This is useful in cases where a merge commit's\n> summary does not fully explain the changes being merged (for example,\n> for longer-lived branches).\n>\n> I could have gone through the effort to make this more configurable, but\n> before doing that level of work I wanted to get some discussion going to\n> understand first if this is a useful change and second how it should be\n> configured. For example, we could allow:\n>\n> $ git diff --submodule=long-log\n>\n> Or a supplementary option such as:\n>\n> $ git diff --submodule=log --submodule-log-detail=(long|short)\n>\n> I'm not sure what makes sense here. I welcome thoughts/discussion and\n> will provide follow-up patches.\n\nThe case of merges is usually configured with --[no-]merges, or\n--min-parents=<n>.\n\nI would think we would want to have different settings per repository,\ni.e. these settings would only apply to the superproject, however\nwe could keep the same names for submodules, such that we could do\n\n    git log --min-parents=0 --submodules=--no-merges\n\nWe started an effort to have a repository object handle in most functions\nsome time ago, but the option parsing for the revision walking doesn't\ntake a repository yet, otherwise the generic revision parsing for submodules\nwould be easy to implement.\n\nThoughts on this generic approach?\nStefan\n\n>\n> Signed-off-by: Robert Dailey <rcdailey@gmail.com>\n> ---\n>  submodule.c | 3 ++-\n>  1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/submodule.c b/submodule.c\n> index 2967704317..a0a62ad7bd 100644\n> --- a/submodule.c\n> +++ b/submodule.c\n> @@ -428,7 +428,8 @@ static int prepare_submodule_summary(struct rev_info *rev, const char *path,\n>         init_revisions(rev, NULL);\n>         setup_revisions(0, NULL, rev, NULL);\n>         rev->left_right = 1;\n> -       rev->first_parent_only = 1;\n> +       rev->max_parents = 1;\n> +       rev->first_parent_only = 0;\n>         left->object.flags |= SYMMETRIC_LEFT;\n>         add_pending_object(rev, &left->object, path);\n>         add_pending_object(rev, &right->object, path);\n> --\n> 2.13.1.windows.2\n>\n"},{"id":"341361","messageId":"xmqqina56t8h.fsf@gitster-ct.c.googlers.com","threadId":"48001","inReplyTo":"CAGZ79kZk7N4zQUS1eMFMPTuPPuo5ViOeLj5hQHV=E+A=OO+D0w@mail.gmail.com","subject":"Re: [PATCH] Support long format for log-based submodule diff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-09T17:42:22Z","receivedAt":"2018-03-09T17:42:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <sbeller@google.com> writes:\n\n>> $ git diff --submodule=log --submodule-log-detail=(long|short)\n>>\n>> I'm not sure what makes sense here. I welcome thoughts/discussion and\n>> will provide follow-up patches.\n>\n> The case of merges is usually configured with --[no-]merges, or\n> --min-parents=<n>.\n\nBut that is a knob that controls an irrelevant aspect of the detail\nin the context of this discussion, isn't it?  This code is about \"to\nwhat degree the things that happened between two submodule commits\nin an adjacent pair of commits in the superproject are summarized?\"\nand the current one unilaterally decides that something similar to\nwhat you would see in the output from \"log --oneline --first-parent\n--left-right\" is sufficient, which is a position to heavily favour\nprojects whose histories are very clean by either being:\n\n (1) totally linear, each individual commit appearing on the\n     first-parent chain; or\n\n (2) totally topic-branch based, everything appearing as merges of\n     a topic branch to the trunk\n\nThe hack Robert illustrates below is to change it to stop favouring\nsuch projects with \"clean\" histories, and show \"log --oneline\n--no-merges --left-right\".  When presented that way, clean histories\nof topic-branch based projects will suffer by losing conciseness,\nbut clean histories of totally linear projects will still be shown\nthe same way, and messy history that sometimes merges, sometimes\nmerges mergy histories, and sometimes directly builds on the trunk\nwill be shown as an enumeration of individual commits in a flat way\nby ignoring merges and not restricting the traversal to the first\nparent chains, which would appear more uniform than what the current\ncode shows.\n\nI do not see a point in introducing --min/max-parents as a knob to\ncontrol how the history is summarized.\n\nThis is a strongly related tangent, but I wonder if we can and/or\nwant to share more code with the codepath that prepares the log\nmessage for a merge.  It summarizes what happened on the side branch\nsince it forked from the history it is joining back to (I think it\nis merge.c::shortlog() that computes this) and it is quite similar\nto what Robert wants to use for submodules here.  On the other hand,\nin a project _without_ submodule, if you are pulling history made by\nyour lieutenant whose history is full of linear merges of topic\nbranches to the mainline, it may not be a bad idea to allow\nfmt-merge-msg to alternatively show something similar to the \"diff\n--submodule=log\" gives us, i.e. summarize the history of the side\nbranch being merged by just listing the commits on the first-parent\nchain.  So I sense some opportunity for cross pollination here.\n"},{"id":"343180","messageId":"CAGZ79kZ_j3_mhk5asNEBgBe_2qD7=18foJgW=p0+p=uJa3U2nw@mail.gmail.com","threadId":"48001","inReplyTo":"xmqqina56t8h.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] Support long format for log-based submodule diff","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-03-27T22:17:57Z","receivedAt":"2018-03-27T22:18:15Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> >> $ git diff --submodule=log --submodule-log-detail=(long|short)\n> >>\n> >> I'm not sure what makes sense here. I welcome thoughts/discussion and\n> >> will provide follow-up patches.\n> >\n> > The case of merges is usually configured with --[no-]merges, or\n> > --min-parents=<n>.\n\n> But that is a knob that controls an irrelevant aspect of the detail\n> in the context of this discussion, isn't it?  This code is about \"to\n> what degree the things that happened between two submodule commits\n> in an adjacent pair of commits in the superproject are summarized?\"\n\nAnd I took it a step further and wanted to give a general solution, which\nallows giving any option that the diff machinery accepts to only apply\nto the submodule diffing part of the current diff.\n\n> The hack Robert illustrates below is to change it to stop favouring\n> such projects with \"clean\" histories, and show \"log --oneline\n> --no-merges --left-right\".  When presented that way, clean histories\n> of topic-branch based projects will suffer by losing conciseness,\n> but clean histories of totally linear projects will still be shown\n> the same way, and messy history that sometimes merges, sometimes\n> merges mergy histories, and sometimes directly builds on the trunk\n> will be shown as an enumeration of individual commits in a flat way\n> by ignoring merges and not restricting the traversal to the first\n> parent chains, which would appear more uniform than what the current\n> code shows.\n\nOh, I realize this is in the *summary* code path, I was thinking about the\nshow_submodule_inline_diff, which would benefit from more diff options.\n\n> I do not see a point in introducing --min/max-parents as a knob to\n> control how the history is summarized.\n\nFor a summary a flat list of commits may be fine, ignoring\n(ideally non-evil) merges.\n\n> This is a strongly related tangent, but I wonder if we can and/or\n> want to share more code with the codepath that prepares the log\n> message for a merge.  It summarizes what happened on the side branch\n> since it forked from the history it is joining back to (I think it\n> is merge.c::shortlog() that computes this)\n\nI do not find code there. To me it looks like builtin/fmt-merge-msg.c\nis responsible for coming up with a default merge message?\nIn that file there is a shortlog() function, which walks revisions\nand puts together the subject lines of commits.\n\n> and it is quite similar\n> to what Robert wants to use for submodules here.  On the other hand,\n> in a project _without_ submodule, if you are pulling history made by\n> your lieutenant whose history is full of linear merges of topic\n> branches to the mainline, it may not be a bad idea to allow\n> fmt-merge-msg to alternatively show something similar to the \"diff\n> --submodule=log\" gives us, i.e. summarize the history of the side\n> branch being merged by just listing the commits on the first-parent\n> chain.  So I sense some opportunity for cross pollination here.\n\nThe cross pollination that I sense is the desire in both cases to freely\nspecify the format as it may depend on the workflow.\n\nStefan\n"},{"id":"343563","messageId":"CAHd499AraFfWY-L9+RFj2E=p58QK0njyS8dQHEOGHjeoTW=YQw@mail.gmail.com","threadId":"48001","inReplyTo":"CAGZ79kZ_j3_mhk5asNEBgBe_2qD7=18foJgW=p0+p=uJa3U2nw@mail.gmail.com","subject":"Re: [PATCH] Support long format for log-based submodule diff","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2018-04-02T01:07:43Z","receivedAt":"2018-04-02T01:08:28Z","isPatch":true,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller <sbeller@google.com> wrote:\n>> >> $ git diff --submodule=log --submodule-log-detail=(long|short)\n>> >>\n>> >> I'm not sure what makes sense here. I welcome thoughts/discussion and\n>> >> will provide follow-up patches.\n>> >\n>> > The case of merges is usually configured with --[no-]merges, or\n>> > --min-parents=<n>.\n>\n>> But that is a knob that controls an irrelevant aspect of the detail\n>> in the context of this discussion, isn't it?  This code is about \"to\n>> what degree the things that happened between two submodule commits\n>> in an adjacent pair of commits in the superproject are summarized?\"\n>\n> And I took it a step further and wanted to give a general solution, which\n> allows giving any option that the diff machinery accepts to only apply\n> to the submodule diffing part of the current diff.\n>\n>> The hack Robert illustrates below is to change it to stop favouring\n>> such projects with \"clean\" histories, and show \"log --oneline\n>> --no-merges --left-right\".  When presented that way, clean histories\n>> of topic-branch based projects will suffer by losing conciseness,\n>> but clean histories of totally linear projects will still be shown\n>> the same way, and messy history that sometimes merges, sometimes\n>> merges mergy histories, and sometimes directly builds on the trunk\n>> will be shown as an enumeration of individual commits in a flat way\n>> by ignoring merges and not restricting the traversal to the first\n>> parent chains, which would appear more uniform than what the current\n>> code shows.\n>\n> Oh, I realize this is in the *summary* code path, I was thinking about the\n> show_submodule_inline_diff, which would benefit from more diff options.\n>\n>> I do not see a point in introducing --min/max-parents as a knob to\n>> control how the history is summarized.\n>\n> For a summary a flat list of commits may be fine, ignoring\n> (ideally non-evil) merges.\n>\n>> This is a strongly related tangent, but I wonder if we can and/or\n>> want to share more code with the codepath that prepares the log\n>> message for a merge.  It summarizes what happened on the side branch\n>> since it forked from the history it is joining back to (I think it\n>> is merge.c::shortlog() that computes this)\n>\n> I do not find code there. To me it looks like builtin/fmt-merge-msg.c\n> is responsible for coming up with a default merge message?\n> In that file there is a shortlog() function, which walks revisions\n> and puts together the subject lines of commits.\n>\n>> and it is quite similar\n>> to what Robert wants to use for submodules here.  On the other hand,\n>> in a project _without_ submodule, if you are pulling history made by\n>> your lieutenant whose history is full of linear merges of topic\n>> branches to the mainline, it may not be a bad idea to allow\n>> fmt-merge-msg to alternatively show something similar to the \"diff\n>> --submodule=log\" gives us, i.e. summarize the history of the side\n>> branch being merged by just listing the commits on the first-parent\n>> chain.  So I sense some opportunity for cross pollination here.\n>\n> The cross pollination that I sense is the desire in both cases to freely\n> specify the format as it may depend on the workflow.\n\nFirst I want to apologize for having taken so long to get back with\neach of you about this. I actually have a lot of work started to\nexpand the --submodule option to add a \"full-log\" option in addition\nto the existing \"log\". This is a pretty big task for me already,\nmostly because I'm unfamiliar with git and have limited personal time\nto do this at home (this is part of what I am apologizing for). I kind\nof get what Stefan and Junio are saying. There's a lot of opportunity\nfor cleanup. More specific to my use case, adding some functionality\nto generate a log message (although I've developed a bash script to do\nthis since I wrote my original email. I'll attach it to this email for\nthose interested). Also I get that taking this a notch higher and\nadding a new option to pass options down to submodules also addresses\nmy case. Before I waste anyone's time on this, I want to make sure\nthat my very narrow and specific implementation will be ideal. By all\nmeans I do not want to do things the easy way which ends up adding\n\"cruft\" you'll have to deal with later. If there's a larger effort to\ngeneralize this and other things related to submodules maybe I can\njust wait for that to happen instead? What direction would you guys\nrecommend?\n\nJunio basically hit the nail on the head with the comparisons of\ndifferent mainlines. I think some repositories are more disciplined\nthan others. At my workplace, I deal with a lot of folks that aren't\ninterested in learning git beyond the required day to day\nresponsibilities. It's difficult to enforce very specific branching,\nrebase, and merge habits. As such, the best I can do to work around\nthat for building release notes is to exclude merge commits (since\nmost of the time, people keep the default message which is generally\nuseless) and include all commits in the ancestry path (since often\ntimes commits on the right side of a merge will have important\ninformation such as JIRA issue keys, which if shown in the parent repo\nwill cause appropriate links back to parent repositories to show when\nchanges in submodules were introduced there as well).\n\nBased on how constructive this email thread has gotten since I started\nit, I'm starting to feel like my solution is too narrowly-focused and\ndoesn't have the long term appeal expected. Let me know, I'm happy to\ndo what I can but I think it will be limited due to my lack of domain\nexpertise in the code base and inability to invest the required time\nfor significant scope of work.\n"},{"id":"343599","messageId":"CAGZ79kb6Ot_Lso+_K6VXcLsT=1hv0JaXXF8j3PpH+2FHQ-8QpA@mail.gmail.com","threadId":"48001","inReplyTo":"CAHd499AraFfWY-L9+RFj2E=p58QK0njyS8dQHEOGHjeoTW=YQw@mail.gmail.com","subject":"Re: [PATCH] Support long format for log-based submodule diff","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-04-02T19:35:44Z","receivedAt":"2018-04-02T19:35:50Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Sun, Apr 1, 2018 at 6:07 PM, Robert Dailey <rcdailey.lists@gmail.com> wrote:\n> On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller <sbeller@google.com> wrote:\n>>> >> $ git diff --submodule=log --submodule-log-detail=(long|short)\n>>> >>\n>>> >> I'm not sure what makes sense here. I welcome thoughts/discussion and\n>>> >> will provide follow-up patches.\n>>> >\n>>> > The case of merges is usually configured with --[no-]merges, or\n>>> > --min-parents=<n>.\n>>\n>>> But that is a knob that controls an irrelevant aspect of the detail\n>>> in the context of this discussion, isn't it?  This code is about \"to\n>>> what degree the things that happened between two submodule commits\n>>> in an adjacent pair of commits in the superproject are summarized?\"\n>>\n>> And I took it a step further and wanted to give a general solution, which\n>> allows giving any option that the diff machinery accepts to only apply\n>> to the submodule diffing part of the current diff.\n>>\n>>> The hack Robert illustrates below is to change it to stop favouring\n>>> such projects with \"clean\" histories, and show \"log --oneline\n>>> --no-merges --left-right\".  When presented that way, clean histories\n>>> of topic-branch based projects will suffer by losing conciseness,\n>>> but clean histories of totally linear projects will still be shown\n>>> the same way, and messy history that sometimes merges, sometimes\n>>> merges mergy histories, and sometimes directly builds on the trunk\n>>> will be shown as an enumeration of individual commits in a flat way\n>>> by ignoring merges and not restricting the traversal to the first\n>>> parent chains, which would appear more uniform than what the current\n>>> code shows.\n>>\n>> Oh, I realize this is in the *summary* code path, I was thinking about the\n>> show_submodule_inline_diff, which would benefit from more diff options.\n>>\n>>> I do not see a point in introducing --min/max-parents as a knob to\n>>> control how the history is summarized.\n>>\n>> For a summary a flat list of commits may be fine, ignoring\n>> (ideally non-evil) merges.\n>>\n>>> This is a strongly related tangent, but I wonder if we can and/or\n>>> want to share more code with the codepath that prepares the log\n>>> message for a merge.  It summarizes what happened on the side branch\n>>> since it forked from the history it is joining back to (I think it\n>>> is merge.c::shortlog() that computes this)\n>>\n>> I do not find code there. To me it looks like builtin/fmt-merge-msg.c\n>> is responsible for coming up with a default merge message?\n>> In that file there is a shortlog() function, which walks revisions\n>> and puts together the subject lines of commits.\n>>\n>>> and it is quite similar\n>>> to what Robert wants to use for submodules here.  On the other hand,\n>>> in a project _without_ submodule, if you are pulling history made by\n>>> your lieutenant whose history is full of linear merges of topic\n>>> branches to the mainline, it may not be a bad idea to allow\n>>> fmt-merge-msg to alternatively show something similar to the \"diff\n>>> --submodule=log\" gives us, i.e. summarize the history of the side\n>>> branch being merged by just listing the commits on the first-parent\n>>> chain.  So I sense some opportunity for cross pollination here.\n>>\n>> The cross pollination that I sense is the desire in both cases to freely\n>> specify the format as it may depend on the workflow.\n>\n> First I want to apologize for having taken so long to get back with\n> each of you about this. I actually have a lot of work started to\n> expand the --submodule option to add a \"full-log\" option in addition\n> to the existing \"log\". This is a pretty big task for me already,\n> mostly because I'm unfamiliar with git and have limited personal time\n> to do this at home (this is part of what I am apologizing for).\n\nNo worries wrt. time.\n\n> I kind\n> of get what Stefan and Junio are saying. There's a lot of opportunity\n> for cleanup. More specific to my use case, adding some functionality\n> to generate a log message (although I've developed a bash script to do\n> this since I wrote my original email. I'll attach it to this email for\n> those interested).\n\nThe functionality looks very similar what Gerrit does in its\n\"superproject subscription mode\", which would update the submodules in\nthe superproject automatically, when you submit on the submodule.\nFor example [1] is an update of the Gerrit project itself, that has some\nsubmodules. This commit only updates the replication plugin, but\nprovides a summary what happened in that plugin.\n\n[1] https://gerrit.googlesource.com/gerrit/+/db20af7123221b0b2f01d1f06e4eaac32a04cef6\n\n\nI wonder if there is need for this in upstream git as well, e.g.\n\"git submodule update --remote\" would also want to have a\nswitch \"--commit-with-proposed-commit-message\" or if the\nstandard commit message template would provide a submodule\nsummary for you. I realize that there is the config option\nstatus.submoduleSummary already, but it is not as clear as either\nyour script or the Gerrit example.\n\n> Also I get that taking this a notch higher and\n> adding a new option to pass options down to submodules also addresses\n> my case. Before I waste anyone's time on this, I want to make sure\n> that my very narrow and specific implementation will be ideal. By all\n> means I do not want to do things the easy way which ends up adding\n> \"cruft\" you'll have to deal with later.\n\nSounds good. I am undecided whether to count this as cruft, as it brings in\nreal improvements for certain histories. And if you need this, it is not cruft\nbut a feature.\n\n> If there's a larger effort to\n> generalize this and other things related to submodules maybe I can\n> just wait for that to happen instead? What direction would you guys\n> recommend?\n\nYou could do that, though there are no timelines and you'd wait quite a\nlong time, potentially.\n\n> Junio basically hit the nail on the head with the comparisons of\n> different mainlines. I think some repositories are more disciplined\n> than others. At my workplace, I deal with a lot of folks that aren't\n> interested in learning git beyond the required day to day\n> responsibilities. It's difficult to enforce very specific branching,\n> rebase, and merge habits. As such, the best I can do to work around\n> that for building release notes is to exclude merge commits (since\n> most of the time, people keep the default message which is generally\n> useless) and include all commits in the ancestry path (since often\n> times commits on the right side of a merge will have important\n> information such as JIRA issue keys, which if shown in the parent repo\n> will cause appropriate links back to parent repositories to show when\n> changes in submodules were introduced there as well).\n\nIt sounds it is fixing a real need, so don't call it cruft. ;)\n\n> Based on how constructive this email thread has gotten since I started\n> it, I'm starting to feel like my solution is too narrowly-focused and\n> doesn't have the long term appeal expected. Let me know, I'm happy to\n> do what I can but I think it will be limited due to my lack of domain\n> expertise in the code base and inability to invest the required time\n> for significant scope of work.\n\nI guess we can have it as\n\n  $ git diff --submodule=long-log\n\nfor now? Or instead \"detailed-log\" or \"log-with-commits\" ?\n\nThanks,\nStefan\n"}]}