{"thread":{"id":"53690","subject":"[GSoC] Shourya's Blog","startedAt":"2020-06-16T07:21:18Z","lastAt":"2020-06-20T06:55:23Z","messageCount":4,"participants":["Shourya Shukla","Kaartic Sivaraam","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"399849","messageId":"20200616072108.GA10273@konoha","threadId":"53690","inReplyTo":null,"subject":"[GSoC] Shourya's Blog","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-06-16T07:21:08Z","receivedAt":"2020-06-16T07:21:18Z","isPatch":false,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"Hello all!\n\nThis is the sixth installation of my weekly blog covering what I have\nlearned in GSoC and other like stuff.\nhttps://shouryashukla.blogspot.com/2020/06/gsoc-week-55.html\n\nFeel free to comment!\n\nRegards,\nShourya Shukla\n"},{"id":"399960","messageId":"c88fe426-eac7-8d77-ec9b-9cb6d8dfc9f9@gmail.com","threadId":"53690","inReplyTo":"20200616072108.GA10273@konoha","subject":"Re: [GSoC] Shourya's Blog","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2020-06-17T08:38:42Z","receivedAt":"2020-06-17T08:38:48Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Shourya,\n\nOn 16-06-2020 12:51, Shourya Shukla wrote:\n> Hello all!\n> \n> This is the sixth installation of my weekly blog covering what I have\n> learned in GSoC and other like stuff.\n> https://shouryashukla.blogspot.com/2020/06/gsoc-week-55.html\n> \n> Feel free to comment!\n> \n\nSome things I noted in the blog:\n\n> As far as I have learned, summary prints a git log --oneline\n> between the revision checked out in the submodule and the\n> revision superproject assumed the submodule to be in (i.e.,\n> the one checked out in the superproject).\n\nThe explanation is pretty close. The wording could be tweaked a little\nto be more precise. Particularly \"assume\" isn't a proper word to\nexplain the working of summary. It works based on facts not\nassumptions. Something along the lines of:\n\n    As far as I have learned, summary prints a git log --oneline\n    between the revision checked out in the submodule and the revision\n    \"known\" to the superproject (i.e., the revision found in the index\n    of the superproject).\n\n>  If no revision is specified of the submodule then we assume it to be HEAD\n\nAs discussed elsewhere, the revision passed to the summary command is\nthe revision of the superproject and not the revision of the submodule.\n\n> $ git submodule summary my-subm\n>   * my-subm abc123..def456\n>     < some commit\n>     < another commit\n>     < some another commit \n\nWhile the command above would produce the result you mention when\n'my-subm' in the repo. The command itself is incorrect if it's\nintention is to print \"only\" the summary of 'my-subm'. This is the\nformat of the 'summary' sub-command according to the doc:\n\n    summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--]\n[<path>...]\n\nSo, it expects a 'commit' followed by the 'path'. As you had passed the\npath as the first argument it would be treated as the 'commit' argument.\nAs 'my-subm' is likely not a valid commit-ish, the script would\ndefault to 'HEAD' (the final else mentioned below) and would\nprint the summary of all the submodules. IOW, it just prints the\nsame output as:\n\n   $ git submodule summary\n\nin this case.\n\n> elif test -z \"$1\" || test \"$1\" = \"HEAD\"\n> then\n> \t# before the first commit: compare with an empty tree\n> \thead=$(git hash-object -w -t tree --stdin </dev/null)\n> \ttest -z \"$1\" || shift\n> \n> This part checks if there are any commits in our tree (of the submodule) or not.\n\nAgain, it's the tree of the superproject that we're concerned about.\n\n> If there aren’t any commits then it simulates an empty repo environment\n> using head=$(git hash-object -w -t tree --stdin </dev/null). The\n> /dev/null is the UNIX null device and is sort of a blackhole meaning\n> things if gone into it completely disappear never to be seen again.\n\nFine. As we're using '/dev/null' as an input here. It would've been nice\nif you had also mentioned that it serves as a \"convenient empty file for\ninput streams\"[1] because \"reads from /dev/null always return end of\nfile\"[2].\n\n> Making stdin as /dev/null means giving nothing as input hence\n> nothing to create a hash object of.\n\nNot precise. That command would return the hash of an empty tree.\n\n> else\n> \thead=\"HEAD\"\n> fi\n>\n> This means that if the above 2 cases fail (which will most probably\n> lead to presence of commits yet a failure in git rev-parse --verify)\n> then make head as HEAD.\n\nCharacterising 'git rev-parse --verify ...' as not being able to print\nthe hash of a commit even when there is one in the repo seems incorrect\nto me. There are other more likely cases which would lead to rev-parse\nfailing and that last else part getting executed. For instance, an\nincorrect ref being passed as the first argument to the summary\nsub-command like:\n\n    git submodule summary no-such-ref-exists\n\nor\n\n    git submodule summary \"invalid ref\"\n\nSo, I think it would've been precise to just say:\n\n    This means that if the above 2 cases fail then we make\n    head as HEAD.\n\n[1]: https://en.wikipedia.org/wiki/Null_device\n[2]: https://man7.org/linux/man-pages/man4/null.4.html\n\n-- \nSivaraam\n"},{"id":"400001","messageId":"xmqq4kr9toqi.fsf@gitster.c.googlers.com","threadId":"53690","inReplyTo":"20200616072108.GA10273@konoha","subject":"Re: [GSoC] Shourya's Blog","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-17T20:35:17Z","receivedAt":"2020-06-17T20:35:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shourya Shukla <shouryashukla.oo@gmail.com> writes:\n\n> Hello all!\n>\n> This is the sixth installation of my weekly blog covering what I have\n> learned in GSoC and other like stuff.\n> https://shouryashukla.blogspot.com/2020/06/gsoc-week-55.html\n>\n> Feel free to comment!\n\nThis like looked unusual:\n\n    var1=${var1:=$var2}\n\nWhat's inside ${...} is sufficient to assing to var1 when it is not\nuset or set to an empty string.  It is far more common to say\n\n    : ${var1:=$var2}\n\nwith or without the colon in front of the equal sign (which tells\nthe construct to treat \"set to empty\" the same way as \"unset\").\n\n"},{"id":"400249","messageId":"20200620065512.GA15019@konoha","threadId":"53690","inReplyTo":"c88fe426-eac7-8d77-ec9b-9cb6d8dfc9f9@gmail.com","subject":"Re: [GSoC] Shourya's Blog","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-06-20T06:55:12Z","receivedAt":"2020-06-20T06:55:23Z","isPatch":false,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"On 17/06 02:08, Kaartic Sivaraam wrote:\n> Some things I noted in the blog:\n> \n> > As far as I have learned, summary prints a git log --oneline\n> > between the revision checked out in the submodule and the\n> > revision superproject assumed the submodule to be in (i.e.,\n> > the one checked out in the superproject).\n> \n> The explanation is pretty close. The wording could be tweaked a little\n> to be more precise. Particularly \"assume\" isn't a proper word to\n> explain the working of summary. It works based on facts not\n> assumptions. Something along the lines of:\n\nThanks for the feedback. I couldn't think of a word back then! Will make\namends.\n\n>     As far as I have learned, summary prints a git log --oneline\n>     between the revision checked out in the submodule and the revision\n>     \"known\" to the superproject (i.e., the revision found in the index\n>     of the superproject).\n> \n> >  If no revision is specified of the submodule then we assume it to be HEAD\n> \n> As discussed elsewhere, the revision passed to the summary command is\n> the revision of the superproject and not the revision of the submodule.\n\nAlright! Will amend.\n\n> > $ git submodule summary my-subm\n> >   * my-subm abc123..def456\n> >     < some commit\n> >     < another commit\n> >     < some another commit \n> \n> While the command above would produce the result you mention when\n> 'my-subm' in the repo. The command itself is incorrect if it's\n> intention is to print \"only\" the summary of 'my-subm'. This is the\n> format of the 'summary' sub-command according to the doc:\n> \n>     summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--]\n> [<path>...]\n> \n> So, it expects a 'commit' followed by the 'path'. As you had passed the\n> path as the first argument it would be treated as the 'commit' argument.\n> As 'my-subm' is likely not a valid commit-ish, the script would\n> default to 'HEAD' (the final else mentioned below) and would\n> print the summary of all the submodules. IOW, it just prints the\n> same output as:\n> \n>    $ git submodule summary\n> \n> in this case.\n\nI just took the case of only one submodule existing in the superproject.\nThough even my output isn't wrog, the path taken to achieve it is a bit\nambiguous. I will change it.\n\n> > else\n> > \thead=\"HEAD\"\n> > fi\n> >\n> > This means that if the above 2 cases fail (which will most probably\n> > lead to presence of commits yet a failure in git rev-parse --verify)\n> > then make head as HEAD.\n> \n> Characterising 'git rev-parse --verify ...' as not being able to print\n> the hash of a commit even when there is one in the repo seems incorrect\n> to me. There are other more likely cases which would lead to rev-parse\n> failing and that last else part getting executed. For instance, an\n> incorrect ref being passed as the first argument to the summary\n> sub-command like:\n> \n>     git submodule summary no-such-ref-exists\n> \n> or\n>      git submodule summary \"invalid ref\"\n\nOh! I did not think this one! I will change this too. Thank you so much\nfor pointing this out.\n\nRegards,\nShourya Shukla\n"}]}