Re: [GSoC] My Git Dev Blog – Week 8

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

On 13-Jul-2021, at 13:48, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> 
> Hi Atharva,
> 
> On 11/07/21 4:48 pm, Atharva Raykar wrote:
>> Here's my weekly update:
>> https://atharvaraykar.me/gitnotes/week8
>> I am currently blocked by trying to pass a super-prefix parameter
>> to another command, when calling it from within C.
>> 
> 
> From the blog:
> 
>> When queried by the get_super_prefix() function, the answer is (null).
>> This boggles my mind to no end (see update). The implementation is basically
>> the same getenv() call?
> 
> Good to see that you were able to identify the reason yourself.
> 
>> I am not sure how to tell Git that the environment variable has in fact
>> been modified, and that it needs to be reinitialized. Maybe I am going
>> about this whole thing wrong?
> 
> I get the same feeling too. I took a brief look at how the issue could be
> fixed and it seems to me that you exploring to set super-prefix might not
> lead us to the solution. Alternatively, you could explore how other sub-commands
> handle recursing into submodules. To me it looks like they handle it by spawning
> a sub-process is likely the easiest approach for achieving recursion. That would
> solve the super-prefix problem as you have observed.

Yes, I was hoping I would not have to spawn a subprocess for recursing on
update, and it does look theoretically possible--it would require changing
a lot of of existing code to use functions taking a repository objects
rather than assuming 'the_repository'. But since that was outside the scope
of my project, I did it like the other implementations that spawned a new
process for the recursion of 'update'.

> Unfortunately, there's not yet proper support for handling recursion of submodules
> which calls for working with the data of multiple Git repositories in the same
> Git process. There was an effort[1] few years ago to make working with
> other Git repositories simpler without having to spawn a sub-process. The state
> of the effort is unclear to me. As far as I know, it has been stalled. I hope
> others could provide more details about it.
> 
> So, you could try the approach of spawning of sub-process for now. In case there's
> a better approach than spawning sub-process others might be able to point during
> review. In the meanwhile, I'll try to take a better look later and see if I could
> find anything.

I was seeing if it was possible to at least save another spawn for calling
init when '--init' is provided for an update. The current implementation
does not spawn a separate process for this, so I was hoping I don't add
more overhead in the conversion, but it's looking hard to avoid at the
moment.

> [1]: https://public-inbox.org/git/20180205235508.216277-1-sbeller@google.com/
> 
> -- 
> Sivaraam