list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Kaartic Sivaraam <>
To: Shourya Shukla <>
Subject: Re: [GSoC] Shourya's Blog
Date: Wed, 17 Jun 2020 14:08:42 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20200616072108.GA10273@konoha>

Hi Shourya,

On 16-06-2020 12:51, Shourya Shukla wrote:
> Hello all!
> This is the sixth installation of my weekly blog covering what I have
> learned in GSoC and other like stuff.
> Feel free to comment!

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] [--]

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.

> elif test -z "$1" || test "$1" = "HEAD"
> then
> 	# before the first commit: compare with an empty tree
> 	head=$(git hash-object -w -t tree --stdin </dev/null)
> 	test -z "$1" || shift
> This part checks if there are any commits in our tree (of the submodule) or not.

Again, it's the tree of the superproject that we're concerned about.

> If there aren’t any commits then it simulates an empty repo environment
> using head=$(git hash-object -w -t tree --stdin </dev/null). The
> /dev/null is the UNIX null device and is sort of a blackhole meaning
> things if gone into it completely disappear never to be seen again.

Fine. As we're using '/dev/null' as an input here. It would've been nice
if you had also mentioned that it serves as a "convenient empty file for
input streams"[1] because "reads from /dev/null always return end of

> Making stdin as /dev/null means giving nothing as input hence
> nothing to create a hash object of.

Not precise. That command would return the hash of an empty tree.

> 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


    git submodule summary "invalid ref"

So, I think it would've been precise to just say:

    This means that if the above 2 cases fail then we make
    head as HEAD.



  reply	other threads:[~2020-06-17  8:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16  7:21 Shourya Shukla
2020-06-17  8:38 ` Kaartic Sivaraam [this message]
2020-06-20  6:55   ` Shourya Shukla
2020-06-17 20:35 ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2020-08-24  7:50 Shourya Shukla
2020-08-05 17:46 Shourya Shukla
2020-08-14  7:14 ` Christian Couder
2020-07-28 10:11 Shourya Shukla
2020-07-14 22:10 Shourya Shukla
2020-07-05 18:38 Shourya Shukla
2020-06-28  9:39 Shourya Shukla
2020-06-23 18:14 Shourya Shukla
2020-05-27 16:20 Shourya Shukla
2020-05-28 13:15 ` Kaartic Sivaraam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [GSoC] Shourya'\''s Blog' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).