Skip to content

fix: resolve submodule path to name on checkout #1237

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yankeguo
Copy link

@yankeguo yankeguo commented Dec 5, 2024

I made a quick and dirty fix for issue #1236

@yankeguo yankeguo force-pushed the fix-checkout-submodule-with-custom-name branch from c92d01f to a2ba292 Compare December 5, 2024 03:43
@yankeguo yankeguo changed the title fix: resolve submodule path to name on checkout, #1236 fix: resolve submodule path to name on checkout Dec 5, 2024
@@ -663,14 +663,20 @@ func (w *Worktree) checkoutChangeSubmodule(name string,
) error {
switch a {
case merkletrie.Modify:
sub, err := w.Submodule(name)
subs, err := w.Submodules()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should you try w.Submodule(name) first before checking the Paths?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that in this case, the "name" variable should actually be the path. So, in order to avoid the situation where the name of the submodule happens to match the path while the path itself fails to match properly, perhaps the "Submodule(name)" method shouldn't be attempted here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that is indeed the case (I haven't looked at the code or the calling code) then the parameter name is wrong, you should rename it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The related methods are all using "name" as the variable name. I'm not sure whether it's appropriate to modify it. It seems that "name" represents the file name (and path), and there is ambiguity when dealing with submodules.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing code looks up for the submodule by name: m.Config().Name == name. This current change does not seem backwards compatible, as although in some cases name and path may be the same, I am not sure that is a hard rule.

I'd keep the existing check (i.e. w.Submodule(name)), and if the submodule was not found, then try to get it by path (e.g. by calling a new func w.submoduleByPath(path)).

@yankeguo yankeguo force-pushed the fix-checkout-submodule-with-custom-name branch from a2ba292 to a7eca4b Compare December 6, 2024 01:44
@yankeguo yankeguo force-pushed the fix-checkout-submodule-with-custom-name branch from a7eca4b to 7bf90de Compare December 9, 2024 10:12
@github-actions github-actions bot added the stale Issues/PRs that are marked for closure due to inactivity label Jun 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issues/PRs that are marked for closure due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants