1: What does it matter? I do $packagemanager install git and am done. What do I care whether it's got dependencies or consists of several binaries?
2: Fair enough. Although a multi-file backup doesn't sound hard to me either.
3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits?
4: Sounds like a nice feature.
5: This just uses the term "tag" to mean something else that git tags. But I agree that it would be nice to be able to label several commits (distinct from tags).
> What does it matter? I do $packagemanager install git and am done.
_Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post.
> I can't clean up my messy WIP commits?
Nope. Fossil remembers what happened, not what "should have" happened. We (on the fossil project) consider that a feature, and fossil's own history is littered with "oopsies" (no small percentage of them from yours truly).
I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset change to switch. And then there's this: what if I accidentally commit a private key or database? Sure, I shouldn't be f-ing up, but we all know it happens sometimes. In Git, I can revert/reset back to the commit prior.
> I amend commits in Git quite often before pushing.
Fossil supports amending checkins at any time after committing, as often as you like - change the checkin commit, re-attribute to a different user, change the timestamp, or similar. What it doesn't support is _modifying_ them.
> And then there's this: what if I accidentally commit a private key or database?
Then you "shun" (to use fossil's term) that artifact. Fossil isn't 100% merciless when it comes to removing content, it just makes doing so a 4th-class sub-citizen of a feature and recommends against doing so in every case except for the one of content which should never have been checked in. Removing content inherently punches holes in the project history, so it's not something we (in the fossil project) recommend doing unless it's absolutely necessary for reasons of security or legality.
> Why do you mean "modify"? As in rewriting history (commits before HEAD)?
Fossil flat-out does not support, with the exception of "shunning" (forcibly removing content), the modification of any history. It supports the "amending" of any history, however.
For example, you can "change" the timestamp of a commit retroactively. It doesn't change the timestamp on the actual checkin (as that's cryptographically baked into the commit), but it changes how the checkin is displayed to the user in fossil's "timeline" view. Fossil also, however, makes it easy to see, in the details for that checkin, that the timestamp was modified later (and who did it, as well as when they did it).
Even in git, amending doesn’t rewrite the actual commit though. It creates a new one. You can find the old in your reflog. Think about it, the commit hash is based on the contents, so it must be changed on any content changes. It’s only after pushing that history is written in stone.
So you can say git never removes anything either.
The biggest issues with data loss in git is before you have done a commit. There, many actions can nuke your changes because you mixed up two flags, trying to rebase before commiting, etc. As long as you have a commit though, the reflog will save you from failed rebases.
> So if someone new on the team accidentally commits "node_modules"
Then the 120k+ files in node_modules is in there forever, far outliving that team member's career as a software developer.
If the user has not yet synced those changes to a central repository, they can still delete their copy, re-clone, and re-do their checkin to be "less encompassing." Once they push, however, all of their coworkers will hate them. The fact that pushing would take noticeably longer than it should for that case would be the first hint that tapping ctrl-c would be in order (that is, cancelling the sync with the upstream repo).
> ... it's there in the history forever?
Until/unless it's "shunned" (which would take extraordinarily long to do for 120k files, as shunning requires the artifact IDs of every file to be shunned, and if a single one of those hashes is the same as a file which should not be shunned (e.g. all empty files have the same hash) then tough luck).
It seems likely, however, that new developer's colleagues would have long since added `node_modules/*` to the repository's `ignore-glob` setting so that the new colleague wouldn't accidentally add that.
Sidebar: in my 14+ years of being active in the fossil community, nobody's yet posted saying they've accidentally checked in a node_modules directory and asked for advice on how to deal with it. Presumably node folks primarily exist in Enterprise environments, and Enterprise environments all use git because that's where the tooling is.
2: Fair enough. Although a multi-file backup doesn't sound hard to me either.
3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits?
4: Sounds like a nice feature.
5: This just uses the term "tag" to mean something else that git tags. But I agree that it would be nice to be able to label several commits (distinct from tags).