Skip to content
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

Avoid repo type assumptions to enable proper tracking branch detection (maint) #5127

Merged
merged 2 commits into from
Nov 6, 2020

Conversation

mih
Copy link
Member

@mih mih commented Nov 5, 2020

Force-treating a to-be-added submodule as a GitRepo prevented the
detection of a corresponding branch to the active branch, in order to
determine the true tracking branch. Which is necessary to discover
the effective clone URL from a repository (when it is in adjusted
mode).

This is an alternative to 901c8fd but
reworked to be applicable to the 0.13 series.

Fixes gh-5107

Will fail on a crippled file system.
…ction

Force-treating a to-be-added submodule as a GitRepo prevented the
detection of a corresponding branch to the active branch, in order to
determine the true tracking branch. Which is necessary to discover
the effective clone URL from a repository (when it is in adjusted
mode).

This is an alternative to 901c8fd but
reworked to be applicable to the 0.13 series.

Fixes dataladgh-5107
@mih mih changed the title Avoid repo type assumptions to enable proper tracking branch detection Avoid repo type assumptions to enable proper tracking branch detection (maint) Nov 5, 2020
@@ -2837,7 +2838,7 @@ def add_submodule(self, path, name=None, url=None, branch=None):
cmd += ['-b', branch]
if url is None:
# repo must already exist locally
subm = GitRepo(op.join(self.path, path), create=False, init=False)
subm = repo_from_path(op.join(self.path, path))
Copy link
Contributor

Choose a reason for hiding this comment

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

Stepping through this with the added tests and eval_under_testloopfs, this looks good to me.

@@ -3115,7 +3116,7 @@ def get_tracking_branch(self, branch=None, remote_only=False):
(remote or None, refspec or None) of the tracking branch
"""
if branch is None:
branch = self.get_active_branch()
branch = self.get_corresponding_branch() or self.get_active_branch()
Copy link
Contributor

@kyleam kyleam Nov 5, 2020

Choose a reason for hiding this comment

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

Hmm, this change isn't needed for the test case, as AnnexRepo.get_tracking_branch(..., branch=None, corresponding=True) already handles it. And if GitRepo is being used directly, get_corresponding_branch always returns None.

Is the idea with this change just that if GitRepo.get_corresponding_branch ever changed to do anything meaningful, this is one spot that should take it into account?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, this might be an artifact of the order in which I explored the situation. I will investigate and adjust accordingly. Thx!

Copy link
Member Author

Choose a reason for hiding this comment

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

Remove, thx for the catch!

@mih mih linked an issue Nov 5, 2020 that may be closed by this pull request
@mih
Copy link
Member Author

mih commented Nov 6, 2020

Timeouts on appveyor again, but #5125 was merged and things should get better.

@mih mih merged commit ace8110 into datalad:maint Nov 6, 2020
@mih mih deleted the bf-5107-maint branch November 6, 2020 07:58
@yarikoptic yarikoptic added this to the 0.13.6 milestone Dec 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking branch logic makes platform homogeneity assumptions
3 participants