Re: [GSOC Proposal] Complete and extend the remote-object-info command for git cat-file

[SoutrikDas <valusoutrik@gmail.com>]

Hi there,

> As far as I can recall, the command allowed users to enter multiple OIDs
> in a single line to reduce the to-fro with the server. But you could
> still fetch single OID info.

Yeah that was what I meant, but from Chistian Couder's feedback, I realized
that cat-file is not a good home for such a subcommand. 

> Nice, have you tried with a more recent 'master'? I assume there are
> merge conflicts?

Yup, I will add these issues in my proposal v2.

> Any idea how much work is left post v11?

From the v11 thread 
- a lot of design decision fix , like comment alignment and blank lines
- the max remote obj info logic is a bit wrong as Junio pointed out [1]
- one test case for max obj limit
- use of size_t for looping
- the placeholder check ie the even with only objectsize the checking of
formatting string is a bit incorrect [2]
- Implementing an allow list for placeholders
- print empty string for unsupported placeholders, ie those not on the
allow list
- remove usage of split_cmdline since neither url nor oid will have spaces
in them, so a strchr would suffice, I think ?

Above is for just for part 1 ie to get eric jus patch accepted

> As per the guidelines, it says
> 
>   Any work done on the Project prior to acceptance of the Project
>   Proposal will not be considered for Evaluations.

I meant like in the May 1-24 duration, which is after the acceptance
of the project ( april 30 ) but before coding officially begins (may 25)

This is the timeline on gsocs page [3]:
> April 30 - 18:00 UTC
>   Accepted GSoC contributor projects announced
> May 1 - 24
>   Community Bonding Period | GSoC contributors get to know mentors, 
>   read documentation, get up to speed to begin working on their projects
> May 25
>   Coding officially begins!

I was planning to also ask design questions in this period.

> How will you manage reviews, considering generally they take a long
> time?

I will adjust the timeline to give more time to rebase previously done work.
I was wondering... I cannot start on part 2 ie adding support for more object
fields without first integrating old work ... so about 50% of time will go to
rebasing and 30% to adding new fields ? and 20% for emergency or any mishap.

> I do agree that something like that would be useful indeed, I'm not sure
> of what that design looks like though.
> I do see benefits of this too. But I do wonder if 'git rev-list' is a
> better command for something like this.

I will clarify questions at the beginning of gsoc duration.


> What I missed from the proposal:
> 1. Where did the work from Eric and Calvin stop at, what review comments
> need to be addressed.
> 2. How do you plan to handle reviews and iterations taking time.

Will update the timeline as well as mention the current outstanding tasks,
as far as I have understood them.

Thank you for your feedback.


[1] : xmqqo6yr3wc4.fsf@gitster.g/
[2] : 20250224234720.GC729825@coredump.intra.peff.net/
[3] : https://developers.google.com/open-source/gsoc/timeline