git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Atharva Raykar <raykar.ath@gmail.com>
Date
Jul 13, 2021, 08:46 UTC
Message-ID
<D3F13902-A7DD-4186-8444-45FD9260CBC8@gmail.com>
In-Reply-To
<f5b12a75-bdaf-fe5c-ffc2-7b4c8cdfddd6@gmail.com>
On 13-Jul-2021, at 13:48, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
Show 28 quoted lines
> 
> 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'.

Show 11 quoted lines
> 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
Previous: Kaartic SivaraamNext: Christian Couder
Message 3 of 6 in “[GSoC] My Git Dev Blog – Week 8”
  1. Atharva RaykarJul 11, 2021
  2. Kaartic SivaraamJul 13, 2021
  3. Atharva RaykarJul 13, 2021
  4. Christian CouderJul 18, 2021
  5. Kaartic SivaraamJul 18, 2021
  6. Atharva RaykarJul 19, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.