gitgithubonedrivegithub-for-windows

Do I have a functional workflow using a local Git repository and OneDrive working directory?


I'm relatively new to git and need to set up a workflow in which my working files are stored in a OneDrive directory.

If I understand correctly, this can be done so long as the local git repository is stored on my local hard drive outside of my OneDrive directory. It is also my understanding that I can set this up using: git init --separate-git-dir=.

My reason for setting my version control up in this way is two-fold: (1) I need to be able to access my working files from multiple computers and (2) I need to backup .gitignore directories and files (large data and figure files) with OneDrive

My plan is to access the working directory on multiple machines but only use git version control on one machine.

Is this a workable setup? I've seen many warnings about using git and OneDrive together but it appears to me that the issue is with storing the .git directories in a OneDrive directory. It seems to me that there shouldn't be a problem if the working directories are on OneDrive and the .git directory is stored locally.

That said, I am new to git and would like confirmation from more experienced users.

I've attached a diagram to illustrate what I want to do. Please feel free to correct any of my vocabulary. Also happy to hear alternate strategies to obtain these goals.

And finally, if this is a workable setup, do I need the file structure "..\GitHubRepositories\Project1.git" for my local repository or is it possible (or better) to use some sort of custom name for the repository so that the file structure is something like "..\GitHubRepositories\Project1.git".

Thanks!

Git-OneDrive Workflow Diagram


Solution

  • Is this a workable setup? I've seen many warnings about using git and OneDrive together but it appears to me that the issue is with storing the .git directories in a OneDrive directory. It seems to me that there shouldn't be a problem if the working directories are on OneDrive and the .git directory is stored locally.

    In both cases I believe issues mainly occur when you modify the synced files from multiple hosts without waiting for them to fully sync.

    For example, with the Git repository on OneDrive, depending on how the sync software handles conflicts, lost commits (e.g. continuing to commit on top of not-fully-synced .git/refs) might be hard to notice. With the repository on a local filesystem, that kind of data loss shouldn't happen but I can still see ways to accidentally overwrite files with older ones and sync in the wrong direction.

    In either case there should be no problems if the synced files are modified strictly from one device only. If you do want to modify the files from multiple devices, things would be more-or-less ~fine~ if you always wait for it to sync completely (which should be relatively easy with only one person having access).

    Try to deliberately break it, e.g. make commits on one host then make commits on another and see how OneDrive handles sync conflicts to .git/index or .git/refs/heads/main. I would say that the general "Don't do that" is conditional on "…unless you know your way around .git/ and can attempt to un-mess it up".

    do I need the file structure "..\GitHubRepositories\Project1.git" for my local repository

    The repository can be anywhere. (As it's a "bare" repository, traditionally it is named with a .git suffix but not necessary.) Its path will be stored in a file named .git within the worktree that remains on OneDrive.

    $ cat .git
    gitdir: /home/grawity/tmp/Example_Project.git
    

    Using GitHub to manage this machine switch would require me to commit code states that might not yet be functional

    That's fine. Git commits are not permanent, especially not on "work in progress" branches (or your own personal repositories in general). It's common to have commits like foo: WIP halfway through implementing bar (especially with notes to self-next-monday on the current approach), then squish them into one "foo: implement bar" commit afterward, or throw them away.