Re: [GSoC] Shourya's Blog

> Some things I noted in the blog:
> 
> > As far as I have learned, summary prints a git log --oneline
> > between the revision checked out in the submodule and the
> > revision superproject assumed the submodule to be in (i.e.,
> > the one checked out in the superproject).
> 
> The explanation is pretty close. The wording could be tweaked a little
> to be more precise. Particularly "assume" isn't a proper word to
> explain the working of summary. It works based on facts not
> assumptions. Something along the lines of:

>     As far as I have learned, summary prints a git log --oneline
>     between the revision checked out in the submodule and the revision
>     "known" to the superproject (i.e., the revision found in the index
>     of the superproject).
> 
> >  If no revision is specified of the submodule then we assume it to be HEAD
> 
> As discussed elsewhere, the revision passed to the summary command is
> the revision of the superproject and not the revision of the submodule.

> > $ git submodule summary my-subm
> >   * my-subm abc123..def456
> >     < some commit
> >     < another commit
> >     < some another commit 
> 
> While the command above would produce the result you mention when
> 'my-subm' in the repo. The command itself is incorrect if it's
> intention is to print "only" the summary of 'my-subm'. This is the
> format of the 'summary' sub-command according to the doc:
> 
>     summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--]
> [<path>...]
> 
> So, it expects a 'commit' followed by the 'path'. As you had passed the
> path as the first argument it would be treated as the 'commit' argument.
> As 'my-subm' is likely not a valid commit-ish, the script would
> default to 'HEAD' (the final else mentioned below) and would
> print the summary of all the submodules. IOW, it just prints the
> same output as:
> 
>    $ git submodule summary
> 
> in this case.

> > else
> > 	head="HEAD"
> > fi
> >
> > This means that if the above 2 cases fail (which will most probably
> > lead to presence of commits yet a failure in git rev-parse --verify)
> > then make head as HEAD.
> 
> Characterising 'git rev-parse --verify ...' as not being able to print
> the hash of a commit even when there is one in the repo seems incorrect
> to me. There are other more likely cases which would lead to rev-parse
> failing and that last else part getting executed. For instance, an
> incorrect ref being passed as the first argument to the summary
> sub-command like:
> 
>     git submodule summary no-such-ref-exists
> 
> or
>      git submodule summary "invalid ref"