tuckr status output

[schoettl]

Is this supposed to look like this?

What does it tell me when the group "all" is both symlinked and not symlinked?

I only have this one group in Configs/

$ tuckr --version
tuckr 0.12.0

[RaphGL]

Yeah it's not supposed to look like that.
Can you show me what your configs look like? I need to know all the files that are there. Or a small reproducible example that I can use.

As for what it means, probably part of all is not symlinked and tuckr is failing to properly detect it. Currently the only way to have this happen that I know of is to have symlinks inside of Configs that point to other dotfiles (I haven't implemented properly handling for them yet)

[schoettl]

I've installed the version from current master and will test if I can reproduce this or #130 . I'll report back by next weekend.

[RaphGL]

Appreciate it!

[schoettl]

So, I may have an example: I get dozens of the failed to symlink group warnings.

The vim-plug plugin manager places plugins in ~/.vim/plugged/ (which serves as a cache folder).
The symlinks below the ~/.vim/plugged/ folder are actually in the plugin code repos. So it's not my fault ^^

And tuckr doesn't cope well with it. The ~/.vim/plugged/ folder ended up being in my dotfiles repo somehow. I merged my dotvim repo git history in my tuckr dotfiles repo and created the ~/.vim/plugged/ later but not in the dotfiles repo.

$ tuckr add vim
…
failed to symlink group `vim`: No such file or directory (os error 2)
failed to symlink group `vim`: No such file or directory (os error 2)
failed to symlink group `vim`: No such file or directory (os error 2)
failed to symlink group `vim`: No such file or directory (os error 2)
Conflicts were detected. Conflicting groups won't be added until conflicts are resolved.
Not Symlinked:
	vim	 -> /home/jakob/.vim/plugged/sparkup/TextMate/Sparkup.tmbundle/Support/sparkup.py (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/ftplugin/html/sparkup.py (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/ftplugin/smarty (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/vim/ftplugin/html/sparkup.py (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/ale/test/.config/nvim/init.vim (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/vim/ftplugin/xml (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/ftplugin/xml (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/vim/ftplugin/smarty (symlinks elsewhere)
	 -> /home/jakob/.vim/plugged/sparkup/ftplugin/htmldjango (symlinks elsewhere)
	 -> /home/jakob/.local/share/nvim/site/autoload/plug.vim (already exists)
	 -> /home/jakob/.vim/plugged/sparkup/vim/ftplugin/htmldjango (symlinks elsewhere)

Symlinked:
	vim

Check `tuckr help add` to learn how to fix symlinks.

$ ls ~/.vim/ -l
total 28
lrwxrwxrwx 1 jakob users   54 Jan 17 19:34 Makefile -> /home/jakob/.config/dotfiles/Configs/vim/.vim/Makefile
drwxr-xr-x 1 jakob users   28 Jan 17 19:34 after
drwxr-xr-x 1 jakob users   38 Jan 17 19:34 autoload
drwxr-xr-x 1 jakob users    0 Jan 17 19:33 backupdir
drwxr-xr-x 1 jakob users   28 Jan 17 19:34 compiler
lrwxrwxrwx 1 jakob users   58 Jan 17 19:34 filetype.vim -> /home/jakob/.config/dotfiles/Configs/vim/.vim/filetype.vim
drwxr-xr-x 1 jakob users  352 Jan 17 19:34 ftplugin
lrwxrwxrwx 1 jakob users   71 Jan 17 19:34 general-abbreviations.vim -> /home/jakob/.config/dotfiles/Configs/vim/.vim/general-abbreviations.vim
lrwxrwxrwx 1 jakob users   56 Jan 17 19:34 gvimrc.vim -> /home/jakob/.config/dotfiles/Configs/vim/.vim/gvimrc.vim
drwxr-xr-x 1 jakob users 1048 Jan 17 19:34 plugged
lrwxrwxrwx 1 jakob users   58 Jan 17 19:34 projects.vim -> /home/jakob/.config/dotfiles/Configs/vim/.vim/projects.vim
lrwxrwxrwx 1 jakob users   62 Jan 17 19:34 qtranslate-x.vim -> /home/jakob/.config/dotfiles/Configs/vim/.vim/qtranslate-x.vim
drwxr-xr-x 1 jakob users   64 Jan 17 19:34 spell
lrwxrwxrwx 1 jakob users   55 Jan 17 19:34 vimrc.vim -> /home/jakob/.config/dotfiles/Configs/vim/.vim/vimrc.vim

I must admit that I don't yet fully understand how tuckr works. When does it symlink the containing folder and when does it symlink only the files?

Is it OK to add new config files in the dotfiles repo or should they only be added with tuckr push?

[RaphGL]

My suspicion is that this is related to this issue #77. Basically if you have a perfectly valid symlink inside your group it will report a conflict instead of accepting it because I didn't expect people to do this. I think the fix is to walk through the links until I reach a real file or a final symlink (or I just refuse to continue if it's recursive) and then symlink that. I just haven't gotten around to doing it yet, I was hoping to rely on Path but it doesn't do well with expanding relative symlink paths so I need to manually change directories for that to work.

I must admit that I don't yet fully understand how tuckr works. When does it symlink the containing folder and when does it symlink only the files?

If the folder doesn't exist it will symlink the folder. If it already exists, it will symlink files into the folder so that you don't adopt things you didn't want to adopt. If the folder exists but is a symlink and your symlinks will go into that folder, it will turn it to a regular folder and restore everything that was in it and then symlink your stuff.

Is it OK to add new config files in the dotfiles repo or should they only be added with tuckr push?

You can do it however you want. The only reason the push command exists is that I find that adding everything manually tends to be more work. That command just automates creating the directory structure tuckr expands, it doesn't do anything you can't just do manually.

[RaphGL]

By the way, tuckr shouldn't be looking at the plugged directory unless you have it inside your dotfiles. Maybe your dotfiles got screwed up because of the previous bug. It's usually pointless to "vendor" your plugins like that. I'm not using neovim anymore but when I was I was also using Tuckr and I didn't have my plugins vendored in. So tuckr would never attempt to symlink it and check it.
Your Dotfiles should only have what you yourself written or configured. If a separate tool will create the plugged directory, there's no need for you to bother including it in your dotfiles backup.

(that being sad, I still need to look at the bug I mentioned)