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
Conversation
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
@@ -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)) |
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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!
Timeouts on appveyor again, but #5125 was merged and things should get better. |
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