Dizzy the Void

I feel like a better backup.zip is so designable it’s any of the collaboration benefits that are so much harder to design. But like 95% of people who would benefit from version control doesn’t need them so,

Someone should make an easy-to-follow, yet powerful git workflow tutorial for introducing to kaizo players and maintainers to git. It could be named "git gud"

if I were trying this, I think I'd make the thing a dead-simple graphical interface over Git or Mercurial that just does a few things:

• Autocommits every X minutes
• Backs up to a server every X hours
• Has a big button that says "save state" and lets you give an explicit name/description
• Exports to a zip file with history
• Merges two zip files with history
• Links to a more complicated GUI client for if/when you need more power

Even though I assume it has gone to shit nowadays, Dropbox is the only tool that has for the most part, a reasonable normal person workflow. Put things in the magic folder.

interesting, never knew this is the state of things in the mario romhack community. over here in rayman land pretty much everyone uses git, but i suppose it’s due to how niche it is, and most of us were programmers before getting into the hacking/modding community

Stop Doing Math meme but about git:

• "imagine a DAG of content-addressable storage" - They have played us for absolute fools

ime the problem is less that it's innately got a steep learning curve than that Git has basically the same PR team as NFTs, and learning how to actually use it effectively means volunteering to spend countless hours reading those guys' opinions about what additional applications you need to install and scripts you need to run to commit updates until you understand which ones are full of shit

i think you're asking for how to make the power of git available without anyone having to think about it, but half the power of git is that it's made out of meaningful checkpoints decided by humans, which is necessarily something you have to think about

if you take all the human intervention out of git then what you have left is just backup.zip

i think this might be a programmer trap. source control is hard precisely because it's secretly a social problem — it's people figuring out how to work together (even if "people" is sometimes just different versions of yourself across time). git is a toolbox for building a solution to that problem. backup.zip is also a toolbox for building a solution to that problem, and if they've done that then maybe that's fine

Yeah, it feels like git is way overkill for this use case. You could probably craft a “backup.zip v2” proof of concept by wrapping some git commands and set up a file watch that commits changes automatically. I guess the interface could let the user create a tag, list tags and revert to a tag (the nice thing about reverting is that it’s non-destructive), with some magic to let you sync to a remote git repo.

I got nostalgic last year, wanting to get back to SMW hacking which I stopped doing 15 years ago.

I was thinking that I might make use of my Git knowledge that I got since then, but the problem is that the main non-divisible resources are still binary patch files consisting of the changes you performed in the level editor (LunarMagic). You can still store and diff ASM files for custom enemies, blocks, etc. but that's just a fraction of what most people put their effort into.

It's not really possible to figure out what the differences are between 2 branches without applying the patches. It should be possible to automate creating the patch and applying it to a non-version-controlled ROM during a regular workflow at least. I guess a higher-level format could be created that contained readable diffs like "moved block of id A to (10, 12)" or "added block of type B to (20, 4)" that could then by assembled.

Working around the restricting that no traces of the original ROM can be comitted to source control really puts a damper on things. EDIT: I guess if you don't expose the repo publically then this part doesn't really matter.

I feel like a big problem with git is its user interface, and its specifically being geared to "_pro_grammers" who work in obtuse utilities like gcc, weird editors like emacs or vim and unintuitive, inflexible languages like make.

trying to convince an '816 assembly code hacker or lunarmagic level designer to "use git properly" is like attempting to convince the chef at a "good but not expensive" new jersey dive diner about how your microwave pizza factory assembles food and how much more profitable it is.

the git methodology, merge conflict resolution behavior, the whole user interface, is wrong to expect of people outside of "I run arch btw" nerds imo.

but the technology of git, is close to the perfect thing for this. it needs a better frontend.