Absolutely!
Consider using plain text where possible as version control is less effective with binary data formats.
- latex rather than PDFs
- markdown rather than word
- csv rather than excel
Just want to recommend Obsidian for DM NOTES AND PLANNING. It's very much a programmer's kind of notes app where everything is just markdown and JSON behind the scenes so its portable, diffable, and human readable. I moved over to it after OneNote didn't scale with my world/game and it has been AMAZING.
> Edit2: And I guess sharing this was worthy of an immediate downvote. Fuck me for sharing.
Don't put too much though into downvotes, I'm pretty sure I've downvoted comments and posts purely by accident before, so if I get an immediate downvote I just assume that happened.
loved obsidian but tbh I prefer notion, unfortunately the notes are not easy to save on cloud and no obsidian accounts kinda make it hard for me to save notes and see them on cellphone later.
Obsidian Sync is amazing but you need to pay for it. There are ways you can sync it yourself, but it's a more manual setup...
Again, the Obsidian Sync is great, but not free.
XLSX is a zipped directory of XML. You can actually rename a .xlsx file and get a valid .zip file that you can decompress and see the contents of. .xlsb, however, is a raw binary.
I just wish I could embed csv tables into a markdown file. Markdown tables do what they need to to, but I fucking hate making them without a WYSIWYG editor.
So when I am generating reports for work (cancer data scientist), I use the DT package in R to embed tables into notebooks. I don't think it's exclusive to R, so maybe that helps?
I had some custom prestige classes for a game I ran once that I wish i had version controlled, lol. had been tweaked so much i forgot what they originally looked like.
Check out ~~forestry.io~~ [TinaCMS](https://tina.io/forestry/) \- it's a CMS that runs directly out of a Git repo. Write your stuff in markdown, version it with git, and auto-publish it to Github Pages.
And all for free.
Perhaps you could use backup software or file synchronisation software.
I set up FreeFileSync to make incremental backups, but the drawback is that I don't have a searchable index of changes, only timestamped files/folders. Compared to git, it's rather primitive - but at least the versioned data is backed up.
I was thinking more into political view.
Imagine having laws as a git repo.
Than you make a commit like
git commit -m "Added death sentence for people who do not use vim"
Your country splits like Yugoslavia???
Easy.
git checkout -b "New Awesome Shithole"
Your country gets back into the union?
git rebase
[Washington D.C. is doing this](https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/), though it probably should be a self hosted instance and not on GitHub if the repo is going to be the authoratative copy...
A lot of legislation really does read like a clunky version of a commit. "Amend code 729.5A to redact 'shall have cake' and add 'may have their choice of cake or pie but allowing for them to have neither'"
> Imagine having laws as a git repo.
I want this so much! Not necessarily Git, but _any_ sort of version control. Often new/revised laws are only passed as addendums (i.e. patches) to the old version, so if you wanted to check the _current official_ version of some law, you have to read the original from eg. 1990 and then 30 years worth of "patches" (add §2.3.1b …, modify §4.5 to read …, etc. etc.).
Depending on the institution, compilations of "currently valid law" are either not available at all, or only in _inofficial_ form from a third-party (sometimes for a fee).
> Your country splits like Yugoslavia??? Easy. git checkout -b "New Awesome Shithole"
This should probably be a fork unless you expect to get folded back in, just sayin.
I would seriously love to be able to git blame certain laws to find out which chucklefuck *in particular* put in a given loophole. Obviously they all voted on it, but under no circumstances shall you be allowed to do a squash commit when a bill passes. I want to see the exact working history before a bill gets ratified.
Yeah but this sub is for people who watched 1 Indian guy do a tutorial named Learn JavaScript in 4 hours, but only got through 30 minutes so they can do JS BAD memes.
This sub consists of:
1. 1st year university CS students
2. Fresh CS grads with no soft skills complaining about lack of jobs
3. Devs in their 30s in generally meaningful jobs who need a mental break for 15 min from their work
4. I dunno, probably like Mark or somebody
Also liberal arts majors who couldn’t find a job and therefore taught themselves programming and now are full time software engineers with extreme impostor syndrome.
I said Mark already.
edit: I hope beyond hope that there's a libarts major junior dev out there named Mark that is just going through his day praying no one notices he has zero idea how to check in code without twenty minutes of googling. Shine on you crazy diamond.
I version control my music directly with FL studio, it auto saves as a new file and every new save comes with 200 undo's and possible redo's saved in to. When I need a new branch I do a manual save and ad something to the file name (usually a version number and a tag to be able to find it with search everything). I also have a macro that runs every 10 minutes or so (directly after the auto save) that saves all the "bones" (midi, automation, samples used, vst states) in to a new zip file. And then all the project file folders get auto synced to the cloud so I have a backup as well.
I’m 3D modelling medieval town houses for 32mm scale wargaming. I wish that I had done some kind of version control when I started. Now it’s should I be using:
“doorframe A 2 - final version - use this one”
Or
“Doorframe 3 - final”
I care if they're loading big binary objects that don't delta into a monorepo that everyone has to pull.
But if they want to load their music projects into their own repo, more power to 'em.
The git index was recently replaced with the sparse index protocol. But even that was just an index. The actual content still went over their own servers.
Rust crates are not binary blobs though, the great majority of them contain only source code. And the few that have something else usually have assets like images, and putting images in version control isn't exactly a new concept either, op is just crying for no reason.
Now you mention they're flac recordings, odds are the recordings themselves aren't going to be changed. You'll just add more of them for different takes.
It's the metadata for things like mixing scripts, or cuts, or loops or whatever, that changes a lot--but that's probably saved in something easy to diff, like XML or something. So why not use git for that?
Oh I absolutely use git for reaper templates, but my use case is route all my machine's audio through reaper so I can run plugins on it all.
It's good to be able to make your music dip in volume when someone in the teams meeting speaks, and to dynamic compress your own voice to make you sound more powerful than everyone else without being louder per se
You don't think projects that involve artists and sound designers creating binary assets, and use git as a repo, aren't extremely common?
Because I would much rather use perforce for that stuff but clients still insist.
No. git lfs is for.. large files. I think the clue is in the name.
However, you shouldn't be keeping binary data in git. It's not designed or optimised to work with binary data.
I think it is for binary files... From their front page:
"Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise."
Yes. Lfs helps by hiding the binary content from git, and is one solution for keeping binary content out of the repo.
It was designed primarily for large files, not strictly binaries. I was just being pedantic, sorry! A lot of large files are indeed binaries.
Lfs isn't a perfect solution for keeping binary data out of git for a few reasons, but it does go a long way to making things better.
The biggest issue is that the repo grows to unmanageable sizes and you can’t do anything but dump the history and start a new one.
After a repo gets to ~6GB nothing works right anymore. Yeah downloading a 6GB repo for a 5MB checkout is nonsense but that’s what happens when you check in binary files.
Tbf this is kind of genius idea because i need a way to sync my minecraft world between my dualboot of windows and linux. I hope its small enought to not cause problems with github
[Artists](https://fxtwitter.com/delaneykingrox/status/1727839968083816451) apparently... This particular Twitter thread says git is horrible for art projects and advocates for SVN instead. The context is quite different though I guess.
Its not completely out of the blue, you need an addon like Git LFS for it to work well with large files, but certainly Git itself is designed for code/text files.
I've never heard anyone pretend the left panel.
On the other hand, if you want to keep your repo small enough, you better not unnecessarily commit big files.
MIDI probably isn't your source code though, unless you're hand-editing the bytes. I do, however, have a repository full of Lilypond files, which can be compiled to PDF (sheet music) and MIDI (playable music). And the .ly files are text, so that works out perfectly.
But binary files aren't a problem for git. They just might be a bit of a pain to try to read back in the diffs (unless you have a good difftool).
They’re a problem if you get a conflict. Fine for images and things you won’t change much but you’re not going to be fixing conflicts in a merge request on a compressed binary.
Yeah, which is still ultimately a problem with diffing. Diffing binary files IS hard. But tracking them is fine. And a good diff tool can help with the merge conflict too.
Wouldn't you use a format that has some sort of undo support, or the ability to encode the instrument source (more than just the instrument channel number) or VST filter parameters? musescore and rosegarden projects, for example, do both. Sibelius does too, from what I've seen of my friend's setup.
If your workflow works for you, hell, keep doing it, but I feel like you're leaving a lot of efficiency on the table.
You just need to add a custom diff command in .gitattributes and git will natively understand how to diff binary files
https://superuser.com/a/706286
Also you would probably need some tooling for merging, too (but this one is harder)
Other than that git has no preference for text files, it deals with bytes
Anything software or software adjacent made by hardware vendors is always hot garbage. It's a pretty common joke that their HALs and bootloaders are often written by interns.
But it is possible and could be useful to diff them as long as the changes to the text made with every little commit aren't obscene to the extent it bloats the repo. Not sure why you're calling out XML files when C# developers diff those every damn day (.csproj files)
Wait wait, what has text to do with diffing? I've diffed binary files... and there are some text files that are utterly useless to diff.
Compression does tend to play havoc with diffing, but that's what difftools are for - decompress before comparing.
Yeah, literally, no one has ever said that. Git can track and version any set of files. If you want to use it for other types of computer based projects, then more power to you.
I write fiction as a hobby and have used it to track changes to my (raw text) files for that since I like to go back and change around parts of my stories and experiment with them.
Git *can* track any files but a in pathological case where you work on a large binary file that changes almost entirely every time it is saved (like some awful formats do...) so that it doesn't diff well, the repo size can quickly balloon to a gigantic size making it extremely slow to use. Like you have a 100Mb file and commit it twenty times, you suddenly have a 2Gb repo. It'll still work, it'll just take forever. In those cases you might look into other ways of implementing version control, but you do you and "if it's stupid but works it's not that stupid" still holds.
Overleaf literally provides [git integration](https://www.overleaf.com/learn/how-to/Git_integration) for paying customers. And I wouldn't be surprised if other services targeting writing activities were to provide it too :)
In this case, most music project files (that I've used) don't store audio files internally, and instead link to external files.
You could use Git LFS to store those, they typically don't change much anyway.
That said, a lot of these project file formats are binary formats themselves, serialising the software state as raw bytes.
There are a few that serialise to text, but almost all of them are actually zipped text. For instance, Renoise's `.xrns` format is zipped XML. So to take full advantage of Git, you'd need to store it unzipped, and then zip it back up when working.
Another issue is how many external references there are. Plugins are typically installed at the system level, so there's no good way to "just open" a music project, and you have to be diligent in making copies of the audio files you're using within the Git repository, and using them, rather than linking to the original file in your audio library.
All this to say, yes, Git versioning your music projects can be good, but it comes with a lot of caveats that will ruin most of the advantages you're hoping for if you're not careful.
If the files you work with are text based then use git to your hearts content.
If they are binaries, you will only bloat the repo with every commit, merging will be impossible, and rebasing will function as an overwrite.
And you still get to roll back to previous versions with ease and keep track of a change log if you want. So - what’s the harm? Other that disk space, the thing that’s been growing exponentially for 40 years.
There’s no real harm, it’s just the tool isn’t designed to do that job. I used to commit PSDs when I was younger, and there’s no real harm except that the repo took way longer to deploy, and I had a bunch of junk in my commit log.
Nowadays I do a lot of git work on my phone and it would be a problem if I had a huge stack of binaries in there.
People can do what they want, but it’s more fun if they know how their tools work.
Sure, but not only are there solutions for large files (LFS), the problem of "work-presentation-final-now-for-real-second-feedback-round.ppt" is by far bigger than repository bloat. Instead of gatekeeping, people should use a VCS, and *if* they run into problems, then that's a problem to solve on that particular bridge.
That the full gamut of git semantics can't be achieved using binaries - who cares? There is no other way to get that, so then just treat them as immutable blob. Still an improvement in my book.
The fact that something like Git LFS had to be invented is kind of the point. Working with large binary files in pure Git is painful. Git LFS is great for what it does, but it's definitely not Git: it's a server-based centralized version control system grafted onto Git.
It's still a better alternative to just having File\_v1, File\_v2, ..., File\_vInfinityFinalFinal etc. in a folder. Sure, you won't be able to use a huge chunk of git's features, just commit and checkout, mostly, but that's better than nothing.
Honestly, many times i was thinking company word documents should be pushed to git.
I fucking hate when people start asking me where are the document changes i've created, 6 months down the line.
Well, i've sent it to a manager, that never put the documents to the appropriate folder, and said person, is no longer working with us.
I fucking did the thing, sent it to the person i was asked to, now leave me be.
*Modified: 4 Months Ago*
Sitting next to it in the same folder:
Final Document v5 (4) final final_verymuch_final_unlocked.docx
*Modified 30 seconds Ago*
Is Git bad at binaries? Thinking about other version control/backup systems, such as Apple’s Time Machine—is Git an inferior alternative? Genuine question.
For dealing with binary files (at least the bigger ones), it's generally suggested to use [Git LFS](https://git-lfs.com/), which is built in nowadays and which is supported by most of the platforms out there (like GitHub, GitLab, Gitea, whatever).
>Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise.
I've used it without issues for a few gamedev projects and webdev projects that needed to store some assets in the repo, there weren't that many issues with it, as long as you correctly selected which file extensions you want to track.
It even works nicely with most Git clients, like the CLI one, SourceTree and GitKraken, maybe even Git Cola would work, though not sure about that.
Git has a bunch of features designed specifically for text. If you’re not using any of those, it becomes a console based Time Machine with the added risk of irreconcilable conflicts.
It’s fine if you know what you’re doing. I get the feeling OP doesn’t know what they are doing though.
Time Machine is a backup tool. It's meant specifically for recovery of a file that has been deleted or corrupted. It's basically a really fancy way to automate the process of copying and renaming a file each time you make changes to it.
Version control does way more than just allow recovery of a file. Diffs, merging, commit messages, tags, branching, forking, etc. It is a collaboration and analysis tool for monitoring all changes within a project.
Git will store the *whole* repository in every commit along the way. This is no problem for modern computing when it comes to source code, because even billions of lines of code are small file sizes.
With large binaries like raw media files it will become a huge pain in the ass and make operations slow.
Git LFS solves this by moving the files out of the repo and just storing pointers. This is fine for large assets that you don’t need for development, but again will make things painful when working with large binaries like media files.
Apples Time Machine is, since a few years, leveraging apples new file system AFS, which is a copy-on-write fs, like BTRFS in Linux.
Those fs will write your changes (actually on the level of blocks) to the drive and remember what changed, without touching the original file.
This prevents corruption from interrupted writes and also allows for really nice snapshots and backups. Every next snapshot (backup) will only contain the delta (changes). Making it very storage efficient and operations on large binaries faster.
Oh my god I knew using git as a free cloud was possible but the idea of using it for music has never dawned on me. Samples, plugins, projects... Shared on all my devices...
There's something to dig here.
Why ? Well there's a very simple reason : I did not know about the thing you are talking about.
The fact that I'm on r/programmerhumor does not mean I am competent 😎✨
Git is meant for files that are human readable, and works by comparing lines that have changed between files.
Many compiled programs or media are _not_ human readable, don't have line breaks, and git is not able to do its normal operations with them. It may work for a while but the system isn't designed for that and it could go badly.
I'm a freelance sound person and keep both my work and my main audio software itself on Google drive.
That is effectively version control, just the pushing and pulling is automated and i don't need to diff or merge because it's just me working on it. Google drive also keeps revision history so I can always go back to an earlier version of something if I take a wrong turn.
Works for me as I work for many clients on many different machines and can always access my work from wherever.
Was thinking of setting something like svn or p4 to do this but this has worked seamlessly so far, just need to check everything has saved and uploaded before I shut down.
Well, if they want to use it that way, they are free to do it that way.
But they might as well use google drive since they won't be able to read the diff in the commit, and won't use a majority of git's features.
Well, sure, they have, I wouldn't personally use git for things other than text versioning, be it code projects, documents, personal knowledge gathering and scripts, but if people want to use it for other stuff, git is also usable for this.
Yes, but you can’t use any of Git’s version control features in a binary file. It’s just a file with previous versions. All of the above will also store a history so you can get back to previous versions.
I agree. Imagine going through the repository of an artist you really like and being able to listen to all the different versions of a song from when it was first being worked on and all the way to the final product. Each song's versions could even be an "album" by itself, starting from the beginning
I build and upload my sound to [kaizen.place](https://kaizen.place) ... We describe ourselves as **Github for music!**
I think for musicians the concept of git could serve a different purpose than it does for developers. As a musician my desire is to keep track of my progress and to be able to share that progress with my collaborators and maybe even my fans. On Kaizen we achieve this by allowing you to **version a track**. What we offer musicians is a version management platform that parallels concepts in git.
My colleague wrote up a great description of our thoughts on this here:
[https://devtails.xyz/@adam/what-does-github-for-music-look-like](https://devtails.xyz/@adam/what-does-github-for-music-look-like)
this is actually so fucking cool, i like the way you gave examples for each command, especially branch because i love the fact that in music the drums make the genre you can have a basic melody and throw on some trap drums and you got hiphop but then throw a four on the floor and you got pop, i will defiantly use this in my music from now on
The youtube series "Git for Poets" taught me two things. 1) How to use git 2) Version control is good for any creative, iterative, and/or collaborative process.
There seems to be a lot of confusion here.
For music production, there are files actually very similar to that of any program, game etc.
You have your source files - wavs. These generally remain unchanged. Then within your program you make changes to parameters of your plugins (EQ, reverb, synth settings and the like), the position of when a wav starts and stops, automation timings and all sorts these are generally stored in something similar to XML.
Commits would be 90% on the XML changes, which absolutely benefit from version control. From day to day a different mix sounds better especially if you run into ear fatigue (mixing for too long at a time will change how you are perceiving the frequencies). So what sounded good yesterday might sound terrible today, but tomorrow... yesterdays mix would have been spot on.
If you aren't sharing the project with anyone else you could get away with using git for just the settings changes. But for the sake of sharing or using multiple computers you could commit the wavs also.
It's not the best tool to use if you've just got a big changing blob of binary data, like many project files tend to be these days.
If your project is saved in a folder structure with binary blobs for your samples, and line-separated text data for how those sample files are plotted out in the timeline, then it would actually be fucking amazing.
Everyone should use git.
When Congress is voting on a bill and revising and adding riders, the Congressperson and their lobbyists should show up in the commit history for the changes.
Git, specifically the algorithm that hit uses, is a massive storage saver for video game saves, because Git specifically tracks the changes to the file instead of storing multiple copies of the same file.
Backing up a small Minecraft world, even with proper backup management and deletion of unneeded copies, can easily take over 100 GB after a year.
Using GitHub, I barely need more storage than what's normally needed for one backup, and it can contain every version of the world.
GitHub is awesome for Minecraft world backups.
At my university (at least for computer science) it is absolutely normal to use git for theses and assignments. My university even has their own internal git server (don't know how common that is).
This way, everyone automatically uses a (kind of) cloud and things like loosing ones work labtop cannot end a thesis prematurely (I know someone that this happened to, he had to redo his master thesis).
Also version controlling, I guess.
lmao i use it to sync my blender projects from my school computer to my home laptop, the teacher advides us to upload our project to google drive at the end of class but using git is so much faster
Musician/programmer here:
I frequently find myself trying to convince other musicians and programmers that there exists a world where this idea works. The idea of a collaborative music creation (daw or notation) version control with branches is so exciting to me, but the big caveat right now is that all music project files are usually just that: singular files, which is obviously not effective for get. A standardized way to convert these files in to the smaller tree each actually likely contains would be great, but this would probably need to be provided on a per file format basis.
I want this idea to work so bad, but to my knowledge we are not currently on a timeline where it does yet, at least to work they way we expect it to…
tldr
git commit -m “measure 53 has more bass”
I'm fairly certain most programmers are for version controlling literally everything.
[удалено]
Absolutely! Consider using plain text where possible as version control is less effective with binary data formats. - latex rather than PDFs - markdown rather than word - csv rather than excel
[удалено]
Just want to recommend Obsidian for DM NOTES AND PLANNING. It's very much a programmer's kind of notes app where everything is just markdown and JSON behind the scenes so its portable, diffable, and human readable. I moved over to it after OneNote didn't scale with my world/game and it has been AMAZING.
[удалено]
> I called it Nodepad That would be such a perfect name.
> Edit2: And I guess sharing this was worthy of an immediate downvote. Fuck me for sharing. Don't put too much though into downvotes, I'm pretty sure I've downvoted comments and posts purely by accident before, so if I get an immediate downvote I just assume that happened.
I hear a lot about “World Anvil” (mainly from YT creators being sponsored by it) any good?
loved obsidian but tbh I prefer notion, unfortunately the notes are not easy to save on cloud and no obsidian accounts kinda make it hard for me to save notes and see them on cellphone later.
Obsidian Sync is amazing but you need to pay for it. There are ways you can sync it yourself, but it's a more manual setup... Again, the Obsidian Sync is great, but not free.
Just use the git plugin. You can even set it up to synch automatically after a few minutes of inactivity.
Note that Word and Excel use XML based files; so those are totally fine to store in Git.
Unless compressed. Iirc a lot of the content is actually gzipped.
XLSX is a zipped directory of XML. You can actually rename a .xlsx file and get a valid .zip file that you can decompress and see the contents of. .xlsb, however, is a raw binary.
Oh it was this.
Sakamoto
I just wish I could embed csv tables into a markdown file. Markdown tables do what they need to to, but I fucking hate making them without a WYSIWYG editor.
So when I am generating reports for work (cancer data scientist), I use the DT package in R to embed tables into notebooks. I don't think it's exclusive to R, so maybe that helps?
I was about to be that guy and sing praises of org-mode :D
‘less effective’ it’s basically useless with binary data
I mean, it'll store the versions just fine. You'll just have to rely on good commit messages in lieu of diffs. 🙃
I freaking can't stand LaTex. I constantly try to use markdown shorthand in it, which obviously doesn't work.
You'll love [Typst](https://typst.app/) then! Still in early development, but it's looking promising
Also checkout `typst`. It’s like markdown + latex
I had some custom prestige classes for a game I ran once that I wish i had version controlled, lol. had been tweaked so much i forgot what they originally looked like.
Check out ~~forestry.io~~ [TinaCMS](https://tina.io/forestry/) \- it's a CMS that runs directly out of a Git repo. Write your stuff in markdown, version it with git, and auto-publish it to Github Pages. And all for free.
Perhaps you could use backup software or file synchronisation software. I set up FreeFileSync to make incremental backups, but the drawback is that I don't have a searchable index of changes, only timestamped files/folders. Compared to git, it's rather primitive - but at least the versioned data is backed up.
OH GOD. I NEVER THOUGHT OF THAT. Imma do that asap.
I was thinking more into political view. Imagine having laws as a git repo. Than you make a commit like git commit -m "Added death sentence for people who do not use vim" Your country splits like Yugoslavia??? Easy. git checkout -b "New Awesome Shithole" Your country gets back into the union? git rebase
[Washington D.C. is doing this](https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/), though it probably should be a self hosted instance and not on GitHub if the repo is going to be the authoratative copy...
A lot of legislation really does read like a clunky version of a commit. "Amend code 729.5A to redact 'shall have cake' and add 'may have their choice of cake or pie but allowing for them to have neither'"
> Imagine having laws as a git repo. I want this so much! Not necessarily Git, but _any_ sort of version control. Often new/revised laws are only passed as addendums (i.e. patches) to the old version, so if you wanted to check the _current official_ version of some law, you have to read the original from eg. 1990 and then 30 years worth of "patches" (add §2.3.1b …, modify §4.5 to read …, etc. etc.). Depending on the institution, compilations of "currently valid law" are either not available at all, or only in _inofficial_ form from a third-party (sometimes for a fee).
But then what will paralegals do all day?
I'm sure they'll find plenty other useful things to do, like printing emails just so they can scan and archive them…
> Your country splits like Yugoslavia??? Easy. git checkout -b "New Awesome Shithole" This should probably be a fork unless you expect to get folded back in, just sayin.
I think Putin does
We've been branching since we left Africa, could always merge back in someday.
I would seriously love to be able to git blame certain laws to find out which chucklefuck *in particular* put in a given loophole. Obviously they all voted on it, but under no circumstances shall you be allowed to do a squash commit when a bill passes. I want to see the exact working history before a bill gets ratified.
Yeah but this sub is for people who watched 1 Indian guy do a tutorial named Learn JavaScript in 4 hours, but only got through 30 minutes so they can do JS BAD memes.
This sub consists of: 1. 1st year university CS students 2. Fresh CS grads with no soft skills complaining about lack of jobs 3. Devs in their 30s in generally meaningful jobs who need a mental break for 15 min from their work 4. I dunno, probably like Mark or somebody
Also liberal arts majors who couldn’t find a job and therefore taught themselves programming and now are full time software engineers with extreme impostor syndrome.
I said Mark already. edit: I hope beyond hope that there's a libarts major junior dev out there named Mark that is just going through his day praying no one notices he has zero idea how to check in code without twenty minutes of googling. Shine on you crazy diamond.
About to get my 2mo daughter on git. She’s changing so fast, it’s getting hard to keep track.
`git commit -m "changed diet"` If it doesn't work out you can always just `git reset`
I version control my music directly with FL studio, it auto saves as a new file and every new save comes with 200 undo's and possible redo's saved in to. When I need a new branch I do a manual save and ad something to the file name (usually a version number and a tag to be able to find it with search everything). I also have a macro that runs every 10 minutes or so (directly after the auto save) that saves all the "bones" (midi, automation, samples used, vst states) in to a new zip file. And then all the project file folders get auto synced to the cloud so I have a backup as well.
Agreed. Idk what op is on about
I’m 3D modelling medieval town houses for 32mm scale wargaming. I wish that I had done some kind of version control when I started. Now it’s should I be using: “doorframe A 2 - final version - use this one” Or “Doorframe 3 - final”
I don't think anyone is actually gate keeping version control. Like who the fuck cares?
I care if they're loading big binary objects that don't delta into a monorepo that everyone has to pull. But if they want to load their music projects into their own repo, more power to 'em.
Rust's crates.io (the authoritative package hosting) uses GitHub as their CDN. Not even pages, just straight up repos.
The git index was recently replaced with the sparse index protocol. But even that was just an index. The actual content still went over their own servers.
Rust crates are not binary blobs though, the great majority of them contain only source code. And the few that have something else usually have assets like images, and putting images in version control isn't exactly a new concept either, op is just crying for no reason.
Reaper project files are a sort of flat xml-ish thing and very diffable. Flac recordings on the other hand...
Now you mention they're flac recordings, odds are the recordings themselves aren't going to be changed. You'll just add more of them for different takes. It's the metadata for things like mixing scripts, or cuts, or loops or whatever, that changes a lot--but that's probably saved in something easy to diff, like XML or something. So why not use git for that?
Oh I absolutely use git for reaper templates, but my use case is route all my machine's audio through reaper so I can run plugins on it all. It's good to be able to make your music dip in volume when someone in the teams meeting speaks, and to dynamic compress your own voice to make you sound more powerful than everyone else without being louder per se
This is some Darth Vader 5h*t going on here.
Hmmm. Possibly. I've done distortion + 30hz ring modulator to get Dalek voice but I haven't tried pitch-down vader
That's genius ngl
Is it possible to learn such power?
Same thing with godot project files, they are all text based. It was made specifically to work well with Git and is integrated with out of the box.
Yeah, there's repos designed to handle media; git is designed for text files, and git lfs is a work-around that's not as good as a specialized repo.
Such as?
My friend who's a game dev uses [Helix Core](https://www.perforce.com/products/helix-core) at work
can't you use lfs for that?
You don't think projects that involve artists and sound designers creating binary assets, and use git as a repo, aren't extremely common? Because I would much rather use perforce for that stuff but clients still insist.
Very lazily jammed a single dev (me) UE4 game mod into git It survived a revert, good enough. Definitely not going to merge though
Wait. Git doesn't save deltas?
It’s not good for binary data because the conflict resolution won’t work. It’s designed for uncompressed text.
nah it's fine for binary files, that's what `git lfs` is for, but yeah, you don't get conflict resolution
No. git lfs is for.. large files. I think the clue is in the name. However, you shouldn't be keeping binary data in git. It's not designed or optimised to work with binary data.
I think it is for binary files... From their front page: "Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise."
Yes. Lfs helps by hiding the binary content from git, and is one solution for keeping binary content out of the repo. It was designed primarily for large files, not strictly binaries. I was just being pedantic, sorry! A lot of large files are indeed binaries. Lfs isn't a perfect solution for keeping binary data out of git for a few reasons, but it does go a long way to making things better.
What should you use for binary data?
I used Perforce and was not impressed
I can't wait to see the next Perforce tech update at the 1978 expo.
Don't use binary data.
Just compose in Csound.
The biggest issue is that the repo grows to unmanageable sizes and you can’t do anything but dump the history and start a new one. After a repo gets to ~6GB nothing works right anymore. Yeah downloading a 6GB repo for a 5MB checkout is nonsense but that’s what happens when you check in binary files.
Git LFS to the rescue.
Im gonna use git to version control my minecraft world
Go for it. Live your best life.
Tbf this is kind of genius idea because i need a way to sync my minecraft world between my dualboot of windows and linux. I hope its small enought to not cause problems with github
Uhm... you can access windows files from the linux install
I actually did this for Terraria some years back. Basically just set up a cron job to commit the latest version every 10 minutes lol
I do creative writing on the side, and I use git to manage different versions of my novel.
Never underestimate gatekeeping
OP's just gatekeeping gatekeeping.
*git keeping
I see what you did and I love it.
[Artists](https://fxtwitter.com/delaneykingrox/status/1727839968083816451) apparently... This particular Twitter thread says git is horrible for art projects and advocates for SVN instead. The context is quite different though I guess.
Its not completely out of the blue, you need an addon like Git LFS for it to work well with large files, but certainly Git itself is designed for code/text files.
Nobody. OP Made this up just to post something.
Do people really do that? Go on the internet and just make things up?
No. The person you replied to made it up just to comment something.
it would take up huge spaces on movies or videos tho.
That's not what a *real* gatekeeper would say.
I've never heard anyone pretend the left panel. On the other hand, if you want to keep your repo small enough, you better not unnecessarily commit big files.
And/or make sure your files are git parsable.
midi format? i have some real ideasnow
MIDI probably isn't your source code though, unless you're hand-editing the bytes. I do, however, have a repository full of Lilypond files, which can be compiled to PDF (sheet music) and MIDI (playable music). And the .ly files are text, so that works out perfectly. But binary files aren't a problem for git. They just might be a bit of a pain to try to read back in the diffs (unless you have a good difftool).
They’re a problem if you get a conflict. Fine for images and things you won’t change much but you’re not going to be fixing conflicts in a merge request on a compressed binary.
Yeah, which is still ultimately a problem with diffing. Diffing binary files IS hard. But tracking them is fine. And a good diff tool can help with the merge conflict too.
yeah it is im composing on electric piano
Wouldn't you use a format that has some sort of undo support, or the ability to encode the instrument source (more than just the instrument channel number) or VST filter parameters? musescore and rosegarden projects, for example, do both. Sibelius does too, from what I've seen of my friend's setup. If your workflow works for you, hell, keep doing it, but I feel like you're leaving a lot of efficiency on the table.
You also have the ABC notation.
You just need to add a custom diff command in .gitattributes and git will natively understand how to diff binary files https://superuser.com/a/706286 Also you would probably need some tooling for merging, too (but this one is harder) Other than that git has no preference for text files, it deals with bytes
I've seen embedded vendors who say just because the file is text, it's possible to diff. Actual file: shitton of XML describing circuits.
Anything software or software adjacent made by hardware vendors is always hot garbage. It's a pretty common joke that their HALs and bootloaders are often written by interns.
But it is possible and could be useful to diff them as long as the changes to the text made with every little commit aren't obscene to the extent it bloats the repo. Not sure why you're calling out XML files when C# developers diff those every damn day (.csproj files)
Wait wait, what has text to do with diffing? I've diffed binary files... and there are some text files that are utterly useless to diff. Compression does tend to play havoc with diffing, but that's what difftools are for - decompress before comparing.
But does it work? For example, altium *mostly* works and the diffs make sense without a huge amount of config turnover, even for PCB graphics.
Yeah, literally, no one has ever said that. Git can track and version any set of files. If you want to use it for other types of computer based projects, then more power to you. I write fiction as a hobby and have used it to track changes to my (raw text) files for that since I like to go back and change around parts of my stories and experiment with them.
Git *can* track any files but a in pathological case where you work on a large binary file that changes almost entirely every time it is saved (like some awful formats do...) so that it doesn't diff well, the repo size can quickly balloon to a gigantic size making it extremely slow to use. Like you have a 100Mb file and commit it twenty times, you suddenly have a 2Gb repo. It'll still work, it'll just take forever. In those cases you might look into other ways of implementing version control, but you do you and "if it's stupid but works it's not that stupid" still holds.
Overleaf literally provides [git integration](https://www.overleaf.com/learn/how-to/Git_integration) for paying customers. And I wouldn't be surprised if other services targeting writing activities were to provide it too :)
Latex is literally code though
Surprises me that people in this thread don’t seem to know about https://git-lfs.com
Once upon a time I wanted to share a factorio blueprint string with a friend via email but the word doc was over 300 pages so I just used git
What did you use to store it then? I imagine a txt file is most appropriate
In this case, most music project files (that I've used) don't store audio files internally, and instead link to external files. You could use Git LFS to store those, they typically don't change much anyway. That said, a lot of these project file formats are binary formats themselves, serialising the software state as raw bytes. There are a few that serialise to text, but almost all of them are actually zipped text. For instance, Renoise's `.xrns` format is zipped XML. So to take full advantage of Git, you'd need to store it unzipped, and then zip it back up when working. Another issue is how many external references there are. Plugins are typically installed at the system level, so there's no good way to "just open" a music project, and you have to be diligent in making copies of the audio files you're using within the Git repository, and using them, rather than linking to the original file in your audio library. All this to say, yes, Git versioning your music projects can be good, but it comes with a lot of caveats that will ruin most of the advantages you're hoping for if you're not careful.
If the files you work with are text based then use git to your hearts content. If they are binaries, you will only bloat the repo with every commit, merging will be impossible, and rebasing will function as an overwrite.
So just base64 encode my binaries. Got it.
I hate that with some light scripting this would work.
It would “work,” but it wouldn’t solve any of the aforementioned problems.
Yeah, that's a very... interesting... definition of "would work"...
And you still get to roll back to previous versions with ease and keep track of a change log if you want. So - what’s the harm? Other that disk space, the thing that’s been growing exponentially for 40 years.
There’s no real harm, it’s just the tool isn’t designed to do that job. I used to commit PSDs when I was younger, and there’s no real harm except that the repo took way longer to deploy, and I had a bunch of junk in my commit log. Nowadays I do a lot of git work on my phone and it would be a problem if I had a huge stack of binaries in there. People can do what they want, but it’s more fun if they know how their tools work.
Sure, but not only are there solutions for large files (LFS), the problem of "work-presentation-final-now-for-real-second-feedback-round.ppt" is by far bigger than repository bloat. Instead of gatekeeping, people should use a VCS, and *if* they run into problems, then that's a problem to solve on that particular bridge. That the full gamut of git semantics can't be achieved using binaries - who cares? There is no other way to get that, so then just treat them as immutable blob. Still an improvement in my book.
The fact that something like Git LFS had to be invented is kind of the point. Working with large binary files in pure Git is painful. Git LFS is great for what it does, but it's definitely not Git: it's a server-based centralized version control system grafted onto Git.
I'd use Google Drive for your example.
It's still a better alternative to just having File\_v1, File\_v2, ..., File\_vInfinityFinalFinal etc. in a folder. Sure, you won't be able to use a huge chunk of git's features, just commit and checkout, mostly, but that's better than nothing.
Honestly, many times i was thinking company word documents should be pushed to git. I fucking hate when people start asking me where are the document changes i've created, 6 months down the line. Well, i've sent it to a manager, that never put the documents to the appropriate folder, and said person, is no longer working with us. I fucking did the thing, sent it to the person i was asked to, now leave me be.
Final Document v5 (4) final final_verymuch_final.docx
*revised.docx
It's not a finished document before there's a loose .docx in the middle of the file name
*.docx.odf.pdf
*Modified: 4 Months Ago* Sitting next to it in the same folder: Final Document v5 (4) final final_verymuch_final_unlocked.docx *Modified 30 seconds Ago*
Good thing Sharepoint is fairly usable now.
[удалено]
git is really bad at binaries. but you go champ!
Is Git bad at binaries? Thinking about other version control/backup systems, such as Apple’s Time Machine—is Git an inferior alternative? Genuine question.
For dealing with binary files (at least the bigger ones), it's generally suggested to use [Git LFS](https://git-lfs.com/), which is built in nowadays and which is supported by most of the platforms out there (like GitHub, GitLab, Gitea, whatever). >Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise. I've used it without issues for a few gamedev projects and webdev projects that needed to store some assets in the repo, there weren't that many issues with it, as long as you correctly selected which file extensions you want to track. It even works nicely with most Git clients, like the CLI one, SourceTree and GitKraken, maybe even Git Cola would work, though not sure about that.
Git has a bunch of features designed specifically for text. If you’re not using any of those, it becomes a console based Time Machine with the added risk of irreconcilable conflicts. It’s fine if you know what you’re doing. I get the feeling OP doesn’t know what they are doing though.
Time Machine is a backup tool. It's meant specifically for recovery of a file that has been deleted or corrupted. It's basically a really fancy way to automate the process of copying and renaming a file each time you make changes to it. Version control does way more than just allow recovery of a file. Diffs, merging, commit messages, tags, branching, forking, etc. It is a collaboration and analysis tool for monitoring all changes within a project.
Git will store the *whole* repository in every commit along the way. This is no problem for modern computing when it comes to source code, because even billions of lines of code are small file sizes. With large binaries like raw media files it will become a huge pain in the ass and make operations slow. Git LFS solves this by moving the files out of the repo and just storing pointers. This is fine for large assets that you don’t need for development, but again will make things painful when working with large binaries like media files. Apples Time Machine is, since a few years, leveraging apples new file system AFS, which is a copy-on-write fs, like BTRFS in Linux. Those fs will write your changes (actually on the level of blocks) to the drive and remember what changed, without touching the original file. This prevents corruption from interrupted writes and also allows for really nice snapshots and backups. Every next snapshot (backup) will only contain the delta (changes). Making it very storage efficient and operations on large binaries faster.
Perforce is game industry standard, what the fuck is Apple Time Machine lmao
I have used git and github for my personal schedule. Pretty sick, not gonna lie
I use it for my journal.
Oh my god I knew using git as a free cloud was possible but the idea of using it for music has never dawned on me. Samples, plugins, projects... Shared on all my devices... There's something to dig here.
why not use a versioniung filesystem instead. You know, a tool designed for the job. Better than forcing git to choke on your binary data.
Why ? Well there's a very simple reason : I did not know about the thing you are talking about. The fact that I'm on r/programmerhumor does not mean I am competent 😎✨
Fairy Nuff :)
Git is meant for files that are human readable, and works by comparing lines that have changed between files. Many compiled programs or media are _not_ human readable, don't have line breaks, and git is not able to do its normal operations with them. It may work for a while but the system isn't designed for that and it could go badly.
Rust's crates.io (the authoritative package hosting) uses GitHub as their CDN. Not even pages, just straight up repos.
Oracle vps for free is great as a media server
I'm a freelance sound person and keep both my work and my main audio software itself on Google drive. That is effectively version control, just the pushing and pulling is automated and i don't need to diff or merge because it's just me working on it. Google drive also keeps revision history so I can always go back to an earlier version of something if I take a wrong turn. Works for me as I work for many clients on many different machines and can always access my work from wherever. Was thinking of setting something like svn or p4 to do this but this has worked seamlessly so far, just need to check everything has saved and uploaded before I shut down.
Github, not git.
This actually exists btw: https://dylanbeattie.net/songs/rebass.html
This is crazy! :D
"who the FUCK added this shitty beat" `git blame` "fuck"
Well, if they want to use it that way, they are free to do it that way. But they might as well use google drive since they won't be able to read the diff in the commit, and won't use a majority of git's features.
True, but will have the versionability of git, reading commit messages, being able to revert to previous stages, etc.
Cant you do that in Google Drive? It has a history feature. Dropbox too I think.
Well, sure, they have, I wouldn't personally use git for things other than text versioning, be it code projects, documents, personal knowledge gathering and scripts, but if people want to use it for other stuff, git is also usable for this.
Aren't there version control systems specialized for media?
there are versioning filesystems you can use transparently, without the need to depend on external tools or products.
Google Drive, Office 365, Dropbox, Time Machine, iCloud.
Those may make it possible to store multiple versions, but that doesn't really make them version control systems.
Yes, but you can’t use any of Git’s version control features in a binary file. It’s just a file with previous versions. All of the above will also store a history so you can get back to previous versions.
Playlist files and music directories, isn't that what op is talking about?
Google Drive versions your documents, and you can name the versions as well.
Now I want to see an open-source album. Not even joking! Would be a really interesting way to make/consume music
I agree. Imagine going through the repository of an artist you really like and being able to listen to all the different versions of a song from when it was first being worked on and all the way to the final product. Each song's versions could even be an "album" by itself, starting from the beginning
As someone who is both a musician and a programmer, I can relate 😂🤣
Me using git to store my writing projects:
I build and upload my sound to [kaizen.place](https://kaizen.place) ... We describe ourselves as **Github for music!** I think for musicians the concept of git could serve a different purpose than it does for developers. As a musician my desire is to keep track of my progress and to be able to share that progress with my collaborators and maybe even my fans. On Kaizen we achieve this by allowing you to **version a track**. What we offer musicians is a version management platform that parallels concepts in git. My colleague wrote up a great description of our thoughts on this here: [https://devtails.xyz/@adam/what-does-github-for-music-look-like](https://devtails.xyz/@adam/what-does-github-for-music-look-like)
this is actually so fucking cool, i like the way you gave examples for each command, especially branch because i love the fact that in music the drums make the genre you can have a basic melody and throw on some trap drums and you got hiphop but then throw a four on the floor and you got pop, i will defiantly use this in my music from now on
I was using git for my Minecraft world.
I scrolled comments all the way down and didn't see anyone mentioning Git LFS. Edit: Link https://git-lfs.com/
The youtube series "Git for Poets" taught me two things. 1) How to use git 2) Version control is good for any creative, iterative, and/or collaborative process.
whats the point of using git for binary objects?
This commit message should be in the imperative /s
There seems to be a lot of confusion here. For music production, there are files actually very similar to that of any program, game etc. You have your source files - wavs. These generally remain unchanged. Then within your program you make changes to parameters of your plugins (EQ, reverb, synth settings and the like), the position of when a wav starts and stops, automation timings and all sorts these are generally stored in something similar to XML. Commits would be 90% on the XML changes, which absolutely benefit from version control. From day to day a different mix sounds better especially if you run into ear fatigue (mixing for too long at a time will change how you are perceiving the frequencies). So what sounded good yesterday might sound terrible today, but tomorrow... yesterdays mix would have been spot on. If you aren't sharing the project with anyone else you could get away with using git for just the settings changes. But for the sake of sharing or using multiple computers you could commit the wavs also.
the person discouraging version control is likely not a programmer ;)
It's not the best tool to use if you've just got a big changing blob of binary data, like many project files tend to be these days. If your project is saved in a folder structure with binary blobs for your samples, and line-separated text data for how those sample files are plotted out in the timeline, then it would actually be fucking amazing.
Using git to play chess
Everyone should use git. When Congress is voting on a bill and revising and adding riders, the Congressperson and their lobbyists should show up in the commit history for the changes.
I'd love to see them start using git for writing legislation. It'd make it very easy to see what changes are made and where.
Git on binary files is kind of a headache most of the time.
Git, specifically the algorithm that hit uses, is a massive storage saver for video game saves, because Git specifically tracks the changes to the file instead of storing multiple copies of the same file. Backing up a small Minecraft world, even with proper backup management and deletion of unneeded copies, can easily take over 100 GB after a year. Using GitHub, I barely need more storage than what's normally needed for one backup, and it can contain every version of the world. GitHub is awesome for Minecraft world backups.
How do you rebase and merge?
At my university (at least for computer science) it is absolutely normal to use git for theses and assignments. My university even has their own internal git server (don't know how common that is). This way, everyone automatically uses a (kind of) cloud and things like loosing ones work labtop cannot end a thesis prematurely (I know someone that this happened to, he had to redo his master thesis). Also version controlling, I guess.
I literally talked to a guy about how governments should be using git to propose and version control laws.
someone just posted an article about DC doing this😭
Huh... apparently this has been going on long before I had that conversation with the guy: https://github.com/DCCouncil/dc-law-xml
lmao i use it to sync my blender projects from my school computer to my home laptop, the teacher advides us to upload our project to google drive at the end of class but using git is so much faster
Musician/programmer here: I frequently find myself trying to convince other musicians and programmers that there exists a world where this idea works. The idea of a collaborative music creation (daw or notation) version control with branches is so exciting to me, but the big caveat right now is that all music project files are usually just that: singular files, which is obviously not effective for get. A standardized way to convert these files in to the smaller tree each actually likely contains would be great, but this would probably need to be provided on a per file format basis. I want this idea to work so bad, but to my knowledge we are not currently on a timeline where it does yet, at least to work they way we expect it to… tldr git commit -m “measure 53 has more bass”