Re: What should "git submodule summary" give before an initial commit?

> "git status" collects the changes for both the index (since HEAD) and the
> working tree files (since the index), summarizes and shows them.  When it
> is run before the first commit is made, it uses a logic different from
> the one used in the normal case to gather the information on the index,
> as we don't have HEAD yet, i.e. instead of "diff-index HEAD", we would
> run "diff-index emtpy-tree".
> 
> How should status.submodulesummary integrate into this framework?
> 
> Currently, it blindly runs "git submodule summary", and it gives an extra
> error message about HEAD not being a commit, and people (me included)
> misguidedly have spent time on squelching the message.
> 
> But I think that was _all wrong_.  I do not think "git submodule summary"
> should fail even when you haven't made your first commit.
> 
> If you are before the first commit, we say everything you have in the
> index is a change you are adding with your next commit (which will be
> your initial one).  If you added a submodule commit to the index,
> shouldn't "git submodule summary" say "you'll be committing the addition
> of this subproject"?  IOW, shouldn't we be comparing an empty tree to
> find added submodules, like this, when we haven't made the first commit?
> 
>  git-submodule.sh |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 5869c00..0397f9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -556,10 +556,10 @@ cmd_summary() {
>  	if rev=$(git rev-parse -q --verify --default HEAD ${1+"$1"})
>  	then
>  		head=$rev
> -		shift
> +		test $# = 0 || shift
>  	elif test -z "$1" -o "$1" = "HEAD"
>  	then
> -		return
> +		head=4b825dc642cb6eb9a060e54bf8d69288fbee4904
>  	else
>  		head="HEAD"
>  	fi