{"thread":{"id":"10788","subject":"[PATCH] status&commit: Teach them to show commits of modified submodules.","startedAt":"2007-11-10T19:27:43Z","lastAt":"2007-11-12T22:39:16Z","messageCount":16,"participants":["Ping Yin","Sven Verdoolaege","Junio C Hamano","Lars Hjemli","Yin Ping","Johannes Sixt","Johan Herland","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"59235","messageId":"1194722863-14741-1-git-send-email-pkufranky@gmail.com","threadId":"10788","inReplyTo":null,"subject":"[PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2007-11-10T19:27:43Z","receivedAt":"2007-11-10T19:27:43Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"git status/commit just treats submodules as ordinary files when reporting status\nchanges. However, one may also wonder how submodules change (the commits).\n\nThis commit teaches git status/commit to also show commits of user-cared\nmodified submodules since HEAD (or HEAD^ if --amend option is on).\nNotes:\n\t1. Submodules already checked out are considered to be user-cared ones.\n\t2. For submodules deleted or initially added, commits are not shown.\n\nFor example, when commiting, submodule sm1 and sm2 are both changed. sm1 has\ncommit C in HEAD and commit E in index. The history of sm1 is\n\t--A-->B-->C (in HEAD:354cd45)\n\t \\\n\t -->D->E (in index:3f751e5)\n\ngit status will give the following output (just output commits of submodules\nbefore the original output) to show how to change from commit C (in HEAD) to\ncommit E (in index) for submodule sm1: backward ('<<<') to commit A, and then\nforward ('>>>') to commit E. Similar illustration for output of sm2 is omitted.\n\n\t#\n\t# submodule modifiled: sm1 sm2\n\t#\n\t# * sm1 354cd45...3f751e5:\n\t# <<<\n\t# \tone line message for C\n\t# \tone line message for B\n\t# >>>\n\t# \tone line message for D\n\t# \tone line message for E\n\t#\n\t# * sm2 5c8bfb5...ac46d84:\n\t# <<<\n\t# \tmsg\n\t#\n\t# On branch master\n\t# Changes to be committed:\n\t# (use \"git reset HEAD ...\" to unstage)\n\t#\n\t#\tmodified: sm1\n\t#\tmodified: sm2\n\nFor sm1, if the commit recorded in HEAD/index (say commit C/E) is not found in\nthe work tree (say sm1 respository in the work tree), a warning will be issued.\n\n\t#\n\t# submodule modifiled: sm1\n\t#\n\t# * sm1 354cd45...3f751e5:\n\t# Warn: sm1 doesn't contains commit 354cd45\n\t#\n\t# On branch master\n\t# Changes to be committed:\n\t# (use \"git reset HEAD ...\" to unstage)\n\t#\n\t#\tmodified: sm1\n\nSigned-off-by: Ping Yin \n---\n git-commit.sh | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 68 insertions(+), 0 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex fcb8443..29f2ebe 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -33,6 +33,68 @@ save_index () {\n \tcp -p \"$THIS_INDEX\" \"$NEXT_INDEX\"\n }\n \n+# Show log of modified submodule (index modification since HEAD or $1)\n+# $1 is the commit to be compared, default 'HEAD'\n+show_module_log () {\n+\tcwd=$(pwd)\n+\tcd_to_toplevel \n+\n+\t# get modified modules which have been checked out (i.e. cared by user)\n+\tmodules=$(git diff --cached --name-only $1 |\n+\t(\n+\t\tIFS=''\t# handle the module name containing space or tab\n+\t\twhile read name\n+\t\tdo\n+\t\t\tgit ls-files --stage \"$name\" | grep '^160000 ' >&/dev/null &&\n+\t\t\tGIT_DIR=\"$name/.git\" git-rev-parse --git-dir >&/dev/null &&\n+\t\t\techo \"$name\"\n+\t\tdone\n+\t)\n+\t)\n+\n+\t# TODO: quote module names containing space or tab\n+\ttest -n \"$modules\" && echo -e \"#\\n# submodule modifiled: \"$modules\"\\n#\"\n+\tOLDIFS=$IFS\n+\tIFS=$'\\n\\r'\t# '\\r' for mac os \n+\tfor name in $modules\n+\tdo\n+\t\trange=$(git diff --cached -- \"$name\" | sed -n '/^index.*160000$/ p' | awk '{print $2}')\n+\t\tindexone=${range#*..}\n+\t\theadone=${range%..*}\n+\t\t(\n+\t\t\techo \"* $name $headone...$indexone:\"\n+\t\t\theadfail=\n+\t\t\tindexfail=\n+\t\t\tGIT_DIR=\"$name/.git\" git-rev-parse $headone >&/dev/null || headfail='t'\n+\t\t\tGIT_DIR=\"$name/.git\" git-rev-parse $indexone >&/dev/null || indexfail='t'\n+\t\t\tcase \"$headfail,$indexfail\" in\n+\t\t\tt,)\n+\t\t\t\techo \" Warn: $name dosn't contains commit $headone\"\n+\t\t\t\t;;\n+\t\t\t,t)\n+\t\t\t\techo \" Warn: $name dosn't contains commit $indexone\"\n+\t\t\t\t;;\n+\t\t\tt,t)\n+\t\t\t\techo \" Warn: $name dosn't contains commits $headone and $indexone\"\n+\t\t\t\t;;\n+\t\t\t*)\n+\t\t\t\tleft=$(GIT_DIR=\"$name/.git\" git log --pretty=oneline $indexone..$headone 2>&1 |\n+\t\t\t\tsed 's/^\\w\\+ / \\t/')\n+\t\t\t\tright=$(GIT_DIR=\"$name/.git\" git log --pretty=oneline --reverse $headone..$indexone 2>&1 |\n+\t\t\t\tsed 's/^\\w\\+ / \\t/')\n+\n+\t\t\t\ttest -n \"$left\" && echo -e \" <<<\\n$left\"\n+\t\t\t\ttest -n \"$right\" && echo -e \" >>>\\n$right\"\n+\t\t\t\t;;\n+\t\t\tesac\n+\t\t\techo\n+\t\t) | sed 's/^/# /'\n+\tdone\n+\tIFS=$OLDIFS\n+\n+\tcd \"$cwd\"\n+}\n+\n run_status () {\n \t# If TMP_INDEX is defined, that means we are doing\n \t# \"--only\" partial commit, and that index file is used\n@@ -55,6 +117,12 @@ run_status () {\n \telse\n \t\tcolor=--nocolor\n \tfi\n+\tif test -z \"$amend\"\n+\tthen\n+\t\tshow_module_log\n+\telse\n+\t\tshow_module_log \"HEAD^\"\n+\tfi\n \tgit runstatus ${color} \\\n \t\t${verbose:+--verbose} \\\n \t\t${amend:+--amend} \\\n-- \n1.5.3.4\n"},{"id":"59236","messageId":"20071110195509.GI2261MdfPADPa@greensroom.kotnet.org","threadId":"10788","inReplyTo":"1194722863-14741-1-git-send-email-pkufranky@gmail.com","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-11-10T19:55:09Z","receivedAt":"2007-11-10T19:55:09Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Sun, Nov 11, 2007 at 03:27:43AM +0800, Ping Yin wrote:\n> This commit teaches git status/commit to also show commits of user-cared\n\nDoes it? It looks like you only changed git-commit.\nShouldn't this be put in wt_status_print, if anywhere?\n\nAlso, you have some typos:\n\n> +\ttest -n \"$modules\" && echo -e \"#\\n# submodule modifiled: \"$modules\"\\n#\"\n[..]\n> +\t\t\t\techo \" Warn: $name dosn't contains commit $headone\"\n\nskimo\n"},{"id":"59237","messageId":"20071110200038.GJ2261MdfPADPa@greensroom.kotnet.org","threadId":"10788","inReplyTo":"20071110195509.GI2261MdfPADPa@greensroom.kotnet.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2007-11-10T20:00:38Z","receivedAt":"2007-11-10T20:00:38Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Sat, Nov 10, 2007 at 08:55:09PM +0100, Sven Verdoolaege wrote:\n> On Sun, Nov 11, 2007 at 03:27:43AM +0800, Ping Yin wrote:\n> > This commit teaches git status/commit to also show commits of user-cared\n> \n> Does it? It looks like you only changed git-commit.\n\nOK. Never mind about this one.\n\nskimo\n"},{"id":"59242","messageId":"7vabpliz13.fsf@gitster.siamese.dyndns.org","threadId":"10788","inReplyTo":"1194722863-14741-1-git-send-email-pkufranky@gmail.com","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-10T21:14:16Z","receivedAt":"2007-11-10T21:14:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ping Yin writes:\n\n> \t# submodule modifiled: sm1 sm2\n> \t#\n> \t# * sm1 354cd45...3f751e5:\n> \t# <<<\n> \t# \tone line message for C\n> \t# \tone line message for B\n> \t# >>>\n> \t# \tone line message for D\n> \t# \tone line message for E\n> \t#\n> \t# * sm2 5c8bfb5...ac46d84:\n> \t# <<<\n> \t# \tmsg\n> \t#\n> \t# On branch master\n> \t# Changes to be committed:\n> \t# (use \"git reset HEAD ...\" to unstage)\n> \t#\n> \t#\tmodified: sm1\n> \t#\tmodified: sm2\n\nI think this presentation order is horrible.\n\n * I think everbody preferes to have \"On branch master\" at the\n very beginning, to avoid committing to a wrong branch by\n mistake.\n\n * As I understand it, in the real life use, there will be quite\n many commits from the submodule updates when a new commit is\n bound to a submodule in the superproject, as _the_ point of\n having a submodule is to bind a more or less independent\n project that progresses at quite a different pace as a\n submodule to the superproject. In other words, by design,\n the superproject can stay behind from the tip of subproject\n and rebind it to a different commit only when there are\n significant changes of the subproject that need to be there\n to allow the other parts of the superproject (either\n superproject itself or another submodule) to use the features\n and/or fixes the submodule updates provides.\n\n Which means it will not be uncommon have hundreds of \"one\n line message\" for the submodules at the very beginning of the\n commit log message buffer, and your prsentation order will\n make that part overwhelm the overview of what changed _in_\n the supermodule itself (the \"Changes to be committed:\"\n lines), which gives the birds-eye view.\n\n And I think it is more important to give the birds-eye view\n of the supermodule itself first, when you are helping to\n prepare a commit message for the supermodule. The user would\n start the commit log for the superproject with \"This updates\n the new frotz feature. It uses the updated API from the\n submodules A and B so we now use updated versions of them.\"\n and then continue \"Notable changes in submodule A are ...\".\n And the new part you are adding would help the user to write\n the latter description.\n\nI also find \"<<< lines then >>> other lines\" format very hard to\nread. Maybe formatting it like this would make it a bit more\nreadable and more space efficient?\n\n \t# * sm1 354cd45...3f751e5:\n \t# - one line message for C\n \t# - one line message for B\n \t# + one line message for D\n \t# + one line message for E\n \t# * sm2 5c8bfb5...ac46d84:\n \t# - msg\n\nNote that if you swap the order and move this at the tail\n(perhaps before \"Untracked files:\" section, if you do not have a\ndecent .gitignore set up), you can also lose the \"submodules\nmodified: sm1 sm2\" line and the blank line before it, which\nwould make the output even shorter without losing any useful\ninformation.\n"},{"id":"59253","messageId":"8c5c35580711101607l7c45d6f5ge0f40ac6e447031a@mail.gmail.com","threadId":"10788","inReplyTo":"1194722863-14741-1-git-send-email-pkufranky@gmail.com","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-11-11T00:07:01Z","receivedAt":"2007-11-11T00:07:01Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On Nov 10, 2007 8:27 PM, Ping Yin wrote:\n> This commit teaches git status/commit to also show commits of user-cared\n> modified submodules since HEAD (or HEAD^ if --amend option is on).\n\nSome nitpicks:\n-we'll need a config option to enable/disable this output in git-status\n-the feature should probably be implemented in git-submodule.sh\n\n--\nlarsh\n"},{"id":"59267","messageId":"46dff0320711102130g5171a421r244bdf74a578f68b@mail.gmail.com","threadId":"10788","inReplyTo":"20071110195509.GI2261MdfPADPa@greensroom.kotnet.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Yin Ping","fromEmail":"pkufranky@gmail.com","sentAt":"2007-11-11T05:30:34Z","receivedAt":"2007-11-11T05:30:34Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Nov 11, 2007 3:55 AM, Sven Verdoolaege wrote:\n> On Sun, Nov 11, 2007 at 03:27:43AM +0800, Ping Yin wrote:\n> > This commit teaches git status/commit to also show commits of user-cared\n>\n> Does it? It looks like you only changed git-commit.\n> Shouldn't this be put in wt_status_print, if anywhere?\n>\ngit-commit and git-status correspond to the same script git-commit.sh\n> Also, you have some typos:\n>\n> > + test -n \"$modules\" && echo -e \"#\\n# submodule modifiled: \"$modules\"\\n#\"\n> [..]\n> > + echo \" Warn: $name dosn't contains commit $headone\"\n>\n> skimo\n>\nOops, i'll fix it\n\n\n\n-- \nPing Yin\n"},{"id":"59276","messageId":"46dff0320711102218h259199e3g2b4a4d3b73202cdb@mail.gmail.com","threadId":"10788","inReplyTo":"7vabpliz13.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Yin Ping","fromEmail":"pkufranky@gmail.com","sentAt":"2007-11-11T06:18:11Z","receivedAt":"2007-11-11T06:18:11Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Nov 11, 2007 5:14 AM, Junio C Hamano wrote:\n> * I think everbody preferes to have \"On branch master\" at the\n> very beginning\n\nReasonable.\n\n>\n> * As I understand it, in the real life use,\n> the superproject can stay behind from the tip of subproject\n> and rebind it to a different commit only when there are\n> significant changes of the subproject that need to be there\n> to allow the other parts of the superproject (either\n> superproject itself or another submodule) to use the features\n> and/or fixes the submodule updates provides.\n\nI think it's this kind of case in most open-source project. However,\nin a company environment, superprojects may be not so super. A\nsuperproject may bind very tightly with submodules (such as the html\ntemplate files which change very frequently) and the developer of a superproject\nand its submodules may be the same guy(s). In these cases, a long list\nof commits\nfor submodules are expected be reviewed when commiting the superproject.\n>\n> And I think it is more important to give the birds-eye view\n> of the supermodule itself first, when you are helping to\n> prepare a commit message for the supermodule.\n> and then continue \"Notable changes in submodule A are ...\".\n> And the new part you are adding would help the user to write\n> the latter description.\nI agree.\n>\n> I also find \"<<< lines then >>> other lines\" format very hard to\n> read. Maybe formatting it like this would make it a bit more\n> readable and more space efficient?\n>\n> # * sm1 354cd45...3f751e5:\n> # - one line message for C\n> # - one line message for B\n> # + one line message for D\n> # + one line message for E\n> # * sm2 5c8bfb5...ac46d84:\n> # - msg\n>\nI have struggled between these two kinds of presentation and finally\nchoose the '<<<' one.\nIMHO, '-/+' one each line will distract and less space/size efficient\n(100 '+/-' for 100 lines of messages).\n\nHowever, it's not a big matter. I'll change the presentation if\neveryone prefers the\npatch-like one.\n\n> Note that if you swap the order and move this at the tail\n> (perhaps before \"Untracked files:\" section, if you do not have a\n> decent .gitignore set up), you can also lose the \"submodules\n> modified: sm1 sm2\" line and the blank line before it, which\n> would make the output even shorter without losing any useful\n> information.\n>\nSo following is ok?\n # On branch master\n # Changes to be committed:\n # (use \"git reset HEAD ...\" to unstage)\n #\n # modified: sm1\n # modified: sm2\n # modified: sm3\n #\n # Changed but not updated:\n # (use \"git add/rm ...\" to update what will be committed)\n #\n # modified: file1\n #\n # Submodules modifiled: sm1 sm2 sm3\n #\n # * sm1 354cd45...3f751e5:\n # - one line message for C\n # - one line message for B\n # + one line message for D\n # + one line message for E\n # * sm2 354cd46...3f751e7:\n # - one line message\n # * sm3 354cd47...3f751e8:\n # Warn: sm1 doesn't contains commit 354cd45\n #\n # Untracked files:\n # (use \"git add ...\" to include in what will be committed)\n #\n # file2\n #\n\n\n\n-- \nPing Yin\n"},{"id":"59277","messageId":"46dff0320711102224h7a14329ag27fcfcfcf479823e@mail.gmail.com","threadId":"10788","inReplyTo":"8c5c35580711101607l7c45d6f5ge0f40ac6e447031a@mail.gmail.com","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Yin Ping","fromEmail":"pkufranky@gmail.com","sentAt":"2007-11-11T06:24:55Z","receivedAt":"2007-11-11T06:24:55Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Nov 11, 2007 8:07 AM, Lars Hjemli wrote:\n> On Nov 10, 2007 8:27 PM, Ping Yin wrote:\n> > This commit teaches git status/commit to also show commits of user-cared\n> > modified submodules since HEAD (or HEAD^ if --amend option is on).\n>\n> Some nitpicks:\n> -we'll need a config option to enable/disable this output in git-status\nagree. default off?\n> -the feature should probably be implemented in git-submodule.sh\n>\nI'll want to see the commits of submodules when editing commit msg. So\ni implemented\nthis in git-commit.sh. May be a configuration/option can added to turn\nthis on or off.\n\n> --\n> larsh\n>\n\n\n\n-- \nPing Yin\n"},{"id":"59289","messageId":"8c5c35580711110027y3a17b9a0j16d3db5ffe606554@mail.gmail.com","threadId":"10788","inReplyTo":"46dff0320711102224h7a14329ag27fcfcfcf479823e@mail.gmail.com","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-11-11T08:27:08Z","receivedAt":"2007-11-11T08:27:08Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On Nov 11, 2007 7:24 AM, Yin Ping wrote:\n> On Nov 11, 2007 8:07 AM, Lars Hjemli wrote:\n> > On Nov 10, 2007 8:27 PM, Ping Yin wrote:\n> > > This commit teaches git status/commit to also show commits of user-cared\n> > > modified submodules since HEAD (or HEAD^ if --amend option is on).\n> >\n> > Some nitpicks:\n> > -we'll need a config option to enable/disable this output in git-status\n> agree. default off?\n\nThat would be nice.\n\n> > -the feature should probably be implemented in git-submodule.sh\n> >\n> I'll want to see the commits of submodules when editing commit msg.\n\nIf git-commit.sh uses git-submodule.sh to get this information, the\nfeature is still available in git-submodule even if it's disabled for\ngit-status.\n\n--\nlarsh\n"},{"id":"59373","messageId":"7vhcjscyhu.fsf@gitster.siamese.dyndns.org","threadId":"10788","inReplyTo":"46dff0320711102218h259199e3g2b4a4d3b73202cdb@mail.gmail.com","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-11T20:34:37Z","receivedAt":"2007-11-11T20:34:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Yin Ping\" writes:\n\n> I think it's this kind of case in most open-source project. However,\n> in a company environment, superprojects may be not so super.\n\nLet's not say \"most open-source\" nor \"company\", because I think\nnobody said anything that substantiates that the commit density\ncharacteristics I described is typical for most open-source, nor\nwhat you said is typical for corporate development projects, in\nthis thread so far.\n\nIf \"superprojects is not so super\", why are you using submodule\nto bind these, instead of using a single project that tracks\ndevelopments of such closely tied parts?\n\nI am not saying that it is wrong to use submodule to track such\ngroups of source trees whose versions are very closely tied\ntogether. At least not yet.\n\nI am just trying to find out what benefit you are getting out of\nthe submodule support, after rejecting one of the most visible\nand advertised benefit of submodule support, which is to enable\nbinding \"related but not that closely tied together\" projects.\n"},{"id":"59425","messageId":"46dff0320711112138j6d1e64a1qc9ea449e2bdab384@mail.gmail.com","threadId":"10788","inReplyTo":"7vhcjscyhu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2007-11-12T05:38:03Z","receivedAt":"2007-11-12T05:38:03Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Nov 12, 2007 4:34 AM, Junio C Hamano wrote:\n>\n> If \"superprojects is not so super\", why are you using submodule\n> to bind these, instead of using a single project that tracks\n> developments of such closely tied parts?\n>\nFor small modules crossing over mutiple projects, the submodule way\nmay be more suitable. And such submodule (such as common config files,\ncommon templates) may be binded tightly with superproject\n\n>\n\n\n\n-- \nPing Yin\n"},{"id":"59433","messageId":"47380019.1000704@viscovery.net","threadId":"10788","inReplyTo":"7vhcjscyhu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-12T07:26:17Z","receivedAt":"2007-11-12T07:26:17Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> \"Yin Ping\" writes:\n> \n>> I think it's this kind of case in most open-source project. However,\n>> in a company environment, superprojects may be not so super.\n> \n> Let's not say \"most open-source\" nor \"company\", because I think\n> nobody said anything that substantiates that the commit density\n> characteristics I described is typical for most open-source, nor\n> what you said is typical for corporate development projects, in\n> this thread so far.\n> \n> If \"superprojects is not so super\", why are you using submodule\n> to bind these, instead of using a single project that tracks\n> developments of such closely tied parts?\n\nBecause the a monolithic project is just too large? Think of KDE!\n\n> I am not saying that it is wrong to use submodule to track such\n> groups of source trees whose versions are very closely tied\n> together. At least not yet.\n\nIn KDE, the supermodule will actually just be a container that binds the \nsubmodules together. The essential development will happen in the \nsubmodules, and the supermodule will receive a commit quite frequently. In \nthis case, there will often be only a few or a few dozen commits listed, and \nI anticipate that the integrator who is going to make the commit (to the \nsupermodule) will probably like the summary. So I'm all for it.\n\n-- Hannes\n"},{"id":"59440","messageId":"200711120940.40271.johan@herland.net","threadId":"10788","inReplyTo":"7vhcjscyhu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-11-12T08:40:39Z","receivedAt":"2007-11-12T08:40:39Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 11 November 2007, Junio C Hamano wrote:\n> \"Yin Ping\" writes:\n> \n> > I think it's this kind of case in most open-source project. However,\n> > in a company environment, superprojects may be not so super.\n> \n> Let's not say \"most open-source\" nor \"company\", because I think\n> nobody said anything that substantiates that the commit density\n> characteristics I described is typical for most open-source, nor\n> what you said is typical for corporate development projects, in\n> this thread so far.\n> \n> If \"superprojects is not so super\", why are you using submodule\n> to bind these, instead of using a single project that tracks\n> developments of such closely tied parts?\n> \n> I am not saying that it is wrong to use submodule to track such\n> groups of source trees whose versions are very closely tied\n> together. At least not yet.\n> \n> I am just trying to find out what benefit you are getting out of\n> the submodule support, after rejecting one of the most visible\n> and advertised benefit of submodule support, which is to enable\n> binding \"related but not that closely tied together\" projects.\n\nAt $dayjob, we are working on a codebase roughly the same size as current \nlinux-kernel with about 8 years of history in CVS. I'm currently looking at \nhow suitable git would be for our revision control purposes (and so far I'm \nlovin' it).\n\nThe codebase is divided into CVS modules; most modules (aka. \"core\" modules) \neach have their own in-house maintainer and have internal releases with \nvariable frequency. The other modules (aka. \"platform/product\" modules) \neach pull together a carefully chosen set of \"core\" modules as submodules, \nand add platform code to create - in the end - a complete product (with its \nown release frequency). Specifically:\n\n- All the modules required by the product must be present in the checkout \nbefore a build can be made\n\n- All the modules are independently developed, with different \ndevelopment/release timelines\n\n- The \"core\" people only focus on 1-2 modules at a time, but \nthe \"platform/product\" people might make changes in _many_ modules during a \nworkday.\n\nWhen investigating how to mesh this workflow with git, I naturally ended up \nwith converting each CVS module to a git repository, and making \nthe \"platform/product\" repos include the required \"core\" repos as \nsubmodules. This decision has the following effect from git's POV:\n\n- \"superproject is not so super\" in that _all_ required modules must be \nchecked out before a build can be made. In other words: all the submodules \nin a repo are \"interesting\"\n\n- The modules are \"related but not that closely tied together\" since they \nfollow separate development schedules, with separate releases, etc.\n\n- The \"platform/product\" people will most certainly want to have commands \nlike \"git diff\", \"git status\", and maybe even \"git log\" and \"git-commit\" \nrecurse into submodules.\n\n- The \"core\" people will probably not want \"recurse-into-submodules\" \nbehaviour, although I can see places where it could be useful for them as \nwell.\n\n\nA possible solution to the above problem is to add \na '--recurse-into-submodules' option to all relevant git commands. At the \nsame time, the actual implementation of submodule recursion should probably \nbe kept in the vicinity of \"git-submodule\" (instead of spreading it across \nthe other git commands).\n\nProbably unrealistic: Maybe we could solve the problem by adding\n\"--recurse-into-submodules\" to the toplevel 'git' command itself, and make \nit re-invoke itself recursively in each submodule.\n\n\nHope this gives you insight into how _some_ people would like to use git's \nsubmodule support.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"59449","messageId":"Pine.LNX.4.64.0711120950370.4362@racer.site","threadId":"10788","inReplyTo":"47380019.1000704@viscovery.net","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T09:51:43Z","receivedAt":"2007-11-12T09:51:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Johannes Sixt wrote:\n\n> Junio C Hamano schrieb:\n>\n> > I am not saying that it is wrong to use submodule to track such groups \n> > of source trees whose versions are very closely tied together. At \n> > least not yet.\n> \n> In KDE, the supermodule will actually just be a container that binds the \n> submodules together. The essential development will happen in the \n> submodules, and the supermodule will receive a commit quite frequently. \n> In this case, there will often be only a few or a few dozen commits \n> listed, and I anticipate that the integrator who is going to make the \n> commit (to the supermodule) will probably like the summary. So I'm all \n> for it.\n\nI like it, too. And we can make the number of shown commits configurable, \njust like for the merge summary. But I'd rather see the code in \nwt-status.c than in git-submodule.sh.\n\nCiao,\nDscho\n"},{"id":"59453","messageId":"47382506.1090106@viscovery.net","threadId":"10788","inReplyTo":"7vabpliz13.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-12T10:03:50Z","receivedAt":"2007-11-12T10:03:50Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> I also find \"<<< lines then >>> other lines\" format very hard to\n> read. Maybe formatting it like this would make it a bit more\n> readable and more space efficient?\n> \n> \t# * sm1 354cd45...3f751e5:\n> \t# - one line message for C\n> \t# - one line message for B\n> \t# + one line message for D\n> \t# + one line message for E\n> \t# * sm2 5c8bfb5...ac46d84:\n> \t# - msg\n\nHow about the equivalent of\n\n\tgit log --left-right --pretty=oneline --topo-order 354cd45...3f751e5\n\nwhich would be\n\n \t# * sm1 354cd45...3f751e5:\n \t# one line message for D\n \t# >one line message for E\n\n-- Hannes\n"},{"id":"59591","messageId":"7vve87142z.fsf@gitster.siamese.dyndns.org","threadId":"10788","inReplyTo":"Pine.LNX.4.64.0711120950370.4362@racer.site","subject":"Re: [PATCH] status&commit: Teach them to show commits of modified submodules.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T22:39:16Z","receivedAt":"2007-11-12T22:39:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 12 Nov 2007, Johannes Sixt wrote:\n>\n>> Junio C Hamano schrieb:\n>>\n>> > I am not saying that it is wrong to use submodule to track such groups \n>> > of source trees whose versions are very closely tied together. At \n>> > least not yet.\n>> \n>> In KDE, the supermodule will actually just be a container that binds the \n>> submodules together. The essential development will happen in the \n>> submodules, and the supermodule will receive a commit quite frequently. \n>> In this case, there will often be only a few or a few dozen commits \n>> listed, and I anticipate that the integrator who is going to make the \n>> commit (to the supermodule) will probably like the summary. So I'm all \n>> for it.\n>\n> I like it, too. And we can make the number of shown commits configurable, \n> just like for the merge summary.\n\nVery good point. In the case J6t uses for his illustration\nabove, changing the submodule bound to the superproject is more\nor less like merging.\n\n> But I'd rather see the code in wt-status.c than in\n> git-submodule.sh.\n\nI do not have a strong preference either way, but submodule-loving\npeople may want to say \"git submodule shortlog \" or whatever\nfrom the command line. \n\nMaking a standalone function that takes two commits from the\nsubproject and produces the output, and calling that function\nfrom both git-submodule (to implement the above \"shortlog\"\nsubcommand) and from wt-status.c (to show what Yin wants to add,\nonly when \"status.submodule\" is set), would be a reasonable\nimplementation. \n"}]}