{"thread":{"id":"56093","subject":"[GSoC] My Git Dev Blog – Week 8","startedAt":"2021-07-11T11:18:54Z","lastAt":"2021-07-19T07:04:24Z","messageCount":6,"participants":["Atharva Raykar","Kaartic Sivaraam","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"429679","messageId":"CD6968A1-179D-4B77-91C1-4EECB1B69951@gmail.com","threadId":"56093","inReplyTo":null,"subject":"[GSoC] My Git Dev Blog – Week 8","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-07-11T11:18:41Z","receivedAt":"2021-07-11T11:18:54Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"Here's my weekly update:\nhttps://atharvaraykar.me/gitnotes/week8\n\nI am currently blocked by trying to pass a super-prefix parameter\nto another command, when calling it from within C.\n\nIf you are interested in helping with that, this will take you to\nright to it:\nhttps://atharvaraykar.me/gitnotes/week8#path-pains\n\nHave a nice day.\n\n---\nAtharva Raykar\nಅಥರ್ವ ರಾಯ್ಕರ್\nअथर्व रायकर\n\n"},{"id":"429880","messageId":"f5b12a75-bdaf-fe5c-ffc2-7b4c8cdfddd6@gmail.com","threadId":"56093","inReplyTo":"CD6968A1-179D-4B77-91C1-4EECB1B69951@gmail.com","subject":"Re: [GSoC] My Git Dev Blog – Week 8","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2021-07-13T08:18:08Z","receivedAt":"2021-07-13T08:18:15Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Atharva,\n\nOn 11/07/21 4:48 pm, Atharva Raykar wrote:\n> Here's my weekly update:\n> https://atharvaraykar.me/gitnotes/week8\n> \n> I am currently blocked by trying to pass a super-prefix parameter\n> to another command, when calling it from within C.\n>\n\n From the blog:\n\n> When queried by the get_super_prefix() function, the answer is (null).\n> This boggles my mind to no end (see update). The implementation is basically\n> the same getenv() call?\n\nGood to see that you were able to identify the reason yourself.\n\n> I am not sure how to tell Git that the environment variable has in fact\n> been modified, and that it needs to be reinitialized. Maybe I am going\n> about this whole thing wrong?\n\nI get the same feeling too. I took a brief look at how the issue could be\nfixed and it seems to me that you exploring to set super-prefix might not\nlead us to the solution. Alternatively, you could explore how other sub-commands\nhandle recursing into submodules. To me it looks like they handle it by spawning\na sub-process is likely the easiest approach for achieving recursion. That would\nsolve the super-prefix problem as you have observed.\n\nUnfortunately, there's not yet proper support for handling recursion of submodules\nwhich calls for working with the data of multiple Git repositories in the same\nGit process. There was an effort[1] few years ago to make working with\nother Git repositories simpler without having to spawn a sub-process. The state\nof the effort is unclear to me. As far as I know, it has been stalled. I hope\nothers could provide more details about it.\n\nSo, you could try the approach of spawning of sub-process for now. In case there's\na better approach than spawning sub-process others might be able to point during\nreview. In the meanwhile, I'll try to take a better look later and see if I could\nfind anything.\n\n[1]: https://public-inbox.org/git/20180205235508.216277-1-sbeller@google.com/\n\n-- \nSivaraam\n"},{"id":"429882","messageId":"D3F13902-A7DD-4186-8444-45FD9260CBC8@gmail.com","threadId":"56093","inReplyTo":"f5b12a75-bdaf-fe5c-ffc2-7b4c8cdfddd6@gmail.com","subject":"Re: [GSoC] My Git Dev Blog – Week 8","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-07-13T08:46:14Z","receivedAt":"2021-07-13T08:46:20Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"On 13-Jul-2021, at 13:48, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:\n> \n> Hi Atharva,\n> \n> On 11/07/21 4:48 pm, Atharva Raykar wrote:\n>> Here's my weekly update:\n>> https://atharvaraykar.me/gitnotes/week8\n>> I am currently blocked by trying to pass a super-prefix parameter\n>> to another command, when calling it from within C.\n>> \n> \n> From the blog:\n> \n>> When queried by the get_super_prefix() function, the answer is (null).\n>> This boggles my mind to no end (see update). The implementation is basically\n>> the same getenv() call?\n> \n> Good to see that you were able to identify the reason yourself.\n> \n>> I am not sure how to tell Git that the environment variable has in fact\n>> been modified, and that it needs to be reinitialized. Maybe I am going\n>> about this whole thing wrong?\n> \n> I get the same feeling too. I took a brief look at how the issue could be\n> fixed and it seems to me that you exploring to set super-prefix might not\n> lead us to the solution. Alternatively, you could explore how other sub-commands\n> handle recursing into submodules. To me it looks like they handle it by spawning\n> a sub-process is likely the easiest approach for achieving recursion. That would\n> solve the super-prefix problem as you have observed.\n\nYes, I was hoping I would not have to spawn a subprocess for recursing on\nupdate, and it does look theoretically possible--it would require changing\na lot of of existing code to use functions taking a repository objects\nrather than assuming 'the_repository'. But since that was outside the scope\nof my project, I did it like the other implementations that spawned a new\nprocess for the recursion of 'update'.\n\n> Unfortunately, there's not yet proper support for handling recursion of submodules\n> which calls for working with the data of multiple Git repositories in the same\n> Git process. There was an effort[1] few years ago to make working with\n> other Git repositories simpler without having to spawn a sub-process. The state\n> of the effort is unclear to me. As far as I know, it has been stalled. I hope\n> others could provide more details about it.\n> \n> So, you could try the approach of spawning of sub-process for now. In case there's\n> a better approach than spawning sub-process others might be able to point during\n> review. In the meanwhile, I'll try to take a better look later and see if I could\n> find anything.\n\nI was seeing if it was possible to at least save another spawn for calling\ninit when '--init' is provided for an update. The current implementation\ndoes not spawn a separate process for this, so I was hoping I don't add\nmore overhead in the conversion, but it's looking hard to avoid at the\nmoment.\n\n> [1]: https://public-inbox.org/git/20180205235508.216277-1-sbeller@google.com/\n> \n> -- \n> Sivaraam\n\n\n"},{"id":"430462","messageId":"CAP8UFD1bGm8r_M9_gLEtSf3EAKseHySJWhMOoJjGO4xy6R2+9Q@mail.gmail.com","threadId":"56093","inReplyTo":"D3F13902-A7DD-4186-8444-45FD9260CBC8@gmail.com","subject":"Re: [GSoC] My Git Dev Blog – Week 8","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2021-07-18T09:26:48Z","receivedAt":"2021-07-18T09:27:11Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jul 13, 2021 at 10:46 AM Atharva Raykar <raykar.ath@gmail.com> wrote:\n>\n> On 13-Jul-2021, at 13:48, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:\n\n> > ... Alternatively, you could explore how other sub-commands\n> > handle recursing into submodules. To me it looks like they handle it by spawning\n> > a sub-process is likely the easiest approach for achieving recursion. That would\n> > solve the super-prefix problem as you have observed.\n>\n> Yes, I was hoping I would not have to spawn a subprocess for recursing on\n> update, and it does look theoretically possible--it would require changing\n> a lot of of existing code to use functions taking a repository objects\n> rather than assuming 'the_repository'. But since that was outside the scope\n> of my project, I did it like the other implementations that spawned a new\n> process for the recursion of 'update'.\n\nYeah, it's definitely outside the scope of your project. So it's ok to\nspawn a new process.\n"},{"id":"430467","messageId":"623770cb-d692-f61f-180a-33145caea97a@gmail.com","threadId":"56093","inReplyTo":"D3F13902-A7DD-4186-8444-45FD9260CBC8@gmail.com","subject":"Re: [GSoC] My Git Dev Blog – Week 8","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2021-07-18T17:39:59Z","receivedAt":"2021-07-18T17:40:05Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Atharva,\n\nOn 13/07/21 2:16 pm, Atharva Raykar wrote:\n> \n> I was seeing if it was possible to at least save another spawn for calling\n> init when '--init' is provided for an update. The current implementation\n> does not spawn a separate process for this, so I was hoping I don't add\n> more overhead in the conversion, but it's looking hard to avoid at the\n> moment.\n> \n\nI'm having some difficulties understanding this. I tried to take a look\nat the existing code[2][3] in 'git-submodule.sh', I could only see that\nif '--init' is passed to update, it calls the 'cmd_update' shell function\nwhich in turn does invoke 'git submodule--helper init'. OTOH, if '--recursive'\nis passed 'cmd_update' itself is called recursively called after setting\nthe 'prefix' and 'wt_prefix' shell variables.\n\nSo, I'm not sure how you mean to say that a sub-process was not spawned\nwhen '--init' is passed. Could you clarify this a little?\n\n>> [1]: https://public-inbox.org/git/20180205235508.216277-1-sbeller@google.com/\n>>\n\n[2]: https://github.com/git/git/blob/abb21c7263616f01c5e950861a29279ab21cb02f/git-submodule.sh#L530-L533\n\n[3]: https://github.com/git/git/blob/abb21c7263616f01c5e950861a29279ab21cb02f/git-submodule.sh#L651-L673\n\n-- \nSivaraam\n"},{"id":"430475","messageId":"C8229C5F-1F47-4D44-A6C0-B291AF9BF612@gmail.com","threadId":"56093","inReplyTo":"623770cb-d692-f61f-180a-33145caea97a@gmail.com","subject":"Re: [GSoC] My Git Dev Blog – Week 8","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-07-19T07:04:05Z","receivedAt":"2021-07-19T07:04:24Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"On 18-Jul-2021, at 23:09, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:\n> \n> Hi Atharva,\n> \n> On 13/07/21 2:16 pm, Atharva Raykar wrote:\n>> I was seeing if it was possible to at least save another spawn for calling\n>> init when '--init' is provided for an update. The current implementation\n>> does not spawn a separate process for this, so I was hoping I don't add\n>> more overhead in the conversion, but it's looking hard to avoid at the\n>> moment.\n> \n> I'm having some difficulties understanding this. I tried to take a look\n> at the existing code[2][3] in 'git-submodule.sh', I could only see that\n> if '--init' is passed to update, it calls the 'cmd_update' shell function\n> which in turn does invoke 'git submodule--helper init'. OTOH, if '--recursive'\n> is passed 'cmd_update' itself is called recursively called after setting\n> the 'prefix' and 'wt_prefix' shell variables.\n> \n> So, I'm not sure how you mean to say that a sub-process was not spawned\n> when '--init' is passed. Could you clarify this a little?\n> \n>>> [1]: https://public-inbox.org/git/20180205235508.216277-1-sbeller@google.com/\n>>> \n> \n> [2]: https://github.com/git/git/blob/abb21c7263616f01c5e950861a29279ab21cb02f/git-submodule.sh#L530-L533\n> \n> [3]: https://github.com/git/git/blob/abb21c7263616f01c5e950861a29279ab21cb02f/git-submodule.sh#L651-L673\n\nMy mistake. When I wrote that paragraph, I had considered the shell call\nin my head to be \"git submodule init\" and not \"git submodule--helper init\".\n\nIn the former case, there would be an extra subprocess because\n'submodule init' will in turn spawn 'submodule--helper init'. So in short,\nthere would have been no difference between the two versions had I gone\ndown that route."}]}