sorry, almost done gushing, just one moe thing:

@Janet

22/9/22

@Janet3/14/2023, 8:03 AM

@Janet

tef @tef3/14/2023, 7:27 AM

version control for regular people

i've been watching some of the kaizo mario community at work, and despite many of them hacking away at text files and building roms, it seems none of them use version control tooling. i don't blame them one bit.

saying "learn source control!" might as well be saying "it's like your backup zip, except all of the files are hidden, you have to learn a whole new tool to do anything, and you'll waste hours on google learning how to do something that used to be easy!"

sure enough, it would be easy to go "skill issue" and say the problem is with them refusing to use git, but i think it would be more interesting to say the problem is "tool issue" and ask ourselves "why can't we make a better backup.zip?"

if anything "it's like a zip file" might make it an easier sell than "imagine a DAG of content-addressable storage"

@Janet3/14/2023, 7:52 AM

i hated cvs (though barely used it) despised svn (but couldnt really use it), warmed up to git and am falling in love everyday with fossil

cvs: i guess it worked, but it was awfull

svn: well, it could have worked, albeit slow, but it wasnt a good fit for the job (the IDE of "visual objects" is not something i want to spend the rest of my days in)

git: now here we are talking, dezentralized version control, no network neccessary to have some history lessons

fossil: holy shit. my only pain point is that i havent quite gotten my head around merging because that happens so seldom when you work alone, but even that is rather painfree and works. best of all: basically a github equivalent on your fucking HDD, in just a single file, the fossil binary is also just a single file. and usage is very straightforward and easy to pick up. no stage, you add files to be tracked, when you change them, they are, lets say, "autostaged". when you want to commit, you just fossil commit -m "i did silly things here" and you are done. in case this commit forks (because upstream changed in the meantime and you forgot to fossil update) you can either let it fork (unnamed branch that will be merged asap) or do an intentional, named branch.

in short, i love fossil and think it's so easy to use that noone should be allowed to have an excuse not to use version control nowadays. (except for "aint nobody got time for that", that is valid as heck and i already grieve over your lost works, but, like, that's unversioned life, eh?)

#fossil-scm #fuck fossil fuels #version control #i'm swooning and want to talk about it!

@Janet3/14/2023, 8:03 AM

sorry, almost done gushing, just one moe thing:

it has very good git integration, import from git, export to git, fossil has you covered: https://www.fossil-scm.org/home/doc/trunk/www/quickstart.wiki

(glossing that page, i see it also covers import and export from/to mercurial and svn)

#Ok #ok im done now

You must log in to comment.

in reply to @tef's post:

cassie @porglezomp3/14/2023, 7:45 AM

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,

graham @graham3/14/2023, 7:50 AM

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"

Natalie @nex33/14/2023, 7:50 AM

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

cassie @porglezomp3/14/2023, 7:55 AM

This reminds me a lot of how Glitch’s version control works.

eevee @lexyeevee3/14/2023, 3:56 PM

"merges" is doing absolute mountains of work here

the dream is to make it all magic and forgettable but conflict resolution is a big fucking nasty gnarly problem

@Cycloneblaze3/14/2023, 10:52 PM

Honestly I often wonder at the fact that VC systems can resolve merge conflicts at all, so I would accept leaving that out. Just do what I expect which is, "pick one of these two zip files to keep"

ceo of eurogaming @ceo-of-eurogaming3/14/2023, 9:19 AM

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.

Girl George @SmogDiamonds3/14/2023, 2:16 PM

That's how I worked before I had to tame git in school. It worked pretty well !

spitfire @spitfire3/14/2023, 9:50 AM

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

noah @noahtheduke3/14/2023, 10:22 AM

Stop Doing Math meme but about git:

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

@secrets3/14/2023, 3:34 PM

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

eevee @lexyeevee3/14/2023, 3:55 PM

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

Chimerelda E. Error, layabout @chimerror3/14/2023, 4:41 PM

I agree with this. My basic way of selling git to people like my former students is that it's "save points" for files, which is most understandable when it's a solo project. This analogy begins falling apart in the multi-user case, where it's more like you are sharing save games with a friend and can usually combine your work except when you make different decisions...

tef @tef3/14/2023, 6:57 PM

i do think can we make something a bit better than a backup.zip and just as easy to use.

and sure, the collaborative part is the most useful part of git, but i don't agree that "all you have left is backup.zip"

you get a backup.zip that stores every version of your project. point in time restore is kinda magical, and it's one reason people use git on solo projects.

eevee @lexyeevee3/14/2023, 8:19 PM

point in time restore is kinda magical, but people remember history by events more than by time. if you have to go back much further than your undo buffer reaches — especially if it's a format that can't be instantly previewed — then it's an endless soup of "Change on 2023-02-27 19:43:27". i've seen this with google docs's change history where my feeling is generally... it's cool that this is here if i ever need it, but god help me i hope i never need it

and all this is assuming a solo project. conflict resolution just plain sucks

chreke @chreke3/14/2023, 8:16 PM

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.

Deffon @deffon3/14/2023, 9:37 PM

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.

sirocyl @sirocyl3/30/2023, 3:27 PM

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.

tef @tef3/30/2023, 3:39 PM

i feel the notion that git is geared to programmers is being kind

it's a bunch of tools programmers can use, sure, but it was in no way designed with user experience or developer experience in mind

in reply to @Janet's post:

@Janet3/14/2023, 8:06 AM

shit. i lied:

im not done, i will never be done gushing about how good fossil has been to me.

it's also just a sqlite database under the hood, lovely stuff