Shinonome/dots-hyprland
1
0
Fork 1
mirror of https://github.com/end-4/dots-hyprland.git synced 2026-06-05 14:59:27 -05:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update dist-nix/README

Browse Source
This commit is contained in:
clsty
2025-11-05 19:34:03 +08:00
parent bd04346f16
commit d14d170016
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdata/dist-nix/README.md
+1 -1
View File
@@ -50,7 +50,7 @@ About handling the dotfiles, i.e. `dots/`, if we are doing this using Nix then t
Current state of `./setup install`: Current state of `./setup install`:
- After finishing running `./setup install`, users can modify any dotfiles in a traditional way, and if they run `./setup install` again to update then they need to skip the steps which overwrite the targets that they have modified and later sync the upgrade manually for such targets by themselves. - After finishing running `./setup install`, users can modify any dotfiles in a traditional way, and if they run `./setup install` again to update then they need to skip the steps which overwrite the targets that they have modified and later sync the upgrade manually for such targets by themselves.
- For Hyprland, specially we have a `custom` folder along with `~/.config/hypr/hyprland.conf` which will only get overwritten the first time but not the later times running `./setup install`. - For Hyprland, specially we have a `custom` folder along with `~/.config/hypr/hyprland.conf` which will only get overwritten the first time but not the later times running `./setup install`.
- This works but is not elegant. An experimental solution is using yaml config to store the selected behavior for each target, see #2137. - This works but is not elegant. An experimental solution is using yaml config to store the selected behavior for each target, see [#2137](https://github.com/end-4/dots-hyprland/issues/2137).
If we use Nix to handle dotfiles, then it must be at least better than the current state described above, mainly in terms of convenience and automation. If we use Nix to handle dotfiles, then it must be at least better than the current state described above, mainly in terms of convenience and automation.