To solve the issue of managing DOTFILES, why can't we just run "git" inside .config directory?

Question

My question is.

Why can't we just "git" the entire .config directory? Wouldn't that be a simpler way to manage dotfiles? for e.g. My ".config directory" is about 250 mb which is well below the space limit in Gitlab/hub. Ofcoruse I will keep it private.

What are edge cases? I issue I can think of is that it might generate a lot of Untracked files when you run git. Idk. I am just a noob thinking aloud.

I have checked out several soltions to solving the problem of managing dot files. Top of them include

1. Create --bare git repository and create custom git commands
2. Save preferred dotfiles in another respository like Documents and git it
3. create symlink to the Dotfiles you need and manage them from @HOME with git
4. Use Stow or yadm ( yet another dotfiles manager)

[Managing dotfiles] (https://www.atlassian.com/git/tutorials/dotfiles)

Answer 1

Why you Shouldn't:

The problem with dotfiles is their lack of standardization. While usually they store things like my username is billy4, sometimes dotfiles can have authentication information, binaries, cache, temporary files, state data, etc. that you don't want to go to source control.

For example, .npmrc has (at least mine does, I can't say the same for everyone) registration tokens shpotify's .shpotifyrc file has auth tokens, the ~/.config/gh, ~/.config/configstore/firebase-tools.json folder can have logins -- you get the point.

As well, applications sometimes store all of their app data in the config folder, like iTerm2. ~/.config/iterm2 stores all of your settings, cached data, the iTerm window state, shell history, etc..

I can't recall if this is default or not, but I have my environment setup so that my global .yarnrc is in my config folder

Finally, applications can store log/history files there, and if they were checked into source control, while it's not the end of the world, it would make things difficult to maintain and add a lot of complexity. You wouldn't want to check .zsh_history or something similar to source control right? That'd make the repo an extreme pain to push, pull or merge.

Workaround:

This is a solution similar to my dotfile repository (You're probably not interested in what my terminal looks like or what font I use, but it might help you with your solution's file structure and potential setup scripts).

TLDR; you can move the children (that you want in source control) of .config to a different path like ~/.dotfiles, then create a git repo in it, and link each one to ~/.config.

If I were you, I'd put all of the config files that I want in git in a path like ~/.dotfiles, I'd link all of the children (except one) of the ~/.dotfiles source to be in ~. For example: ~/.dotfiles/.zshrc would be linked to ~/.zshrc. The child not to link is ~/.dotfiles/.config. This is because I would run mkdir -p ~/.config (in case it isn't already), then I'd link every child directory of ~/.dotfiles/.config/<child> to ~/.config/<child>. This allows me to put whatever config folder I want in the repo's .config folder to be sent to ~/.config, but I could also have items in ~/.config that are normal folders instead of links.

Here is kind of what I mean:

HOME             links to      DOTFILES

# Link the whole file          # Link
~/.zshrc             ->        ~/.dotfiles/.zshrc

# Link the whole folder        
~/.some-folder/      ->        ~/.dotfiles/.some-folder/    # Linked folder
  |- dev/                      ~/.dotfiles/.some-folder/dev/ 
  |  |- hello.txt              ~/.dotfiles/.some-folder/dev/hello.txt 
  |  |- world.txt              ~/.dotfiles/.some-folder/dev/world.txt 
  |- fun/                      ~/.dotfiles/.some-folder/fun/ 
  |  |- foo.txt                ~/.dotfiles/.some-folder/fun/foo.txt

# Link the children            
~/.config/                     ~/.dotfiles/.config/# Real Folder
  |- nvim/           ->        ~/.dotfiles/.config/nvim/ # Link
  |- git/            ->        ~/.dotfiles/.config/git/ # Link

There are upsides and downsides to both.

Linking the whole folder gives a lot less control and you will likely have things you don't want to be in your repo. However, it also is a lot simpler, and easier to manage. If I modify any child or grandchild (etc.) of ~/.some-folder from either side (source file vs. link), all of the changes will be reflected. I can update, delete, create, etc.

If you are more specific with your linking (linking children, childrens' children, etc.), you can have more control with what goes to git, and what stays local. By making ~/.config an actual folder, and linking each child to it, I can decide I don't want ~/.config/.auth to go to the repo and just put it in the ~/.config/.auth directory. this all works because ~/.config is a normal folder, it isn't a symlink, and if you put something in it, there won't be any changes in ~/.dotfiles/.config.

Getting too specific with links can make things pretty challenging to manage; let's say, for example, instead of linking the whole .config/git folder, I link .config/git/config and .config/git/aliases. Later, if I decide to add .config/git/some-other-file, I need to create it in the dotfiles source, then link it. If I rename .config/git/config to .config/git/gitconfig, I need to delete the .config/git/config link (it will be pointing to a file that doesn't exist), and add a link for .config/git/gitconfig.

I thought quite a bit about this when I set up my repo, and once you get the right balance of ease and specificity, it is super nice.

I'd recommend making a bash file that will read the contents of the ~/.dotfiles directory and set up the links, so that if you want to update your dotfiles because of a name change, deletion, etc., you can just run something like: ~/.dotfiles/link.sh and it will update the links for you.