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

Fix test_clone_unborn_head_sub on a managed branch #4792

Merged
merged 2 commits into from Aug 1, 2020

Conversation

kyleam
Copy link
Collaborator

@kyleam kyleam commented Jul 31, 2020

This fixes the test failure that @mih reported in gh-4727. The first commit is the main fix. It updates the test itself, which was setting up an unintended and bizarre repo state that happened to pass before Git 2.27. The second commit prevents postclone_check_head from checking out adjusted branches. Either of these commits on their own avoid the failure.

I've confirmed that the test passes when executed under tools/eval_under_testloopfs both before and after the git commit mentioned in that issue.

kyleam added 2 commits Jul 31, 2020
test_clone_unborn_head_sub() sets up a scenario in which the
to-be-cloned dataset has a submodule where HEAD points to a branch
with no commits and another branch has commits.  This is an uncommon
state to get into with a local repository, but it's not too tricky to
do when setting up remotes, particularly for datasets created with a
create-sibling before 8452426 (ENH: create-sibling: Set HEAD of
sibling to local repo's branch, 2020-04-01).

When on a managed branch, the scenario is botched.  The corresponding
branch is renamed while the adjusted branches are left as is, leading
to a mismatched set like refs/heads/other,
refs/heads/adjusted/master(unlocked), and
refs/basis/adjusted/master(unlocked).  Fix the setup so that the
adjusted branches are renamed as well, following the approach used in
another test, test_clone_unborn_head().

Note that, without the changes here, this test doesn't start to fail
until Git's 7c5045fc18 (ref-filter: apply fallback refname sort only
after all user sorts, 2020-05-03), which was released with v2.27.0.
With 7c5045fc18, the git-annex-init call in the cloned submodule fails
trying to update a non-existent origin/master.  But 7c5045fc18 is just
about refname ordering; you can trigger the failure with Git versions
before v2.27.0 by replacing the refname "other" with "abc"
(i.e. changing the position of the non-master refname relative to
master).

Even though the scenario that triggers this is broken and unlikely to
happen in the wild, this should probably be reported to git-annex in
case it indicates a wider issue.

Fixes datalad#4727.
The previous commit describes how test_clone_unborn_head_sub()
unintentionally created a set of mismatched corresponding and adjusted
branches, such as refs/heads/other,
refs/heads/adjusted/master(unlocked), and
refs/basis/adjusted/master(unlocked).  If a repo with this setup is
cloned and postclone_check_head() checks out the adjusted branch, the
downstream git-annex-init call may crash.

Teach postclone_check_head() to avoid adjusted branches.  The
subsequent git-annex-init call will take care of moving to an adjusted
branch if it detects that the file system doesn't support symlinks.

Re: datalad#4727
@kyleam kyleam changed the title Fix_test_clone_unborn_head_sub on a managed branch Fix test_clone_unborn_head_sub on a managed branch Jul 31, 2020
@mih
Copy link
Member

mih commented Aug 1, 2020

Test failure is #4773

mih
mih approved these changes Aug 1, 2020
Copy link
Member

@mih mih left a comment

Thx, this LGTM!

@mih mih merged commit e2ec849 into datalad:maint Aug 1, 2020
1 of 2 checks passed
@kyleam kyleam deleted the sub-unborn-head-failure branch Aug 3, 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.

None yet

2 participants