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
next prev parent 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 [GSoC] Shourya's Blog 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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).