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

Kaartic Sivaraam [off-list ref] writes:

On 20/08/21 8:05 pm, Atharva Raykar wrote:

quoted

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:

quoted

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

quoted

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.

quoted

Structuring Patches

Structuring was indeed an overarching theme your work.
 > This taught me how effective communication makes software scale—your

quoted

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.

quoted

What I learned over the course of this project

Good to see that you had some good learnings from the project. :-)

quoted

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.