💾 Archived View for idiomdrottning.org › local-repo-copies captured on 2024-05-10 at 11:17:07. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
The Fossil vs Git wiki page writes:
While you can use Git in the Fossil style, Git’s default tie between working directory and repository means the standard method for working with a Git repo is to have one working directory only.
OMG, that sounds so bad! I didn’t know that many people used git that way. That sounds super fiddly. Having a couple of different local copies of the repo is usually not needed but it makes a lot of things way more straight-forward. And that goes especially when you’re new to git and don’t know every command. You can clone a fresh copy and use your normal file management and file melding tools.
The whole idea of a DVCS is to have many repos. That’s what the D is—“decentralized”.
Yeah, yeah, git gives you tools to not always have to have multiple copies; like if you just want to copy an older version of foobar.txt over the newer version and you don’t feel like making a separate repo to copy it over manually, you can just use git restore on that one file. For example. But those are all optional shortcuts, not meant to be a burden.
I’m not slagging Fossil at all! SQLite is amazing, and it wouldn’t exist without Fossil. I’m not slagging that page, either. It does a great job outlining where Fossil is a good fit and where git is a much better fit.
It’s just that if you don’t know that you can “clone” locally easily by just copying the folder, or get a fresh copy by recloning into another directory, you might be missing out, especially for new git users.