Support alt dirs with deeply nested tracked files

[ian-h-chamberlain]

What does this PR do?

Now, as long as there is a tracked file somewhere under the alt directory, it will be linked correctly, instead of requiring the tracked files to be direct children of the alt dir (previous behavior).

What issues does this PR fix or reference?

Closes #490
Related: #328, #356

Previous Behavior

A tracked file had to be a direct child of the ## alt directory for linking the directory to work properly.

New Behavior

Any descendant of the ## alt directory will cause it to be treated as an alt, and the directory itself will be linked (same as previous behavior).

Have tests been written for this change?

Yes: Updated test_alt to use a subdirectory for its contained file as part of the tests. Verified the test failed before my changes and passes after.

Have these commits been signed with GnuPG?

Yes

---

Please review yadm's Contributing Guide for best practices.

[ian-h-chamberlain]

This was just a drive-by cleanup I noticed, from reading builtin_dirname's comment it seems like it should be more portable?

[ian-h-chamberlain]

This doesn't work quite how I thought it did, drafting for now until I maybe eventually get some time to work on a more robust solution.

[erijo]

I'm currently working on refactoring the alt handling a bit and can try to incorporate a fix for this as well. So give me a week or two and we'll see if it turned out successful or not :)

[erijo]

@ian-h-chamberlain: If you have the time, could you please test with the deep-alt branch and see if it works as you expect?

[ian-h-chamberlain]

@ian-h-chamberlain: If you have the time, could you please test with the deep-alt branch and see if it works as you expect?

@erijo wow, quick turnaround! I think the changes in that branch do work, but it has the same problem my attempt had; there's no way to merge the linked directory, and if it already exists the symlink will be created as a child instead of what I thought the behavior should be (symlink all the children to their respective locations).

Here's an example that hopefully shows what I mean (current behavior):

$ yadm ls-files .config/yadm/alt/Services* | tree --fromfile
./
└── .config/
    └── yadm/
        └── alt/
            └── Services##os.Darwin/
                └── Open in Visual Studio Code.workflow/
                    └── Contents/
                        ├── Info.plist 
                        ├── QuickLook/
                        │   └── Thumbnail.png
                        ├── Resources/
                        │   └── workflowCustomImage.icns
                        └── document.wflow

9 directories, 4 files

$ yadm alt 
[...]
Linking /Users/ianchamberlain/.config/yadm/alt/Services##os.Darwin to /Users/ianchamberlain/Services

$ tree -F ~/Services
/Users/ianchamberlain/Services/
└── Services##os.Darwin -> .config/yadm/alt/Services##os.Darwin

1 directory, 2 files

I think ideally, what it should do is something like this:

$ yadm alt 
[...]
Linking /Users/ianchamberlain/.config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/Info.plist to /Users/ianchamberlain/Services/Open in Visual Studio Code.workflow/Contents/Info.plist
Linking /Users/ianchamberlain/.config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/QuickLook/Thumbnail.png to /Users/ianchamberlain/Services/Open in Visual Studio Code.workflow/Contents/QuickLook/Thumbnail.png
Linking /Users/ianchamberlain/.config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/Resources/workflowCustomImage.icns to /Users/ianchamberlain/Services/Open in Visual Studio Code.workflow/Contents/Resources/workflowCustomImage.icns
Linking /Users/ianchamberlain/.config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/document.wflow to /Users/ianchamberlain/Services/Open in Visual Studio Code.workflow/Contents/document.wflow

$ tree -F ~/Services
/Users/ianchamberlain/Services/
└── Open in Visual Studio Code.workflow/
    └── Contents/
        ├── Info.plist -> .config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/Info.plist
        ├── QuickLook/
        │   └── Thumbnail.png -> .config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/QuickLook/Thumbnail.png
        ├── Resources/
        │   └── workflowCustomImage.icns -> .config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/Resources/workflowCustomImage.icns
        └── document.wflow -> .config/yadm/alt/Services##os.Darwin/Open in Visual Studio Code.workflow/Contents/document.wflow

Hopefully that makes sense... it might be slightly trickier to implement but maybe your refactors will make it a little easier?

[erijo]

there's no way to merge the linked directory, and if it already exists the symlink will be created as a child instead of what I thought the behavior should be (symlink all the children to their respective locations).

Aha, I didn't even consider that way of doing it, but it sounds like a reasonable way to handle this case. I'll look into soon (tm) :)