Create symbolic links to issues instead of moving them

[Luís Ferreira]

Since an issue has a unique ID, would be great to use symbolic link references to state folders (pending, resolved) instead of literally moving them.

This is particularly useful to reference an issue without changing its path.

[Cal Bryant]

Hi @ljmf00

That might mean that changing status is not a detectable conflict that git can resolve. Besides, the task list file loader abstracts the location of the task.

Is there an advantage I'm missing? Tasks are never addressed directly on the filesystem.

[Luís Ferreira]

Hi @ljmf00

That might mean that changing status is not a detectable conflict that git can resolve. Besides, the task list file loader abstracts the location of the task.

Can you elaborate on that? I guess it is the same since the symbolic link will only be present on the current status and the actual task file doesn't change the path. I'm not sure if this is designed to work on Windows, but I can see a problem with this for filesystems that don't support it, like NTFS. This would be easily resolved by making this feature to be configurable.

Is there an advantage I'm missing? Tasks are never addressed directly on the filesystem.

The advantage I see the most is naturally referencing a task publicly. My use-case for this is the fact that I have my tasks public and if someone wants to track the task, they can do it with only one link I provide. Instead, with the current approach, if the task is not found, they need to manually search on other folders to get, let's say, updated notes related to that task.

[Coleman McFarland]

How are you actually sharing your tasks? Something like Dropbox? Or a network file share?

[Luís Ferreira]

How are you actually sharing your tasks? Something like Dropbox? Or a network file share?

No, directly though raw user content provided by GitHub, that directly maps git structure. I also host a copy of my tasks on IPFS that realistically copy the entire git structure to a folder /files. https://tasks.lsferreira.net/ . The point is: I can do symbolic links manually, the other way around, but I would have to have a script to do the symbolic links, plus it could break if, e.g. Github raw user content could not handle symbolic links.

[Coleman McFarland]

Moving tasks into directories is just how things work right now. This way of doing things has some advantages, but isn't right for every use case.

Also, I don't think github raw content handles symlinks. I just tested a symlink, by creating a symlinks directory in my .dstask database, and this was the output in raw content.

../pending/0b2b311f-0bda-42dd-8fda-ad264434b778.yml

Your best bet here is a script that maintains copies of your task files in a single directory at the top level of your task database. Perhaps you could do this with a pre-commit hook:

1. Hook identifies changed files
2. Hook copies the new file to a directory not maintained by the task db, say, .dstask/TASKS
3. Hook invokes git add file.yaml on the updated file under TASKS

After the hook is done, the files under TASKS will be synced. Don't forget to handle deletes in your script (dstask rm). See also this stack overflow question

This dedicated directory of copies can be a stable path, which in turn should yield a stable URL.

PS: That is a cool website! How do you render the table? It looks exactly like the terminal output.

[Luís Ferreira]

Moving tasks into directories is just how things work right now. This way of doing things has some advantages, but isn't right for every use case.

I totally understand that changing this, could be a breaking change and this functionality may not work on Windows, unfortunately.

Also, I don't think github raw content handles symlinks. I just tested a symlink, by creating a symlinks directory in my .dstask database, and this was the output in raw content.

My point on that was that being the alternative. If the actual files were not symbolic links, that would work perfectly.

../pending/0b2b311f-0bda-42dd-8fda-ad264434b778.yml

Your best bet here is a script that maintains copies of your task files in a single directory at the top level of your task database. Perhaps you could do this with a pre-commit hook:

1. Hook identifies changed files
2. Hook copies the new file to a directory not maintained by the task db, say, .dstask/TASKS
3. Hook invokes git add file.yaml on the updated file under TASKS

After the hook is done, the files under TASKS will be synced. Don't forget to handle deletes in your script (dstask rm). See also this stack overflow question

I'm aware of git hooks and I'm probably going to do something similar to that. Thanks for the suggestion :)

PS: That is a cool website! How do you render the table? It looks exactly like the terminal output.

Oh, glad you liked it. For now, this is a bit clunky as I wanted it to simply work. You can check the generator script that I made, in bash: https://github.com/ljmf00/tasks/blob/master/generate-html.sh . I'm going to soon make something fancier tho, to add hyperlinks. Probably I'm going to add some redirection files and index the status to make it sharable. Something like tasks.lsferreira.net/share/#0b2b311f-0bda-42dd-8fda-ad264434b778 and will redirect accordingly.

[Dieter Plaetinck]

cool to see an appearence of GH synced tasks in the wild :)

[Cal Bryant]

cool to see an appearence of GH synced tasks in the wild :)

Yes!