problems with nested datasets when working from multiple computers

[alecristia]

I'm working on William's RELIVAL project from 2 computers.
In one computer (laptop), I've the metrics datasets nested the way I want them, and that computer claims that it's up to date, nothing to commit, nothing to pull. It's pushing to RELIVAL in gin.

PROBLEM #1: The other computer (dekstop) did NOT show the same changes.
SOLUTION TO PROBLEM #1:

1. Check that both computers have the same remote url with something like git config --get remote.origin.url (you may need to change the bit remote.origin.url depending on the name of the branch). Indeed, I found that the second computer used to have its url set to William's gitlab, so I reset it to gin with this: git remote set-url origin [email protected]:/LAAC-LSCP/RELIVAL.git.
2. Even after that, datalad update merge did not result in changes reflecting in my local copy. git pull, in contrast, resulted in an update. As to why this was good, @LoannPeurey suggested "could be something linked to remotes if you have multiple siblings but git only has the gin remote".

PROBLEM #2: Nested datasets aren't showing in the other computer (desktop)

I'm sure I appropriately nested the datasets (using datalad clone -d . SOURCE PATH) on my laptop but on my desktop, the folders show up but they are empty. In all honesty, the version I had installed or cloned from William's gitlab also had the same behavior (I could see the name of the datasets but no contents), but since I don't know how he had installed them, I did it again, making sure to use the -d (in datalad clone **-d** . SOURCE PATH) in my laptop. But in my desktop, they are still showing up empty.

@LoannPeurey asked: "the version on your desktop was made by cloning from GIN? if you did an install or clone without the -r option, the nested modules are not installed, you need to explicitely tell that you want them locally (and not as a remote reference as it is right now) by doing a datalad get ". Notice that since I nested the datasets after the superdataset was installed or cloned, this doesn't seem relevant. That is, if it is relevant, then it suggests that when you're working on a live project, and someone nests a dataset, pulling will not result in the dataset being appropriately showing up as an "active" nested dataset.

Things I tried but that did not work:

1. check that the desktop's version is a dataset:
   datalad siblings
   results in

.: here(?) [git]
.: origin(?) [[email protected]:/LAAC-LSCP/RELIVAL.git (git)]
yes, it is

2. check that GIN has the datasets nested:

yes, it does

3. Try uninstalling and reinstalling the dataset, making sure to include the -r switch (in progress):

# from within the relival folder
datalad uninstall . # yields: "[WARNING] path constraints did not match an installed subdataset: ['.']", and nothing is removed

datalad remove . # yields uninstall(error): . (dataset) [will not uninstall top-level dataset (consider `remove` command)]

# from parent directory:
datalad uninstall RELIVAL/ # yields [ERROR  ] NoDatasetFound(No dataset found at '/Users/acristia/Documents/gitrepos' for the purpose 'uninstall'.  Specify a dataset to work with by providing its path via the `dataset` option, or change the current working directory to be in a dataset.) (NoDatasetFound)

# from parent directory:
datalad uninstall -d relival/ #yields uninstall(error): . (dataset) [will not uninstall top-level dataset (consider `remove` command)]

datalad remove relival/ # success!!

datalad install -r [email protected]:/LAAC-LSCP/RELIVAL.git

[alecristia]

For the time being, the only solution that worked was uninstalling and reinstalling the whole dataset (ie not the nested datasets, but the superdataset):

# from the parent directory to the superdataset
datalad remove relival/ # remove the previous version of the superdataset
datalad install -r [email protected]:/LAAC-LSCP/RELIVAL.git # reinstall

It remains to be seen whether if someone nests a dataset now, this will show as appropriately nested here as well.

Perhaps not automatically nesting is a feature rather than a bug - perhaps it forces one to show one has the right permissions.

[alecristia]

in another case that superficially looked like the one above (nested datasets show up empty), we first checked .gitmodules. It did contain in it links to the right datasets. So from the dataset level, we could do something like datalad get SUBFOLDER/PATH_TO_KEY_FOLDER and voilà !

[LoannPeurey]

Get (clone) a registered subdataset, but don’t retrieve data:

datalad get -n <path/to/subds>

=> http://docs.datalad.org/en/stable/generated/man/datalad-get.html