{"thread":{"id":"22893","subject":"Latest master failing t7401 submodule tests","startedAt":"2010-03-03T12:21:36Z","lastAt":"2010-03-04T06:48:10Z","messageCount":17,"participants":["A Large Angry SCM","Junio C Hamano","Jeff King","Johan Herland","Jens Lehmann","Sverre Rabbelier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136073","messageId":"4B8E5450.3040702@gmail.com","threadId":"22893","inReplyTo":null,"subject":"Latest master failing t7401 submodule tests","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-03-03T12:21:36Z","receivedAt":"2010-03-03T12:21:36Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"13 to the 18 tests in t7401 submodule test jig are failing with the \nlatest master this morning.\n"},{"id":"136086","messageId":"7vhboxqje8.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"4B8E5450.3040702@gmail.com","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-03T19:45:19Z","receivedAt":"2010-03-03T19:45:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM <gitzilla@gmail.com> writes:\n\n> 13 to the 18 tests in t7401 submodule test jig are failing with the\n> latest master this morning.\n\nDo you mean v1.7.0.1-138-ga75bab5?\n\nI don't see it with Debian 5.0.4 on x86_64 (my primary box), Fedora 11 nor\nFreeBSD 8.0 (the latter two are kvm sandboxes pretending to be i686).\n"},{"id":"136090","messageId":"20100303200239.GA28904@coredump.intra.peff.net","threadId":"22893","inReplyTo":"7vhboxqje8.fsf@alter.siamese.dyndns.org","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-03T20:02:39Z","receivedAt":"2010-03-03T20:02:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 03, 2010 at 11:45:19AM -0800, Junio C Hamano wrote:\n\n> A Large Angry SCM <gitzilla@gmail.com> writes:\n> \n> > 13 to the 18 tests in t7401 submodule test jig are failing with the\n> > latest master this morning.\n> \n> Do you mean v1.7.0.1-138-ga75bab5?\n> \n> I don't see it with Debian 5.0.4 on x86_64 (my primary box), Fedora 11 nor\n> FreeBSD 8.0 (the latter two are kvm sandboxes pretending to be i686).\n\nI did see it on my debian unstable box with with dash as /bin/sh (though\nIIRC, isn't FreeBSD /bin/sh ash?). It looked like a \"shift: can't shift\nthat many\" error, but I haven't had time to track it down further yet\n(I'm installing lighting in a 2-year-old's play kitchen. ;) ).\n\nMaybe the shell selection will give somebody lead. If not, I'll try to\nlook at it again in a few hours.\n\n-Peff\n"},{"id":"136097","messageId":"7vhboxno38.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"20100303200239.GA28904@coredump.intra.peff.net","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-03T20:32:11Z","receivedAt":"2010-03-03T20:32:11Z","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> I did see it on my debian unstable box with with dash as /bin/sh (though\n\n3deea89 (submodule summary: Don't barf when invoked in an empty repo,\n2010-02-16) looks broken.  It shifts $1 unconditionally when:\n\n - \"git submodule summary\", no arguments given and defaults to HEAD which\n   is _not_ unborn (we shouldn't shift in this case);\n\n - \"git submodule summary HEAD path...\", which is not unborn (we should shift);\n\n - \"git submodule summary path...\", defaults to HEAD which is _not_ unborn\n   (we shouldn't shift).\n"},{"id":"136101","messageId":"20100303204257.GA5501@coredump.intra.peff.net","threadId":"22893","inReplyTo":"7vhboxno38.fsf@alter.siamese.dyndns.org","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-03T20:42:57Z","receivedAt":"2010-03-03T20:42:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 03, 2010 at 12:32:11PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I did see it on my debian unstable box with with dash as /bin/sh (though\n> \n> 3deea89 (submodule summary: Don't barf when invoked in an empty repo,\n> 2010-02-16) looks broken.  It shifts $1 unconditionally when:\n\nYeah, I can confirm that the breakage was introduced there (and it looks\nlike for bash, an extra \"shift\" is a failing command but doesn't make\nthe shell barf, but for dash it is more serious, which explains why\ntests passed for you).\n\n>  - \"git submodule summary\", no arguments given and defaults to HEAD which\n>    is _not_ unborn (we shouldn't shift in this case);\n\nYes, definitely a bug.\n\n>  - \"git submodule summary HEAD path...\", which is not unborn (we should shift);\n\nYes, and I think we do that part right.\n\n>  - \"git submodule summary path...\", defaults to HEAD which is _not_ unborn\n>    (we shouldn't shift).\n\nI don't think this is a problem. We do:\n\n  git rev-parse -q --verify --default HEAD path\n\nand it correctly reports failure, so we never do the problematic shift.\n\nSo I think we just need\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 1ea4143..bf5ea50 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -556,7 +556,7 @@ cmd_summary() {\n \tif rev=$(git rev-parse -q --verify --default HEAD ${1+\"$1\"})\n \tthen\n \t\thead=$rev\n-\t\tshift\n+\t\ttest -n \"$1\" && shift\n \telif test -z \"$1\" -o \"$1\" = \"HEAD\"\n \tthen\n \t\treturn\n\n-Peff\n"},{"id":"136102","messageId":"7vbpf5m8kh.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"7vhboxno38.fsf@alter.siamese.dyndns.org","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-03T20:52:46Z","receivedAt":"2010-03-03T20:52:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> I did see it on my debian unstable box with with dash as /bin/sh (though\n>\n> 3deea89 (submodule summary: Don't barf when invoked in an empty repo,\n> 2010-02-16) looks broken.  It shifts $1 unconditionally when:\n>\n>  - \"git submodule summary\", no arguments given and defaults to HEAD which\n>    is _not_ unborn (we shouldn't shift in this case);\n>\n>  - \"git submodule summary HEAD path...\", which is not unborn (we should shift);\n>\n>  - \"git submodule summary path...\", defaults to HEAD which is _not_ unborn\n>    (we shouldn't shift).\n\nIOW, shouldn't the code look more like this?\n\n\tif test $# != 0 && head=$(git rev-parse -q --verify \"$1\")\n\tthen\n\t\tshift\n\telse\n\t\tgit rev-parse -q --verify HEAD >/dev/null || return 0\n\t\thead=HEAD\n\tfi\n\nThat is, if a specific version might be there, we see if it is a version\nand shift it out only if that is the case.  Otherwise we default to HEAD\nbut special case for an unborn HEAD (and report success).\n\n\n git-submodule.sh |    9 +++------\n 1 files changed, 3 insertions(+), 6 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 5869c00..bd3a8d4 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -553,15 +553,12 @@ cmd_summary() {\n \n \ttest $summary_limit = 0 && return\n \n-\tif rev=$(git rev-parse -q --verify --default HEAD ${1+\"$1\"})\n+\tif test $# != 0 && head=$(git rev-parse -q --verify \"$1\")\n \tthen\n-\t\thead=$rev\n \t\tshift\n-\telif test -z \"$1\" -o \"$1\" = \"HEAD\"\n-\tthen\n-\t\treturn\n \telse\n-\t\thead=\"HEAD\"\n+\t\tgit rev-parse -q --verify HEAD >/dev/null || return 0\n+\t\thead=HEAD\n \tfi\n \n \tif [ -n \"$files\" ]\n"},{"id":"136103","messageId":"7v3a0hktga.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"20100303204257.GA5501@coredump.intra.peff.net","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-03T21:04:37Z","receivedAt":"2010-03-03T21:04:37Z","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>>  - \"git submodule summary path...\", defaults to HEAD which is _not_ unborn\n>>    (we shouldn't shift).\n>\n> I don't think this is a problem. We do:\n>\n>   git rev-parse -q --verify --default HEAD path\n>\n> and it correctly reports failure, so we never do the problematic shift.\n\nStepping back a bit, why do we even special case an unborn branch case in\nthe first place?  \n\n    rm -fr one && git init one && cd one && git diff HEAD\n\nwould diagnose it as an error (we may want to sugarcoat \"ambiguous\nargument\" error message, but that is a tangent).\n\nI may be able to buy \"status/diff internally calls submodule summary, and\nthat codepath needs to special case a submodule on an unborn branch _for\nsuch and such reasons_\" if the reasoning is sound, but even if that is the\ncase, shouldn't that special case be triggered explicitly by the caller of\n\"submodule summary\" with an option?\n"},{"id":"136106","messageId":"7vzl2phz8e.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"7v3a0hktga.fsf@alter.siamese.dyndns.org","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-03T21:28:01Z","receivedAt":"2010-03-03T21:28:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>>>  - \"git submodule summary path...\", defaults to HEAD which is _not_ unborn\n>>>    (we shouldn't shift).\n>>\n>> I don't think this is a problem. We do:\n>>\n>>   git rev-parse -q --verify --default HEAD path\n>>\n>> and it correctly reports failure, so we never do the problematic shift.\n>\n> Stepping back a bit, why do we even special case an unborn branch case in\n> the first place?  \n>\n>     rm -fr one && git init one && cd one && git diff HEAD\n>\n> would diagnose it as an error (we may want to sugarcoat \"ambiguous\n> argument\" error message, but that is a tangent).\n>\n> I may be able to buy \"status/diff internally calls submodule summary, and\n> that codepath needs to special case a submodule on an unborn branch _for\n> such and such reasons_\" if the reasoning is sound, but even if that is the\n> case, shouldn't that special case be triggered explicitly by the caller of\n> \"submodule summary\" with an option?\n\nContinuing to mutter to myself...  I am suspecting that the right solution\nto the issue $gmane/140066 raised may be your \"dwim-ref fix in 003c6ab\n(dwim_ref: fix dangling symref warning, 2010-02-16) and a patch along the\nline of the attached (with 3deea89 reverted of course).\n\nWe _might_ also want to revert 003c6ab, though it is more or less an\nindependent issue.\n\n wt-status.c |    3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 5807fc3..1cca3aa 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -476,6 +476,9 @@ static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitt\n \t\tNULL\n \t};\n \n+\tif (s->is_initial && !uncommitted)\n+\t\treturn;\n+\n \tsprintf(summary_limit, \"%d\", s->submodule_summary);\n \tsnprintf(index, sizeof(index), \"GIT_INDEX_FILE=%s\", s->index_file);\n \n"},{"id":"136108","messageId":"7vhboxf4nx.fsf_-_@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"7vzl2phz8e.fsf@alter.siamese.dyndns.org","subject":"What should \"git submodule summary\" give before an initial commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-03T21:58:58Z","receivedAt":"2010-03-03T21:58:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"git status\" collects the changes for both the index (since HEAD) and the\nworking tree files (since the index), summarizes and shows them.  When it\nis run before the first commit is made, it uses a logic different from the\none used in the normal case to gather the information on the index, as we\ndon't have HEAD yet, i.e. instead of \"diff-index HEAD\", we would run\n\"diff-index emtpy-tree\".\n\nHow should status.submodulesummary integrate into this framework?\n\nCurrently, it blindly runs \"git submodule summary\", and it gives an extra\nerror message about HEAD not being a commit, and people (me included)\nmisguidedly have spent time on squelching the message.\n\nBut I think that was _all wrong_.  I do not think \"git submodule summary\"\nshould fail even when you haven't made your first commit.\n\nIf you are before the first commit, we say everything you have in the\nindex is a change you are adding with your next commit (which will be your\ninitial one).  If you added a submodule commit to the index, shouldn't\n\"git submodule summary\" say \"you'll be committing the addition of this\nsubproject\"?  IOW, shouldn't we be comparing an empty tree to find added\nsubmodules, like this, when we haven't made the first commit?\n\n git-submodule.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 5869c00..0397f9d 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -556,10 +556,10 @@ cmd_summary() {\n \tif rev=$(git rev-parse -q --verify --default HEAD ${1+\"$1\"})\n \tthen\n \t\thead=$rev\n-\t\tshift\n+\t\ttest $# = 0 || shift\n \telif test -z \"$1\" -o \"$1\" = \"HEAD\"\n \tthen\n-\t\treturn\n+\t\thead=4b825dc642cb6eb9a060e54bf8d69288fbee4904\n \telse\n \t\thead=\"HEAD\"\n \tfi\n"},{"id":"136112","messageId":"20100303225744.GA26575@coredump.intra.peff.net","threadId":"22893","inReplyTo":"7vzl2phz8e.fsf@alter.siamese.dyndns.org","subject":"Re: Latest master failing t7401 submodule tests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-03T22:57:44Z","receivedAt":"2010-03-03T22:57:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 03, 2010 at 01:28:01PM -0800, Junio C Hamano wrote:\n\n> Continuing to mutter to myself...  I am suspecting that the right solution\n> to the issue $gmane/140066 raised may be your \"dwim-ref fix in 003c6ab\n> (dwim_ref: fix dangling symref warning, 2010-02-16) and a patch along the\n> line of the attached (with 3deea89 reverted of course).\n\nI am totally clueless about submodules, not having ever actually used\nthem myself. So I will let others weigh in on whether \"git submodule\nsummary\" on an unborn branch makes any sense. But:\n\n  1. _if_ it is not a sensible thing, then your patch below:\n\n> diff --git a/wt-status.c b/wt-status.c\n> index 5807fc3..1cca3aa 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -476,6 +476,9 @@ static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitt\n>  \t\tNULL\n>  \t};\n>  \n> +\tif (s->is_initial && !uncommitted)\n> +\t\treturn;\n> +\n>  \tsprintf(summary_limit, \"%d\", s->submodule_summary);\n>  \tsnprintf(index, sizeof(index), \"GIT_INDEX_FILE=%s\", s->index_file);\n\nSeems like the right thing, to protect git-status users.\n\n  2. If it is sensible, then the hunk we both posted (to check for args\n     before shift) makes sense to me. Whether the \"compare against empty\n     tree\" bit makes sense is beyond my submodule cluelessness to\n     determine (but it intuitively sounds right to me).\n\nIn either case, I think that:\n\n> We _might_ also want to revert 003c6ab, though it is more or less an\n> independent issue.\n\nreverting 003c6ab is not a good idea. As far as I am concerned, it was a\nbugfix.\n\n-Peff\n"},{"id":"136113","messageId":"201003040010.19061.johan@herland.net","threadId":"22893","inReplyTo":"7vhboxf4nx.fsf_-_@alter.siamese.dyndns.org","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-03-03T23:10:18Z","receivedAt":"2010-03-03T23:10:18Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 03 March 2010, Junio C Hamano wrote:\n> \"git status\" collects the changes for both the index (since HEAD) and the\n> working tree files (since the index), summarizes and shows them.  When it\n> is run before the first commit is made, it uses a logic different from\n> the one used in the normal case to gather the information on the index,\n> as we don't have HEAD yet, i.e. instead of \"diff-index HEAD\", we would\n> run \"diff-index emtpy-tree\".\n> \n> How should status.submodulesummary integrate into this framework?\n> \n> Currently, it blindly runs \"git submodule summary\", and it gives an extra\n> error message about HEAD not being a commit, and people (me included)\n> misguidedly have spent time on squelching the message.\n> \n> But I think that was _all wrong_.  I do not think \"git submodule summary\"\n> should fail even when you haven't made your first commit.\n> \n> If you are before the first commit, we say everything you have in the\n> index is a change you are adding with your next commit (which will be\n> your initial one).  If you added a submodule commit to the index,\n> shouldn't \"git submodule summary\" say \"you'll be committing the addition\n> of this subproject\"?  IOW, shouldn't we be comparing an empty tree to\n> find added submodules, like this, when we haven't made the first commit?\n> \n>  git-submodule.sh |    4 ++--\n>  1 files changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 5869c00..0397f9d 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -556,10 +556,10 @@ cmd_summary() {\n>  \tif rev=$(git rev-parse -q --verify --default HEAD ${1+\"$1\"})\n>  \tthen\n>  \t\thead=$rev\n> -\t\tshift\n> +\t\ttest $# = 0 || shift\n>  \telif test -z \"$1\" -o \"$1\" = \"HEAD\"\n>  \tthen\n> -\t\treturn\n> +\t\thead=4b825dc642cb6eb9a060e54bf8d69288fbee4904\n>  \telse\n>  \t\thead=\"HEAD\"\n>  \tfi\n\nAcked-by: Johan Herland <johan@herland.net>\n\nIf you're planning to revert 3deea89 (although the above patch suggests \nyou're not), then please don't revert the t7401 testcases added by that \ncommit. The testcase is useful in any case.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"136118","messageId":"4B8F00AA.5050007@web.de","threadId":"22893","inReplyTo":"7vhboxf4nx.fsf_-_@alter.siamese.dyndns.org","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-03-04T00:36:58Z","receivedAt":"2010-03-04T00:36:58Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.03.2010 22:58, schrieb Junio C Hamano:\n> \"git status\" collects the changes for both the index (since HEAD) and the\n> working tree files (since the index), summarizes and shows them.  When it\n> is run before the first commit is made, it uses a logic different from the\n> one used in the normal case to gather the information on the index, as we\n> don't have HEAD yet, i.e. instead of \"diff-index HEAD\", we would run\n> \"diff-index emtpy-tree\".\n> \n> How should status.submodulesummary integrate into this framework?\n> \n> Currently, it blindly runs \"git submodule summary\", and it gives an extra\n> error message about HEAD not being a commit, and people (me included)\n> misguidedly have spent time on squelching the message.\n> \n> But I think that was _all wrong_.  I do not think \"git submodule summary\"\n> should fail even when you haven't made your first commit.\n> \n> If you are before the first commit, we say everything you have in the\n> index is a change you are adding with your next commit (which will be your\n> initial one).  If you added a submodule commit to the index, shouldn't\n> \"git submodule summary\" say \"you'll be committing the addition of this\n> subproject\"?  IOW, shouldn't we be comparing an empty tree to find added\n> submodules, like this, when we haven't made the first commit?\n> \n>  git-submodule.sh |    4 ++--\n>  1 files changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 5869c00..0397f9d 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -556,10 +556,10 @@ cmd_summary() {\n>  \tif rev=$(git rev-parse -q --verify --default HEAD ${1+\"$1\"})\n>  \tthen\n>  \t\thead=$rev\n> -\t\tshift\n> +\t\ttest $# = 0 || shift\n>  \telif test -z \"$1\" -o \"$1\" = \"HEAD\"\n>  \tthen\n> -\t\treturn\n> +\t\thead=4b825dc642cb6eb9a060e54bf8d69288fbee4904\n>  \telse\n>  \t\thead=\"HEAD\"\n>  \tfi\n\nAcked-by: Jens Lehmann <Jens.Lehmann@web.de>\n\nYour patch fixes \"git submodule summary\" in a freshly created repo for me.\n\n\nBut to make \"git status\" with status.submodulesummary work as expected,\ni need something like the following patch on top of current pu (because\n\"git submodule summary --cached HEAD\" returns no changes in a freshly\ncreated repo):\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 5807fc3..6769c2e 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -459,11 +459,21 @@ static void wt_status_print_changed(struct wt_status *s)\n \twt_status_print_trailer(s);\n }\n\n-static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitted)\n+static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitted, int initial)\n {\n \tstruct child_process sm_summary;\n \tchar summary_limit[64];\n \tchar index[PATH_MAX];\n+\tconst char *ref = NULL;\n+\tif (!uncommitted) {\n+\t\tif (s->amend)\n+\t\t\tref = \"HEAD^\";\n+\t\telse\n+\t\t\tif (initial)\n+\t\t\t\tref = \"4b825dc642cb6eb9a060e54bf8d69288fbee4904\";\n+\t\t\telse\n+\t\t\t\tref = \"HEAD\";\n+\t}\n \tconst char *env[] = { index, NULL };\n \tconst char *argv[] = {\n \t\t\"submodule\",\n@@ -472,7 +482,7 @@ static void wt_status_print_submodule_summary(struct wt_status *s, int uncommitt\n \t\t\"--for-status\",\n \t\t\"--summary-limit\",\n \t\tsummary_limit,\n-\t\tuncommitted ? NULL : (s->amend ? \"HEAD^\" : \"HEAD\"),\n+\t\tref,\n \t\tNULL\n \t};\n\n@@ -581,8 +591,8 @@ void wt_status_print(struct wt_status *s)\n \twt_status_print_unmerged(s);\n \twt_status_print_changed(s);\n \tif (s->submodule_summary) {\n-\t\twt_status_print_submodule_summary(s, 0);  /* staged */\n-\t\twt_status_print_submodule_summary(s, 1);  /* unstaged */\n+\t\twt_status_print_submodule_summary(s, 0, s->is_initial);  /* staged */\n+\t\twt_status_print_submodule_summary(s, 1, 0);  /* unstaged */\n \t}\n \tif (s->show_untracked_files)\n \t\twt_status_print_untracked(s);\n"},{"id":"136133","messageId":"fabb9a1e1003032201l38b052ebk4c0061e9d40f68b6@mail.gmail.com","threadId":"22893","inReplyTo":"4B8F00AA.5050007@web.de","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-03-04T06:01:52Z","receivedAt":"2010-03-04T06:01:52Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Mar 4, 2010 at 01:36, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> But to make \"git status\" with status.submodulesummary work as expected,\n> i need something like the following patch on top of current pu (because\n> \"git submodule summary --cached HEAD\" returns no changes in a freshly\n> created repo):\n\nI think the problem is deeper than that: git doesn't work that great\nif there's no HEAD yet. Some of our features don't work (as expected)\nif there's no HEAD. For example, 'git reset' doesn't work, of course,\nI can use 'git rm --cached .' to achieve the same effect (since all\nstaged changes are guaranteed to be adds), but its' not quite the\nsame. Perhaps it's an idea to look at how we handle not having a head\nacross the board and deal with it at a higher level? Something like\npretending we do have a HEAD that's pointing at the empty tree when on\nan unborn branch might fix 'git reset' (although I'm sure there's all\nkinds of objections to actually doing that, I'm not suggesting that's\nwhat we should do, but that's the kind of solution I think we should\nlook at).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"136134","messageId":"7vfx4gfvwv.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"fabb9a1e1003032201l38b052ebk4c0061e9d40f68b6@mail.gmail.com","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-04T06:22:40Z","receivedAt":"2010-03-04T06:22:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> ... pretending we do have a HEAD that's pointing at the empty tree when on\n> an unborn branch might fix 'git reset' ...\n\nI think \"git reset HEAD\" _should_ fail, but on the other hand, \"git reset\"\nand \"git reset paths...\" would be Ok before HEAD points at a commit.\n"},{"id":"136135","messageId":"fabb9a1e1003032236x59a781b8ne0266877db25d001@mail.gmail.com","threadId":"22893","inReplyTo":"7vfx4gfvwv.fsf@alter.siamese.dyndns.org","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-03-04T06:36:20Z","receivedAt":"2010-03-04T06:36:20Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Mar 4, 2010 at 07:22, Junio C Hamano <gitster@pobox.com> wrote:\n> I think \"git reset HEAD\" _should_ fail, but on the other hand, \"git reset\"\n> and \"git reset paths...\" would be Ok before HEAD points at a commit.\n\nYes, that's what I came up with after sending my email, commands that\n_default_ to HEAD as revision should instead default to an empty\ncommit when there is no HEAD yet. Perhaps something we can add to\nparse_opt and then make sure that all commands we care about use that\nfeature?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"136136","messageId":"7vvddcd1si.fsf@alter.siamese.dyndns.org","threadId":"22893","inReplyTo":"fabb9a1e1003032236x59a781b8ne0266877db25d001@mail.gmail.com","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-04T06:43:57Z","receivedAt":"2010-03-04T06:43:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> Yes, that's what I came up with after sending my email, commands that\n> _default_ to HEAD as revision should instead default to an empty\n> commit when there is no HEAD yet. Perhaps something we can add to\n> parse_opt and then make sure that all commands we care about use that\n> feature?\n\nI doubt it would be very much useful as a general feature, as sometimes we\ndefault to HEAD because we want a tree-ish (in which case using \"empty\ntree\" would be appropriate) and other times because we want an actual\ncommit (e.g. \"git commit --amend\" should exit, not \"amend an empty tree\")\nand we would need to be careful to study each codepath and use the\nappropriate one.\n\nBut you are welcome to try and prove me wrong with a working patch ;-).\n"},{"id":"136137","messageId":"fabb9a1e1003032248w4fb290capf1e45ed16a1ea0c4@mail.gmail.com","threadId":"22893","inReplyTo":"7vvddcd1si.fsf@alter.siamese.dyndns.org","subject":"Re: What should \"git submodule summary\" give before an initial commit?","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-03-04T06:48:10Z","receivedAt":"2010-03-04T06:48:10Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Mar 4, 2010 at 07:43, Junio C Hamano <gitster@pobox.com> wrote:\n> I doubt it would be very much useful as a general feature, as sometimes we\n> default to HEAD because we want a tree-ish (in which case using \"empty\n> tree\" would be appropriate) and other times because we want an actual\n> commit (e.g. \"git commit --amend\" should exit, not \"amend an empty tree\")\n> and we would need to be careful to study each codepath and use the\n> appropriate one.\n\nYes, I think if we add such a \"default to HEAD or empty tree\" option\nto parse_opt we shouldn't just plug it in anywhere we default to HEAD.\n\n> But you are welcome to try and prove me wrong with a working patch ;-).\n\nAh, I was hoping perhaps one of our still-in-hiding prospective gsoc\nstudents might feel up to the task, I am short on free time lately (I\nbarely have enough time for Melange), the little git time I do have is\nspent on adding write support to git-remote-hg. So! To all you people\nthat want to be a gsoc student for git, now's your \"opportune moment\"\nto impress us ;).\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}