git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Shourya Shukla <shouryashukla.oo@gmail.com>
To: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Cc: christian.couder@gmail.com, git@vger.kernel.org, gitster@pobox.com
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: <c88fe426-eac7-8d77-ec9b-9cb6d8dfc9f9@gmail.com>

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

  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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20200620065512.GA15019@konoha \
    --to=shouryashukla.oo@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kaartic.sivaraam@gmail.com \
    --subject='Re: [GSoC] Shourya'\''s Blog' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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:

	https://80x24.org/mirrors/git.git

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