@rysiek "we've always done it this way"
"our company is different"
"we don't really see how the marginal benefits of using x could possibly outweigh the downsides of implementing such a complex system, and training all our staff to use it"
"well, we do have it in place for a few years now, but nobody is really using it, except for the department that (installed it | requested it)"
@hirojin yeah, seen them all. In my team I just unilaterally said "we're using git for everything" and that's that. I can help people train, I can set up CI/CD pipelines for them and whatnot, we can talk about the workflows and how to use git in a way that fits our needs, but using git is non-negotiable.
@hirojin and for the record, I loathe git. I think it's overcomplicated, and needs a decent CLI.
But it's what the industry standard is, so I'll use that.
I think people think it's complicated. I tend to git all of the things because it's simpler to initialize git in a directory than to decide what .bak type extension to clutter it with.
I use numbers (a la (Open)VMS) and sym.links at the early stages, when the files are still independent.
• file.ext.0, file.ext.1, …
• file.ext -> file.ext.7
Why not VCS from the very beginning? — I don't want to come up with commit messages for things I may forget about tomorrow, and rebase the repo, if it's going to be published, just to modify the said silly commit messages.
Nothing really ingenious:
Make lots of small commits, squash & permute them before pushing, if that explains the changes better.
Use scripts to perform a massive changes, quote the scripts in commit message or add them to the commit as files, then remove them on the next.
Yep, it's the same thing as with time and budget management — everybody does it, one way or another, but only few utilize the sophisticated specialized tools and don't suffer from it…
WRT, that my scheme: it was inspired by Common Lisp's filesystem access facilities and all the features of e.g. FILES-11 it captured.
@rysiek because people sometimes have bad experiences.
SVN: middle management settled on a giant single repo used like an FTP directory. No one knows where the code that's used in production is or if they have access to the right folders, and no one tags anything.
GIT: I didn't use exactly the right incantation, so now I have to delete everything and re-clone. Why won't my branch merge and how do I resolve this conflict? WHO USED CHERRYPICK?!
STOP BULLYING ME!!!
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!