On 13-Jul-2021, at 13:48, Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> 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@xxxxxxxxxx/ > > -- > Sivaraam
