list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Shourya Shukla <>
To: Kaartic Sivaraam <>
Subject: Re: [GSoC] Shourya's Blog
Date: Sat, 20 Jun 2020 12:25:12 +0530	[thread overview]
Message-ID: <20200620065512.GA15019@konoha> (raw)
In-Reply-To: <>

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

>     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.

Shourya Shukla

  reply	other threads:[~2020-06-20  6:55 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
2020-06-20  6:55   ` Shourya Shukla [this message]
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 \
    --in-reply-to=20200620065512.GA15019@konoha \ \ \ \ \ \
    --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).