| 12 Aug 2021 |
 elonsroadster | not the checkout, but yes | 07:15:47 |
 mewp | yes | 07:15:48 |
| elonsroadster | maybe im misremembering, but I thought that gitignore only had the effect of making files not report as untracked | 07:16:07 |
| elonsroadster | if a file is part of the repository already I thought the gitignore does not end up mattering | 07:16:23 |
| elonsroadster | but I could be wrong about that | 07:16:29 |
 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 |
