An example of why ignore or a list option is useful

[KharmaScribbles]

I'm sure I'm just missing out on some command somewhere, but my help info only shows me "add, unlinjk. status, link, remove, help" as the only commands with the version from master.

This has happened to me a few times now, and I keep face-palming myself for not remembering how "link" acts. I'm thinking that internally dotfiles keeps track of only files I've "dotfiles add"ed.. however it appears it keeps track of all the files in the repo, each one representing a dotfile according to 'dotfiles'.

For my use case this is incorrect, as I have quite a few files in my Dotfiles repo that are not actually part of my dotfile configuration and I wish them to not be tracked by dotfiles. Is this possible? Dotfiles also should do as it's told, if I tell it to unlink a file, I don't want it talking back to me with an error about how such and such file is within the repo, there is no force option so I'm kinda stuck fixing everything the hard way. Cheaky dotfiles! :p

In this case, I used "dotfiles link" to ensure that all my dotfiles were symlinked properly since I had been adding and removing a lot today. I forgot it thinks everything in my repo should be tracked. Turns out, I didn't want any of the new links it made! Those are either an encrypted version of a dotfile I use only to push to the repo, I already had the decrypted version linked (this could have caused a loss of data had the one file not ended in .gpg).. or files related to my encryption program, nothing of which I needed linked in my $HOME.. Oops.

As we figured out in my last issue, I fail at life.. my fault for doing this like 3 times now... but I think dotfiles should either be smarter with linking or at least make it easier to clean up. If I want a link removed, remove it.. I am boss. As you can see, it won't listen to me. Dotfiles owns me right now, it is totally playing the dom in this relationship..:p

*FYI the 2nd command I ran.. "dot" is a dotfiles alias, obvious maybe but just clarifying..

[jbernard]

* Kharma Scribbles <[email protected]> wrote:

I'm sure I'm just missing out on some command somewhere, but my help info only shows me "add, unlinjk. status, link, remove, help" as the only commands with the version from master. This has happened to me a few times now, and I keep face-palming myself for not remembering how "link" acts. I'm thinking that internally dotfiles keeps track of only files I've "dotfiles add"ed.. however it appears it keeps track of all the files in the repo, each one representing a dotfile according to 'dotfiles'.

Both statements are true, let me explain. Dotfiles stores the files you `add` in a repository (~/Dotfiles by default). The only way to get a file into the repsitory is to use the `add` command. The `link` command iterates through each file in the repository and attempts to create the corresponding symlink in your home directory that points to the actual file in the repository. The only files that dotfiles knows about are the ones present in the repository and therefore the ones you've explicitly added. If you never added it, dotfiles won't know about it. An aside, the errors in your screenshot are not really errors, it's just the link creation failing because the link is already present. Those need to become info or silenced.

For my use case this is incorrect, as I have quite a few files in my Dotfiles repo that are not actually part of my dotfile configuration and I wish them to not be tracked by dotfiles. Is this possible?

Can you show me an example?

Dotfiles also should do as it's told, if I tell it to unlink a file, I don't want it talking back to me with an error about how such and such file is within the repo, there is no force option so I'm kinda stuck fixing everything the hard way. Cheaky dotfiles! :p

So, the error in your screenshot is because of this: you're asking it to link a set of files, but those files should be the one's in your home directory (the target), not files within the dotfiles repository. This is why the error is raised. To be more specific, you've `cd`'d into the repository and you're attempting to `link` the `keyrings/live/.gitattributes` file. But you should be linking `~/.keyrings/live/.gitattributes` <- this is the target and what dotfiles expects to operate on. The contents of the repository is supposed to be managed by dotfiles and mostly opaque to the user.

In this case, I used "dotfiles link" to ensure that all my dotfiles were symlinked properly since I had been adding and removing a lot today. I forgot it thinks everything in my repo should be tracked.

In theory, everything in the repo was explicitly added, so dotfiles is doing what it's supposed to. Are you saying that the repository contains files that should not be in there?

Turns out, I didn't want any of the new links it made! Those are either an encrypted version of a dotfile I use only to push to the repo, I already had the decrypted version linked (this could have caused a loss of data had the one file not ended in .gpg).. or files related to my encryption program, nothing of which I needed linked in my $HOME.. Oops.

Dotfiles in the master branch will never overwrite an existing file, on filename collision and error should be raised. Data loss is the most unacceptable form of bug in this case.

As we figured out in my last issue, I fail at life.. my fault for doing this like 3 times now... but I think dotfiles should either be smarter with linking or at least make it easier to clean up. If I want a link removed, remove it.. I am boss. As you can see, it won't listen to me. Dotfiles owns me right now, it is totally playing the dom in this relationship..:p *FYI the 2nd command I ran.. "dot" is a dotfiles alias, obvious maybe but just clarifying..

The most helpful thing you could do is create a complete log of your commands starting with an empty repsitory up to the point where something appears to be not working correctly. I need to see both the confusing state and exactly how we got into that state. On linux you can use script [1] to record shell command and email me the resulting file (or attach it here). [1] https://linux.die.net/man/1/script There are other tools too, I'm not particular about it as long as I can see the steps. Hope this helps,

…

-- Jon

[KharmaScribbles]

Ahh, misunderstanding.. I was just showing that dotfiles was linking everything in my repo, I didn't mean to point out the error messages, but basically everything that did not error I did NOT want linked... lol , for example, ".keyring/live/.gitattributes" ".keyrings/live/.pubring.kbx" all the files ending in .gpg basically (or rather, any of the files under the .keyring dir) and it also linked "..gitattributes"

I do add files to my dotfiles repo manually - I have an encryption program, which in turn I run on plaintext sensitive files, and it makes that file encrypted with the extension .gpg I only encrypt to push to my public github remote, any files containing secrets basically. It adds the extension .gpg so at the end my repo contains as example irissi/config.gpg however this was the original irissi/config file that dotfiles already linked earlier, but with the filename change it attempts to make a new link on irissi/config.gpg.. After I'm done commiting and push to the remote, I unencrypt that .gpg file and it goes back to being irissi/config. My mistake was asking dotfiles to check links before I was done and unencrypted.. but I wanted to make sure I had everything up to date before my push.. I would rather have it ignore anything in the .keyrings dir as well. .. My encryption program needs to run/be cloned in the root of the repository it will be used in, and it looks for/creates and uses this .keyrings dir. I also sometimes add submodules to my dotfiles repo, like themes or antigen/plugin managers.. I haven't this time around yet but I like having those all within the same "project" aka my dotfiles.

The error I mentioned about it not listening to me, was that for example, running "unlink .keyring/live/.gitattributes" in the repo threw up an error about how it basically wasn't going to unlink because that file I'm asking it to unlink is within the repo. I did discover that running that command outside the repo on the filename it symlinked to my homedir made it unlink successfully, so a suitable workaround but it should just do as I command within the repo anyways.

I guess I could do my workflow a completely different way to avoid this, but I just thought I'd mention this as having a dotfilesignore would just solve it all for me.