| 12 Aug 2021 |
 chreekat | That's what I thought, too, but I'm pecking at my phone right now and can't verify | 07:16:52 |
 mewp | maybe I'm wrong, let's see | 07:17:27 |
| chreekat | Anyway +1 to the problem being discussed. :) | 07:17:54 |
| chreekat | 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 |
| chreekat | +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 |
| chreekat | 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 |
| chreekat | 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 |
| chreekat | 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 |
| chreekat | 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 |
