From: Atharva Raykar <raykar.ath@gmail.com>
To: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Christian Couder <christian.couder@gmail.com>,
Shourya Shukla <periperidip@gmail.com>
Subject: Re: My Git Dev Blog - Week 9
Date: Mon, 19 Jul 2021 14:18:50 +0530 [thread overview]
Message-ID: <6A97A724-4B80-4DDC-B5D2-83F8AD0B27EF@gmail.com> (raw)
In-Reply-To: <a8122438-8d8b-9e7d-d66a-dc6eff7a0817@gmail.com>
On 19-Jul-2021, at 08:28, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
>
> Hi Atharva and all,
>
> On 19/07/21 12:49 am, Kaartic Sivaraam wrote:
>> On 18/07/21 5:29 pm, Atharva Raykar wrote:
>>> Passing the superprefix explicitly
>> My gut instinct tells me we could get away without having to go this way but
>> I haven't yet been able to figure out how. How 'prefix', 'super-prefix' and
>> 'recursive-prefix' is still puzzling me. In case anyone has knowledge about
>> this please chime in and enlighten us. It would be very helpful.
>>
>
> I just noticed I was short and unhelpful here. To expand on what information would be
> helpful on this respect, here's a snippet of a private e-mail I sent which I've
> tweaked a little to make it relevant for the list audience:
>
> -- 8< --
>>> ...
>>>
>
> I took a look at this. I'm not able to find the exact issue but my gut instinct tells me
> it has something to do with how prefix, super-prefix and recursive-prefix
> are handled before and after the conversion. To be more specific, I'm having doubts
> about whether the following code snippet[4] in shell ...
>
> prefix=$(git submodule--helper relative-path "$prefix$sm_path/" "$wt_prefix")
> wt_prefix=
> sanitize_submodule_env
> cd "$sm_path" &&
> eval cmd_update
>
> ... has been properly converted to C. Particularly, the fact that recursive calls to
> 'cmd_update' is made in the existing shell implementation in case '--recusive' is
> passed needs to be observed well. This would subsequently result in multiple calls to
> 'cmd_init' with different 'prefix' and 'wt_prefix' values. So, that needs to be
> observed well too.
The whole deal with prefixes confused me initially a lot as well, so I'll try to
explain what's going on there first, and then show why I had trouble with it.
The terminology of 'recursive-prefix' was something I borrowed from the update-clone
helper[5]. Just to give you a summary of which shell variable maps to which C
variable, along with my understanding of what they represent:
| shell | C | description |
|------------+------------------+-------------------------------------------|
| $prefix | recursive_prefix | this represents the superproject prefix, |
| | | ie, the path of the superproject relative |
| | | to the current subproject. |
| | | |
| $wt_prefix | prefix | this is the path into the working tree, |
| | | ie, the path of the directory from the |
| | | root of the git directory's worktree |
The display paths that are generated for the error messages require one of these to
be non-NULL, but not both[6].
I feel confident the values of the various prefixes are handled properly during the
recursion because I setup a new worktree on based master as my "control", and a
combination of running with GIT_TRACE2 and printing the values showed me that both
of them handle the prefixes identically.
The issue with the subprocess approach[7] seems to be not with the prefixes, but
rather with the configuration not being properly read when it is set in the same
command invocation.
[5] https://github.com/git/git/blob/75ae10bc75336db031ee58d13c5037b929235912/git-submodule.sh#L536-L550
[6] https://github.com/git/git/blob/75ae10bc75336db031ee58d13c5037b929235912/builtin/submodule--helper.c#L258-L260
[7] https://github.com/tfidfwastaken/git/commits/submodule-helper-update-1a
> I have not been able to get a complete picture of this myself. I'll try to take better
> look later and see if I could get anything.
>
> Note that this could also be me just not being able to get a proper picture of it.
> Just wanted to share it in case others are able to get any ideas or able to think of a
> possible cause.
>
> [4]: https://github.com/git/git/blob/abb21c7263616f01c5e950861a29279ab21cb02f/git-submodule.sh#L654-L658
> -- >8 --
>
> I hope that gives a better idea about what kind of information would be helpful.
> Kindly let me know if it doesn't.
>
> Atharva,
>
> In the meanwhile, I think you could continue polishing your attempted solution
> and preparing to send it to the list. I'll try to dig more on my gut instinct
> and let you know if I get anything. If you have some free time left after
> polishing your series, you could try digging into it too :)
Sure. Thanks for the time and effort you are putting into this!
> --
> Sivaraam
next prev parent reply other threads:[~2021-07-19 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-18 11:59 My Git Dev Blog - Week 9 Atharva Raykar
2021-07-18 13:15 ` Christian Couder
2021-07-19 8:57 ` Atharva Raykar
2021-07-18 19:19 ` Kaartic Sivaraam
2021-07-19 2:58 ` Kaartic Sivaraam
2021-07-19 8:48 ` Atharva Raykar [this message]
2021-07-19 0:51 ` Bagas Sanjaya
2021-07-19 8:53 ` Atharva Raykar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6A97A724-4B80-4DDC-B5D2-83F8AD0B27EF@gmail.com \
--to=raykar.ath@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=kaartic.sivaraam@gmail.com \
--cc=periperidip@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).