| 12 Aug 2021 |
 mewp | maybe I'm wrong, let's see | 07:17:27 |
 bryan | Anyway +1 to the problem being discussed. :) | 07:17:54 |
| bryan | I agree a solution would be nice | 07:18:03 |
 elonsroadster | Thanks bryan I'm glad someone else feels my pain | 07:18:11 |
| mewp | all right, yes, it appears I was wrong | 07:18:52 |
| mewp | weird, I thought I remembered using that | 07:19:09 |
| bryan | +1 to that problem, too | 07:20:11 |
| mewp | stackoverflow says that git update-index --assume-unchanged <filename> should do that | 07:20:43 |
| mewp | source: https://stackoverflow.com/questions/23673174/how-to-ignore-new-changes-to-a-tracked-file-with-git | 07:21:18 |
| bryan | I think I remember darcs has a way of keeping track of local commits that never go upstream, and since I learned darcs before git, I've always missed that feature | 07:21:35 |
| mewp | then again, git faq says not to do that: https://git-scm.com/docs/gitfaq#ignore-tracked-files | 07:22:07 |
| bryan | In reply to @mewp:nurupo.pl
stackoverflow says that git update-index --assume-unchanged <filename> should do that Oh, that's cool/weird | 07:22:11 |
| elonsroadster | yeah that is weird | 07:22:26 |
| elonsroadster | it seems like it would be way better to track this in a flat file | 07:22:36 |
| elonsroadster | seems like it could get really confusing if it were accidentally applied or something | 07:22:48 |
| elonsroadster | but anyway that does do basically what I want | 07:23:00 |
| elonsroadster | I still think there are problems, even with this approach, like for example, if you wanted to import from additional flakes in this modification | 07:24:25 |
| elonsroadster | say you wanted to import a flake for the dev tool you want to use | 07:24:56 |
| elonsroadster | there's still not a great way to do that with this approach | 07:25:09 |
| bryan | It's a slippery slope, though. At what point do you accidentally develop a "works for me" situation if it's too convenient to override things locally | 07:28:02 |
| elonsroadster | bryan: I mean it seems like it could be specifically aimed at nix develop and the devShell attribute | 07:31:06 |
| bryan | True, the package would still have to pass muster in the build phase | 07:31:49 |
| mewp | nix develop --help says that you can pass a profile to it | 07:32:02 |
| mewp | so you could just have separate profiles per rpeo | 07:32:25 |
| mewp | * so you could just have separate profiles per repo | 07:32:28 |
| elonsroadster | mewp: yeah but I dont think that profile can depend on e.g. the pkgs that was used to define the shell | 07:32:34 |
| elonsroadster | youd have to separately maintain that profile | 07:32:53 |
| mewp | that's true | 07:32:59 |
| elonsroadster | so like with haskell, for example, you use a specific haskellPackages set, and that would be defined by the flake, and you would want to use both the compiler and the haskell-language server version that is used to contruct the shell | 07:33:33 |
| elonsroadster | this could for example change over time, and if you do something thats like nix integrated, you would automatically pick up these changes if upstream for example made changes to the nixpkgs, ghc etc etc. versions they were using | 07:34:10 |
