datalad get (-n) of subdataset in adjusted mode yield improper initialization

[mih]

Using the test code from #5241 I build a superdataset with a subdataset that has a single annexed files. I push them into a ria store, and clone the superdataset from it.

Running the following snippet in the superdataset, I can more or less consistently generate an improperly initialized subdataset:

# clean prev attempt
datalad uninstall --nocheck sub
# cause the breakage
datalad get -n sub
# test for the breakage: there should be a diff between HEAD of the managed branch
# to the corresponding branch from creating a pointer file
[ "x$(git -C sub diff dl-test-branch..HEAD)" = "x" ] && echo BROKEN

In this broken state, the adjusted mode branch has no commit from adjusting. A subsequent git annex get
will leave the dataset dirty (staged adjusted file).

I am not able to replicate this situation outside of datalad. Here is my attempt at performing the internal steps manually without datalad:

% datalad uninstall --nocheck sub
% git submodule update sub

% git -C sub annex init
% [ "x$(git -C sub diff dl-test-branch..$(git -C sub log --pretty=%h -1))" = "x" ] && echo BROKEN

[bpoldrack]

FTR: Spontaneously smells like an issue with clone.postclone_check_head() to me.

[mih]

Debug session with @bpoldrack revealed that it is indeed datalad that destroys a perfectly initialized subdataset in an attempt to checkout the correct submodule commit -- in complete ignorance of adjusted mode.

The path to enlightenment seems to be to delete all this code in get and use the capabilities of clone_dataset() itself to check out particular version.

Well, not that simple. clone_dataset cannot do what it needed, but would need to be equipped with what is needed. Importantly, the checkout of the right commit needs to happen prior to git annex init.

[mih]

I have a fix. I think.