Is there a sane way to use Git as a glorified sync tool?

I do not wish to go through diffs approving every single change.

You should only be seeing diffs you didn't ask for if you have conflicts or you're doing a pull request sort of workflow. If you just pull + make changes + commit + push to the same branch every time, and don't mess with it from another computer between those steps, you shouldn't ever need to see them since your history can't ever diverge into multiple timelines.

As for automatically committing and pushing, not that I'm aware of. It's designed for use cases where you want the programmer explicitly saying "yes, I am done with this part and now wish to inflict it upon other people".

Have you looked at git-annex?

The simplest way to move to a new machine is to commit your latest changes, push them to Github, and then pull them on the new machine. As a software developer, I wouldn’t automate this process because I don’t switch machines all that often and I want my commit history to be clean. It wouldn’t do to commit unfinished work that doesn’t even compile, and then publish it by pushing to Github. Also, I’d want to write a commit message describing each change.

As a writer, you probably don’t care about that, so you’re off the beaten path a bit, but setting up syncing should be doable. One way to partially automate it might be to have your editor update GitHub when you save a file?

I did a quick search and found an emacs package that will automatically commit and (optionally) push on save. It has settings to customize how it works. I haven’t tried it, but it seems suitable?

https://github.com/ryuslash/git-auto-commit-mode

I don’t know how familiar you are with customizing emacs. Please ask if their directions are unclear. (There is an INSTALL file explaining how to install it.)

That script will ensure that the Github repo is always up to date, but the next step would be to do a pull before starting work on your new machine. Since it’s just one command, I would do that manually.

This is the purpose of GitHub and remote repositories. In the middle of something but if someone else doesn’t answer by the time I’m done I can help

git-timemachine

Incidentally, just from a quick glance, I think Magit can do everything this does (and much more).

The problem is, sometimes I work on different machines, and sometimes on different operating systems on the same machine (via dual boot). So I would like to know if there's an easy way to always "sync" the local mirror I am currently working on with the latest changes (also making sure that all changes are pushed). Essentially, I am asking if I can make Git work like Dropbox or OneDrive by automatically accept changes as long as they are the most recent version of a file. I do not wish to go through diffs approving every single change.

So what is the actual problem? Every time you try to commit and/or push changes you have made, you have to review a diff of those changes and approve them?

That sounds like you're trying to fix a merge conflict.

Generally, there are two ways to handle merge conflicts:

1. Always maintain clean working copies, in every version of the repository, across all of your computers
2. Use branches

Option #1 (usually) works fine if you are the only person working on a repository. Option #2 (usually) is preferred for collaborating with other people.

I'll leave it up to you to figure out what branches are, how to use them, etc.

For option #1 though, here is what I mean:

Every time you clone a git repo to your computer, you get a local working copy of that repo. Your working copy is the same as the remote copy hosted on GitHub. It is "clean" and "in-sync".

When you make changes to the (local) repo on your computer, you are making the working copy "dirty", until you successfully commit and push your changes to the (remote) repo on GitHub. After you push your changes, your repos (local and remote) are in-sync again. They once again have the same state, you once again have a clean working copy on your computer.

If I had to guess, you are encountering merge conflicts because you are working on the repo on Computer1, but not committing and pushing your changes when you are done working (probably because the changes themselves aren't done; for example: not having fully rewritten a paragraph yet).

So Computer1's (local) working copy is dirty. Its changes have not been committed and pushed to the remote repo yet, so it is "out-of-sync".

Then later on, you work on the repo some more from Computer2. This time you actually do commit and push your changes, such that Computer2's (local) working copy is clean, and in-sync with the remote repo.

Now, Computer2 and the remote repo are in-sync with each other, but out-of-sync with Computer1's repo.

So you go back to Computer1, finish your work there, try to commit the changes, and experience a merge conflict.

The key to avoiding this situation is to always commit and push your changes when you are done working, not when the changes themselves are finished.

Finished rewriting a paragraph? Commit-push. Started rewriting a paragraph, but now you have to go change a diaper? Commit-push.

Always commit and push your work when your work session is done. Religiously do that, and you will always maintain a clean working copy in every instance of that repo, on every machine.

Again, this way of working with git does not universally work well. It generally is not recommended to collaborate with other people this way.

Also, a concern with committing and pushing unfinished work is that it makes it difficult to find and pick-up where you left off. Personally, I litter TODO: comments throughout my files (prose and code) to help me get back to work later on. For prose, I also sometimes wrap sentences and paragraphs with curly braces ({}) to signify to myself that I want to rewrite whatever is contained within the braces.

This workflow might be good for you, or you might prefer branches, or you might prefer to use something other than git entirely. This is what works for me.

I sync my home folder with git (between many machines) and syncthing (between two machines). Syncthing might work well for you because it has automatic conflict resolution and backs up what would be "lost" under git (hidden behind automatic merge conflict resolution) as a *.sync-conflict.* file which may be easier for you to recover.

Here is something I run frequently:

ssh pc -t tmux new-session -A -s phone "'fish -c clean_home; exec fish'"

The clean_home function syncs git automatically by doing something like this:

git add . && git pull && git reset

Using this technique of staging changes, pulling, and resetting the stage eliminates a lot of handholding that git wants when it sees incoming changes modifying an unstaged file.

Related files which may be important:

• .gitconfig
• syncpcs
• wip

Here is how I use git in a "centralized" sync context (similar to rsync--though bidirectional sync works unhindered... it's just controlled by the client).

It's useful for if you want to push commits directly to a web server or something like that. I don't know if it's exactly what you want but reading your title reminded me of it and some of your words make me think this might be helpful:

On the "server"

git config receive.denyCurrentBranch updateInstead

On the "client"

git remote remove origin
set user (id -un)
git remote add server ssh://$user@unli.xyz/home/$user/github/(path basename (pwd))/
git branch --set-upstream-to=server/main main
git fetch

But if you work with multiple people this type of configuration will lead to merge conflicts on the server HEAD which is why bare repos are used for collaborative contexts 99% of the time

Personally I do not recommend trying to automate or hide any of the complexities of git with cron jobs or layering on additional tools--this just adds more potential surface area for things to go wrong, and if you're not actively involved in the sync process it could stop working and you might not even realize it until it's too late.

I use git for the exact purpose that you state for my own writing and I think once you engrain the necessary routine to muscle memory it's not too bad (admittedly I use git daily for my job too so it comes very naturally to me). You need to git pull changes from the server before you start writing to sync up your local machine, git add + git commit whenever you want to save a snapshot of your current state, followed by a final git push to sync everything you've done in this writing session back to the server when you're done (or click whatever buttons do the equivalents of those commands if you're using a graphical git application). It's really just those three things to ensure you're always in sync everywhere and don't lose any work. The only situation where you'd ever potentially need to look at diffs and approve things is if you forgot one of those steps and had conflicting work on two machines simultaneously, but once you've got the routine down to muscle memory that should hopefully not happen very often or at all.

I have no answer for your question, just small anecdot. Few years ago I read in a few sources that git does not work well with big files. (Mostly from performance perspective I recall?). I do not have such experience, and maybe it's not a issue anymore. So, please, correct me if Im wrong.

Since I don't think anyone has said this yet, and I think it's the simplest solution:

git fetch origin
git reset --hard origin/master
git clean -xdf

(This is assuming your branch is master and your remote is called origin.)

This will reset your local remote to be the exact same as it exists in Github. No merging, no rebasing, it just overwrites your local repository with the head of your branch from Github.

You will lose any local changes, so make sure you don't want them and push them first if you do.