On 17/06 02:08, Kaartic Sivaraam wrote: > 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: Thanks for the feedback. I couldn't think of a word back then! Will make amends. > 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. Alright! Will amend. > > $ 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. I just took the case of only one submodule existing in the superproject. Though even my output isn't wrog, the path taken to achieve it is a bit ambiguous. I will change it. > > 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" Oh! I did not think this one! I will change this too. Thank you so much for pointing this out. Regards, Shourya Shukla
