Usually you provide better explanations that are more clear and accurate. This might provide a little clarification for some: Early on you mix concepts of stow and git and use them almost interchangeably, which isn't at all how they work. Stow and git are two separate tools. Symlinks are not what allow you to push changes to your GitHub repo, that's just git. You describe symlinks in a way that implies data is copied and both sets of data are simply mirrored/synchronized, but you earlier correctly described symlinks as pointers. You aren't changing the symlink when you edit it in vim, you're only changing what the symlink points to. Stow doesn't care what you call things. That's dependent on the package/application. You also don't need the "package" subdirectories in your stow source directory. The target to place symlinks is not your home directory. The default target is the parent directory from where you ran stow. This feels like just a longer version of DreamsOfCode/DreamsOfAutonomy video on stow.
@@bassamsaleh8034 Sure. Stow's default behavior is to place symlinks in the parent directory of wherever you choose to run the "stow" command. When you feed stow the directory you want symlinks for, in this case the nvmin "package directory" as typecraft called it in the video, it will create symlinks for everything within that folder, and place them in the parent folder of your current location. So let's say I start out when I log in at my home directly (~)... I would then cd to where my dotfile repo is stored, which when using stow defaults should be in your home directory (because it will place things in the parent directory remember). cd .dotfiles stow nvim this will place symlinks for everything in the nvim directory in my home directory. It follows the same directory structure that you have in the nvim directory. Notice in the video that most of typecraft's "package" directories have everything in them in a .config directory. This is because the respective application expects its configuration files to be in ~/.config. So stow makes symlinks for everything in nvim in your home directory, and anything in the .dotfiles/nvim/.config/ directory goes into ~/.config/ You can simplify this process a bit by not using the "package" directories within your .dotfiles directory/repository. You have a bit less granular control over selecting which files get copied by default, but instead of running stow dirName for everything, you can just run stow . to symlink everything in .dotfiles all at once. You can of course modify stow's behavior with flags and configuration settings, etc so you don't have to set things up exactly like typecraft or I have described. It's just a bit simpler to use the defaults and have one less thing you need to configure or remember what flags you need when you may not use it that often. It's a lot easier to remember if you keep it simple. I hope that helped your understanding. If you have any more questions, feel free to ask and I'll try my best to answer them thoroughly.
Dream of Autonomy's videos was pretty great. I personally learnt about it about 2 years ago through Jake Wiesler's video. It was informative, well researched and if I remember he had the same guide on his blog for those who prefer to read.
Also, one does not need stow to disseminate their dot file configs across machines, git is perfectly capable of doing that without symlinks. What stow allows, in such a setting, is to keep a set of configs that you can choose to stow or not, in the same repo, targeting the same set of directories. I personally don't have a need for such granularity and I've been syncing my home folder across machines via git for more than a decade, never once utilizing stow for that...
By the way, with all my L❤VE for your work, at 6:42 you mention that the "-l" flag of the "ls" command will show links. Precisely, the "-l" flag of the "ls" command will display a long listing format, in which we will have the permission string as well as a lot more information. 😉
This video explains it so well with the examples that make sense. I had to understand this stow thing on my own going through so many symlinks mistake which was so terrible. This video is gonna help so many people getting into GNU stow. Great vid for sure !!!
Yeah, +1 for Chezmoi. The only downside is that I ended up not having my nvim directory in there but as a separate repo instead, given how frequently it's modified and it is a little bit of a hassle to `chezmoi add` changed stuff. But for files that aren't changed that frequently, chezmoi is awesome.
yesssss oh man you made this whole setup SO much easier to understand, thank you! I've been enjoying your other videos, and I'm really glad you talked about this.
It’s a bit more of a commitment than just installing software but I feel like NixOS would fit well with this channel. The home manager for dot files is amazing. I prefer that to configuring NeoVim in Nix though that is an option.
I've used NixOS for almost a year now, but never got into HomeManager because I don't understand the point. Is it just putting all the dotfiles into a single file, or is it doing something special?
@@GoldenBeholdenwell getting your dot files set up is just one part of setting up your system. Home manager can go much farther including setting up your git config, or better yet, installing all of the programs your dotfiles rely on (In non nix os context)
I can see the advantage of the more granular control that the package naming approach would give you, but I've found that (for me), just breaking my dotfiles folder into target hardware folders works best. For example, my desktop is running KDE, but my laptop is running Hyprland, so in my dotfiles folder i have a "desktop" folder and a "laptop" folder which each have the config files unique to them, and then a "common" folder for config files that are the same for both (such as neovim and tmux). Then I just run "stow common", and "stow laptop" or "stow desktop" depending on what machine I'm using.
@@misterkite yeah lately I've been considering doing something like that. I realized that if I get a Macbook from work, I'd probably just want my tmux and nvim configs, which my current setup doesn't really support easily.
top tip you can use a target path for stow For example, Imagine you have a config repo like and a Mac source machine: gitrepo:config ├── vscode │ └── settings.json The command: stow -t ~/Library/Application\ Support/Code/User vscode Will add a sym link in your vscode user settings directing to your settings.json thats held in your git repo! VScode is a bad example as it's a repo that allows for cross device setting management, but the same logic can be applied to most other apps with customisable settings.
With nix, you don't have to manage your dotfiles separately, nor use any additional tools. Everything related to your OS setup is neatly located in one place, written with same language and uses one tool (though with home-manager addon, and optionally something like agenix if you need secret management).
Yeah, I recently switched to it and it's fantastic, I love the password manager integration too so I never have to worry about accidently pushing secrets to my repo.
I've been so inspired by your that I made my first video myself. You made it so simple to use arch, i3, nvim, tmux And im eveusing catppuccin. Thanks for your efforts! Also commented on "why i love programming" but I guess you dont view comments on old vids 😅
Just use nix and home manager. I use it to manage my work Mac, my NixOS desktop, my Ubuntu WSL instance, and my NixOS home server. One config, 4 machines.
The issue with `stow` is that it's an extra dependency, and while you don't even need `git` to download a repository and `unzip` is guaranteed to come with every distro, the probability of `stow` being already installed is next to zero. Since you cannot guarantee `stow` availability, you need to download it every time or keep it as a binary in your dotfiles repo, both are meh. And to have a true one-command-install of your entire environment, you still need a custom script that calls it underneath. Not only that, but said script should also ask for credentials to gain access to your private repository, because a real life setup requires two - one for general config files, and a separate one for secrets (e.g. API & SSH keys). Depending on how you store voulnerable data, symbolic link might not be an option. At this point, `stow` becomes a constraint, and it's easier to just write a function or two to replace it.
i just wrote a script to manage my dotfiles (i basically have a file where i list all file/directory where my config files to save are, and then the script copies all the file in a directory, and then i save the directory basically. And it also allows me to restore them on a new machine very easily, needing only git as a depency. i am really proud of my script)
@@Lars-ce4rd I just want something which i give a list of files to save, it goes through them, and if they are not uptodate, it will copy them. I want no symlinks, neither do i want a git bare repo in my home directory, and i want it to just work. Also, i have some options like seeing the diff of the backed up file from the orignial ones, copying backuped files to replace the original ones (ie allowing me to rollback or to restore a backup on a fresh install) If i there is a tool that can do the exact same, without being absurdly complex, i am all for it. Sadly None of the tools i ever tried do all of this
@@no_name4796 Symlinks have a big advantage: they let you edit your configuration files in place. Any changes you make are reflected in your git repo, so you don't need to manually copy files around. Using git with stow can simplify things a lot. You get your diff checking and rollback capabilities with git, and stow handles scaffolding your configuration files with symlinks. But if you think your script fits your needs better, that's cool. Just wondering why you're so eager to avoid symlinks? (I do understand with for example neovim config, where symlinks are broken by package manager, at least if you use lazy.nvim. That's why I have a seperate repo for neovim config.) Also, you might want to check out "chezmoi", if you haven't. I don't really know much about it personally, it seems more complex than using stow so I haven't taken the time yet, but I hear people praising it and calling it the superior and best option for managing dotfiles.
Next level: Maintaining a small ansible project to bootstrap not only dotfiles but entire system configurations. Doing that for a few years now on all of my private systems, never looking back. If you keep the playbooks/roles modular you can easily choose between just updating dotfiles, installing base-packages etc. I just use plain git with a simple config file that ansible reads to know which dotfiles to take care of, but you can easily use stow or any other dotfile handling tool with ansible as well.
Reminder to push your dotfiles to your gitgub. My favorite new way to push and and pull them to other devices. On top of that I do, dotfiles/common or dotfiles/mac or dotfiles/Linux depending on the app
I advocate for sharing your dotfiles publicly, but I wouldn't say "reminder". There are multiple ways to deploy git servers that are more private and secure than GitHub... there are competitive reposit sites, but I recommend self hosting a git server... It's really easy
Personally, I put all files in the root of my dotfiles repository, and add a stow ignore file. this way I just have to run stow . and not on every folders, this is much cleaner as we can put everything in the .config folder
Great demonstration of stow. I used to use stow, but recently transitioned to yadm. Why? Well yadm offers me more of the features I need -- like file encryption
it doesn't really, it just automates it. it includes a variety of command line arguments that negate the tedium of having to write a script, which he really did not go into in this video
@@typecraft_dev Thank you, I have read (a little) more about chezmoi and even though it seems to be a more complete/versatile solution, I will use gnu stow, it's simpler and does exactly what I need.
I was wondering why the heck we need something to manage dot files, don;t you just include them in backups? Then I watched the video. Now I have stow and a dotfile repo.... I am a believer. I had to refactor my bashrc script to include tokens from a separate unmanaged file but I should have done that anyway from day 1.
So i am a bit crazy about dotfiles, and have used many things out of boredom from chezmoi, custom utilities, and now im at ansible.. yes it is crazy but at the same time it sets up the whole device, and i kinda like it but i kept my dotfiles inside a single directory so i could use stow or anything if i ever wanted to
Stow isn't really doing anything special besides creating the symlink, correct? The directory naming convention basically just allows you to take your config out of its original location and allow you to use stow cli to create those symlinks? The convenience here is you don't have to git init your home dir and maintain a huge .git ignore file?
very interesting because I was about to do something similar by hand but if I understand correctly you could have problems if you use it with computers that for some reason (macOS Linux distro) have different positions of the various dot files. Right ?
Na man, chezmoi is the way. It can handle differences really well. NixOS is too muchz and ansible is just too verbose for something like this. Stow is just barely above just using a few bash scripts. Chezmoi is the perfect amount of configurability and complexity.
Unfortunately no Windows support. I maintain a Windows and arch compatible dotfiles using git bare repos. I use powershell 7 as my FOSS cross platform shell
not sure why this is a problem... stow is a gnu tool, so why don't you utilize stow for your gnu based machines alongside the bare repo, then the bare repo method can be implemented for windows. I think stow is better for Linux since there are more programs that utilize config directories , whereas with windows it's really only the programs you have configs for
Sort of disagree. IMO nothing beats following setup! Locally hosted git (NAS or dedicated device) and Nix(OS) with flakes and home-manager on the system you work on.
if I am understanding you correct, you are linking your bare repo straight to your .config?? If so, here is why stow is better... Let's say I have 6 programs that use the standard config dir, and I only care about 2. instead of having useless/redundant files on my repo, I can use a repo to only keep track of the configs I care about. Then I use stow to link ONLY those files. If you think it would be helpful I can link my git repo for my dotfiles
@@noahjoyner8232 its a bare repo in my home folder and it works similarly to stow, in that, you opt in on what files to add. Someone wrote an article on how to do this method, “Dotfiles: Best way to store in a bare git repository”. I’m not affiliated with the author at all, but this is what I’ve been doing. But I’m trying to decide if the stow workflow feels better.
Hi nerd. You have left me confused. I do not get why would you use this program instead of simply initiating git in your home, ignoring all and then make whitelist or ignore stuff you do not want. I am doing it the second way on all my machines and it has added benefit of tracking my whole user-space (apart from ignored parts) so I can see if some app left some junk somewhere. The only reasons I see for using stow are if you have conflicting configs between machines or you simply do not want to have in your dotfiles everything that you keep in stow
This works, and I did this for a while, but it's a royal pain to basically manage things via a gitignore. It's a lot cleaner to have the git repo in a dotfiles directory and be explicit about what is included. But hey, whatever works for you!
for me personally i have a lot of shit in .config that i dont care about, far easier to just have everything i care about in a separate folder and then just - stow */
@@IainSimmons Of course everyone should use whatever is best for them, I was just trying to understand the appeal of stow. I do not find it hard to add new stuff to exclude list and I really like having everything new show up so I can audit if I want to start tracking it, ignore it or delete. I use lazygit and I only need to press "i" key to exclude
