You must log in or register to comment.
I knew a dude who would burn a cd every week and store it in his house as his version control, his software is still used by hundreds of businesses to this day
That last one is more common than I’d like, a lot more
$ cp -r src/ src.old
No sir never seen it in me life, honest to god sir
Oh I used to do it as a kid
cp index.php index.php-20250220the last one is just immutability, praised in modern JS / TS, albeit at the repo level
I “love” how JavaScript has slowly rediscovered every piece of functional programming wisdom that was developed before 1980.
Kind of, though they honestly just do pretend immutability. Object references are still copied everywhere.
All of javascript is kinda just pretend.
I find you need the whole ecosystem to support immutability to make it work. Every library needs to be based around it. Elixir is about the only modern option that does.
cp $fic $fic.$(date -Iseconds) git commit -a -m "save at $(date -Iseconds)" # edit $fic git commit -a -m "save at $(date -Iseconds)" git push -fcp?💀
cp is short for create packup
And worse than all of those options is Visual Sourcesafe.
Fox Pro!
Shrug
The last is just a normal git workflow, isn’t it?
I’m pretty sure it means, they copy and paste the project file and iterate the version number manually.
As one of the maintainers of Mercurial, I take great offense in this meme. ;)
It’s definitely up with Git in my opinion. I much prefer the branching in Mercurial.
It’s certainly very offensive to lump it in the same band as SVN and TFVC.
What could possibly be preferrable to
git switch -c <branchname>?It’s not the mechanism of branching that I prefer.
It’s the fact that Mercurial tags the commit with the name of the branch that it was committed to which makes it much easier to determine whether a commit is included in your current branch or not.
Also, Mercurial has a powerful revision search feature built in which I love (https://www.mercurial-scm.org/doc/hg.1.html#revisions).
It’s the fact that Mercurial tags the commit with the name of the branch that it was committed to which makes it much easier to determine whether a commit is included in your current branch or not.
Isn’t this trivial in Git too?
git branch --contains COMMIT?Sure, if you want to do it once, but Git still has to compute that information (save for a new-ish cache that is just that, a cache). But that is not the point really, the point is that Mercurial’s graph Is the same (topologically) everywhere, which is not the case in Git because branches (and thus remotes) have different names. So saying that a branch contains a commit is not the same as a commit being on a branch. There are a bunch of great properties that emerge from this but it’s too long for this comment and I should actually properly write this down at some point this year.
I admit that I have been bitten by the fact that commits don’t have a “true home branch”.
Given that Git and Mercurial were both created around April 2005 to serve the same purpose by very similar people for the same reason… I’d say it’s fair!
The last one can easily describe Django. Feels like depending on the code base/your mistakes/people you work with can easily turn a normal project into a project where majority of the files is just migration files.
I miss mercurial and it’s far more sensical flags and commands…
Me too. It also handled some situations, like divergent lines in the same branch or obsolete changes, much better.
It’s still here and very much alive in case you were curious.
The only reason that we stopped using Mercurial is that Microsoft used Git in Azure DevOps. I still wish that they’d supported Mercurial instead of or as well as Git.
I really liked Mercurial too. It was much easier to follow branches to find out if a branch included a commit.
Git is so ready to understand, that I don’t understand how people work without it.
It’s one of those things that’s hard to really understand why it’s so useful, until you actually use it.
Why did you mention git twice?
While TFS did support Git, I had to deal with the much worse TFVC for a long while, up until Azure DevOps came along.
btrfs sub snap -rWith properly configured subvolumes, I’ll allow it.
Isn’t that just git with more steps and harder to share?
It’s equivalent to
cp -r, but:- the copy is read-only
- reuses unchanged files
- easier to share (
btrfs sub send)
Sounds just like git (unless you do some special operations to change the copies)
Couldn’t add perforce to the list because someone else was checking it out, I see.
It’s actually a pretty good idea to have a full system snapshot time to time, where the project can compile successfully, for future Virtual Machine use. It’s usually easier to spin a VM than setting up the whole dev environment from scratch.
