Add more robust work directory parsing

[SymbionicNigel]

What does this PR do?

This PR removed the requirement for the user to provide the -w and the associated file path when dealing with git submodules. As described in the issue I had created (#501) where git operations were not working correctly even though the --yadm-data, --yadm-dir, --yadm-repo arguments were being supplied to yadm, I see this as a way in which yadm can take a step towards Staying out of the way and letting Git do what it’s good at by relying less on the manual setting of the core.worktree git config value and requiring fewer configuration values past the three arguments I mentioned above.

There are 3 situations which this new function handles:

1. When core.worktree is not filled: This means that the user is working with or initializing a top level git repository in yadm which has not been initialized through yadm before. This is the first branch of the if statement, where I am either returning $YADM_REPO defaulting to $HOME if $YADM_REPO is not valid.
2. When core.worktree is an absolute path: This means that we are dealing with a top level git repository or a git submodule which has been initialized through yadm. This branch will handle the situations dealing with all correctly configured yadm repositories.
3. When core.worktree is a relative path: This means that we are dealing with a submodule which has not been initialized through yadm. Git, when dealing with submodules naturally, will populate the core.worktree config with a relative path that points to the submodule it is managing in relation to the top level repositories location in which it stores the submodules git config.

An example for situation 3 would be if I had a top level repository located at ~/test with a submodule in a directory at ~/test/.secrets. If only configured through git, the $YADM_REPO value that I would supply would be ~/test/.git/modules/.secrets and the core.worktree value written by git would be ../../../.secrets. Given those examples we could combine the $YADM_REPO value with the core.worktree output to get an absolute path to the actual location of the directory we are working with.

What issues does this PR fix or reference?

#501

Previous Behavior

Previously yadm would require the user to supply the -w <path to workdir> argument with the yadm init command when working with submodules, otherwise git commands would not function. This still works with that method of initialization.

New Behavior

The new behavior would allow for the user to just initialize the repo through git and not yadm. Either method would work now.

Have tests been written for this change?

No, but I can add them if requested.

Have these commits been signed with GnuPG?

Yes.

---

Please review yadm's Contributing Guide for best practices.

[erijo]

Thanks for this PR!

If you could add a test that would be helpful. Both to avoid regressions but also to make the problem your fixing more clear.

Please also rebase on latest develop.

[SymbionicNigel]

Hello,

Sorry I have not touched the MR in a couple of months, I have had some things come up recently.

To clarify I was experiencing errors when trying to perform operations on submodules saying that it could not find the git repo nor the work directory. After some further testing recently, I had found that I was in fact passing in some incorrect arguments and have been able to get this working in the past few days for my use case.

This change was trying to make use of the relative core.worktree value that gets set when a submodule is initialized through git instead of needing to set it during yadm initialization, but I was mistaken and thought that the core.worktree value needed to point towards the root of the submodule (like the value set by git when it initializes the submodule) instead of the location where yadm will be symlinking files into.

Honestly, I think my brain got caught up on the fact that, in the situation I am trying to use this for, it looks like there is some connection and that value could be used. But it would need to be the inverse of that relative path (it would then point from submodule to parent) for it to work.

Sorry for the confusion and any time this may have taken on your end. And thank you for the work you are putting in to maintain the package!