Re: [GSoC] The Final Git Dev Blog(s)

[Atharva Raykar <raykar.ath@gmail.com>]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> On 20/08/21 8:05 pm, Atharva Raykar wrote:
>> Hello Git Developers,
>> This is my last week with Git under the Google Summer of Code banner.
>> This week's update will be different from usual, as I have split it into
>> two separate posts.
>> These are:
>> 1. The Technical Report: https://atharvaraykar.me/gitnotes/final-report
>>     This is a largely impersonal report that describes the current status
>>     of my work.
>>     Mentors: this is what I will be submitting to Google as my final work
>>     product.
>
> Thanks for the report! It's well written. Some comments:
>
>> Portability: Non-POSIX systems like Windows don’t play nice with shell
>> script commands like grep, cd and printf, to name a few, and these
>> commands have to be reimplemented for the system. There are also
>> POSIX to Windows path conversion issues.
>
> I wonder if that's a valid claim. The shell script version of the
> commands use a lot of *nix utilities to achieve their goal. This comes
> as a hindrance to run the corresponding commands on other platforms such
> as Windows which don't have these utilities. That doesn't mean those
> platforms implement those utilities for their platforms. From what
> I know,They just use an emulation layer in which the *nix commands would
> be available. Using an emulation layer is costly and not an ideal solution.

Maybe I didn't phrase it well enough. Maybe doing a
s/reimplemented/emulated at a cost/ would fix it?

(Welp, unfortunately I cannot edit the GSoC project description which
has this same text. That blooper would be set in stone.)

>> Miscellaneous
>
> You could consider mentioning that the first two changes have been merged
> to the 'master' and possibly also link to the corresponding commits.

Okay.

>> Structuring Patches
>
> Structuring was indeed an overarching theme your work.
>  > This taught me how effective communication makes software scale—your
>> changes should tell a story that’s easy to follow, so that the code
>> can easily be picked up by others by a mere examination of its
>> commit and list history.
>
> Good point.
>
> Speaking about structuring, I must mentioned that the structuring approach
> has paid off very well till now. I'm inferring this from the fact that
> the reviewers haven't expressed any concerns about patches being too
> long-ish to review. Having taken a look at the patches that aren't on
> list yet, they seem to be structured well for ease of review too.
> So, good job!

Yes, the strategy has worked well so far. I would say my only major
error was holding onto some of the patches for too long, because I did
not still have the right idea for when to send the next series.

>> What I learned over the course of this project
>
> Good to see that you had some good learnings from the project. :-)
>
>> Do let me know if it is missing anything.
>
> I don't think you missed anything. There's one thing which might
> be worth including in the report, though. You could have a section
> called "Organization of the work" or something like that which
> gives some details about the branches that contain your work and
> clarify which ones are still relevant at this point. This could
> help future readers (including you!) to quickly get an idea of
> the branches and code in your fork.

This is a good idea. I will update that blog post soon. The blog's home
used to have that but I did a poor job of keeping that up to date.