this post was submitted on 27 Aug 2024
20 points (95.5% liked)

Programming

17024 readers
274 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

This is more of a system config question than a programming one, but I think this community is the best one to ask about anything Git-related.

Anyway, I am setting up a new project with hardware that has 2 physical drives. The "main" drive will usually be mounted and have 10-20 config files on it, maybe 50-100 LOC each. The "secondary" drive will be mounted only occasionally, and will have 1 small config file on it, literally 2 or 3 LOC. When mounted, this file will be located in a specific directory close to the other config files.

I would like to manage all of these files using git, ideally with a single repo, as they are all part of the same project. However, as the second drive (and thus the config file on it) will sporadically appear and disappear, Git will be confused and constantly log me adding and deleting the file.

Right now I think the most realistic solution is to make a repo for each drive and make the secondary drive a submodule of the main. But I feel like it is awkward to make a whole repo for such a simple file.

What would you do in this situation, and what is best practice? Is there a way to make this one repo?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] addison@programming.dev 4 points 3 weeks ago (1 children)

I haven't seen git update-index --skip-worktree mentioned yet. You can read about the motivation for this feature in the git scm docs.

I have used it in the past when a professor wanted us to clone repos for assignments that included some opinionated settings for VSCode that I didn't want to use. Skipping the work tree for that directory allowed me to change or delete the config files without git complaining every time I pushed or pulled or whatever, and the changes I made remained local.

You could set up a couple git aliases to "freeze" and "thaw" your config files on the second drive.

[โ€“] addison@programming.dev 1 points 3 weeks ago

@anon2963@infosec.pub

On this same train of thought: there's also git sparse-checkout which uses the skip-worktree bit under the hood, and may have an easier interface. I'm not sure though, I haven't used it yet.