[qbasic_forever]

git-annex is something to consider too. It's kind of like git LFS in that it doesn't directly store files in the git repo (so the files can be enormous or change frequently without all the overhead of commits in git), but it's more flexible and allows you to direct the files to be stored and retrieved from many different types of file stores (network drives, piles of discs/burned CDs/USB drives, S3 storage, etc.). Basically throw all your music files wherever you want, tell git-annex where they live, and then ask it what music you want on what machines and it will do the rest to go figure out what needs to happen to materialize those files in the right locations.

I'd be leery of storing the music files in a git repo directly as MP3 tags and metadata are a wild west and some music players do wacky things like update ID3 tags with play counts, etc. on every listen (which would require committing and pushing music on every listen!).

[_dain_]

anecdote but last year I sunk three solid weekends into trying to make git-annex work to sync my files between devices, and was defeated. it is such a fucking incomprehensible buggy pain in the ass.

I settled on syncthing instead. it has given me few troubles.

[yepguy]

If SyncThing works for your use case, I agree that you should choose it over git-annex. However, git-annex is also much more flexible than SyncThing.

For example, if you want to protect your music collection from accidental changes and are willing to use it manually from the command line, git-annex will work better. Or when I used it for my music, I had a branch for all my lossless files, and then a separate branch for curated and transcoded files that I used for syncing to devices with less disc space. (Perhaps not the most useful example, but the point is that there are a bunch of git-annex workflows that have no parallel in SyncThing or similar tools.)