this post was submitted on 27 Aug 2024
21 points (95.7% liked)

Programming

17658 readers
79 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 [email protected]



founded 2 years 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?

all 12 comments
sorted by: hot top controversial new old
[–] lowleveldata 12 points 3 months ago

Your project code structure should be independent of your hardware structure. Maybe include the config file to your local drive and setup some file sync to auto deploy those files to the mount drive? E.g. syncthing

[–] addison 4 points 3 months 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 1 points 3 months ago

@[email protected]

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.

[–] FizzyOrange 3 points 3 months ago

I think you need to give more details about why you have this crazy set-up. What are you trying to achieve?

You can git add the file but also add it to .gitignore. But I don't know if that really solves your problem because it isn't clear what your problem is.

[–] MajorHavoc 2 points 3 months ago* (last edited 3 months ago)

Git is really good at two things you are doing:

  • tracking separate files in related but disconnected repositories
  • backing thing up intermittently when access is available

I don't know your exact scenario, but you've shared enough that I can confidently recommend:

  • the files on each device that is removed and restored should in a separate repository
  • you should at least consider using git init --bare somewhere in this recipe - you can put a remote on a removable drive, and use git pull and git push to sync to it
[–] [email protected] 2 points 3 months ago

The odd config files on inconsistent drive should just be symlinks (I think you want hard links?) so that your repo can contain all your actual code and file tracking. If necessary, keep a script on hand that can be run when mounted to recreate broken links.

This is a very strange setup and goes against standard practice separation of software and hardware unless this is some embedded thing in which case you wouldn’t have a repo on it at all.

[–] mcmodknower 1 points 3 months ago

You can just not git add the one file on the secondary drive when it is not connected. This schould not be that much overhead and (at least for me) it is much simpler than any other solution. Ps: Why do you want that one config file on the external drive and not on the main one?

[–] [email protected] 1 points 3 months ago

Can you clarify if you want to track changes across all the files or just the ones that will always be available? And will you be automatically committing the state of the files at some regular interval or would you only be manually checking in changes?

[–] [email protected] 1 points 3 months ago* (last edited 3 months ago) (1 children)

If you commit the file on the secondary drive then it will be in the same repository as the rest of the code so you will end up with a large tree in that repo or you will need to move it over with the rest of the files. Why not make a symlink on the secondary drive pointing to the config in the repository? This way you can track it in git and have it located on the secondary.

[–] [email protected] 3 points 3 months ago (1 children)

Usually these drives will be mounted on Linux. But occasionally they will be mounted on Windows 10 where I do not have admin or developer mode access, so I cannot depend on symlinks.

[–] MajorHavoc 1 points 3 months ago

If you put a git init --bare push/pull target on the removable drive, then all of git's awesomeness will start working in your favor.

Git knows that a push/pull may switch from Linux to Windows and back. Git knows the remote won't always be there. Lots of nice stuff, for removable drives, if you can make it work.