> I think it's fairer to say that we don't think a data repository is any place for lies of any sort, even white lies.

I, too, wish this extreme hyperbole would be just left out of the discussion completely. It is offputting, and I think it's intentionally a bad faith argument, it fails to acknowledge the utility, the design intent, and the context behind rebase, which has been talked about at length by Linus and others.

When rebase is used as designed, according to the golden rule, it's not modifying published history, so it's not "lying". Whether rebase has safety problems is a separate issue from whether it's use as designed amounts to being "dishonest".

I'm all in favor of improved design choices, and if Fossil is making those better design choices, let them stand on their own without intentionally denigrating git and every user of git through utter exaggeration.

My understanding is that shunning is blacklisting specific artifacts. That's nice, but I don't understand how that solves the problem.

When I revise history in Git, even if it's just doing something as simple as removing sensitive information, I often need to replace that information, either through new commits, or by introducing minor edits to surrounding commits. I could add those changes on top of my current HEAD, but then checkouts of old versions would be broken. On the other hand, if I can just replay my commits while inserting extra code, I'll end up with something that's pretty close to my original history, with just the offending information excluded/replaced.

That carries the cost that people will need to force pull my repo, but at least the repo history will still roughly correspond to what development looked like, rather than being out-of-order and mostly impossible to build except for at my current HEAD.

As a followup question, what do you do if the sensitive information you need to exclude is in a commit message? `amend` won't help you, since it's not destroying information. Do you shun that commit and then... what?

It just seems like destroying information isn't enough unless you can also replace it?

> Sure, flexible tools are often better than inflexible ones, but you also have to consider the cost of the flexibility.

I appreciate this -- I like having multiple tools for different purposes. I don't see a problem with having a VC that focuses on auditability, or having one that goes in a radically different direction from Git. Fossil has very interesting ideas, which is why I try to pay it some attention whenever I see it mentioned or linked to.

However, whenever I follow those links and start digging deeper into the philosophy behind its design decisions, inevitably the conversation changes from, "here's our alternative approach to Git" to "what Git does is fundamentally wrong". It's not, "Fossil doesn't have this problem because we eschew rebasing", it's "why would anyone rebase?"

(Nearly) all architectural decisions have good and bad consequences. Sometimes those consequences are imbalanced, so we have heuristics that can say things like, "often X is a bad idea." That's fine.

More harmfully, sometimes people extend heuristics into rules that say, "it's never a good idea to do X". Programming rules are usually wrong.

But programming ideologies the worst, because they say, "there is something mentally or morally wrong with a person who would do X". This is toxic for the reasons that Fossil devs already mention in their documentation:

> programmers should avoid linking their code with their sense of self

Programming ideologies explicitly encourage developers to have egos, because ideology conflates architectural decisions and workflow processes with individual worth. Programming ideologies make it harder for people to grow as programmers, because they tie intellectual growth to fears about being wrong. They're completely toxic.

And is Fossil's documentation promoting an ideology? I'm guessing that you'd disagree with me on this, but my take is that when Fossil's official documentation says things like:

> Honorable writers adjust their narrative to fit history. Rebase adjusts history to fit the narrative.

or

> It is dishonest. It deliberately omits historical information. It causes problems for collaboration. And it has no offsetting benefits.

That's not designing a focused tool to support specific heuristics, or making a case that, "sometimes strict auditability is important". That's just trolling for fights.

> ideology conflates architectural decisions and workflow processes with individual worth

No. You start with the ideology based on your local culture and project needs, then you pick the tool that supports your project's needs.

This is why we spend so much time talking about philosophy in the Fossil vs. Git article, particularly this section: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

Which of the two philosophies matches better with the way your project works? That alone is a pretty good guide to whether you want Fossil or Git. (Or something else!)

I generally try very hard not to argue about definitions, and it seems like you're using the word "ideology" differently than me. To get past that, substitute out my word "ideology" for "foobar".

A foobar is an assertion that there is a single right or wrong way to look at the world. Not even just a single correct or incorrect way, but a right way -- a proper way. If the problem with a rule is that it overgeneralizes what the world is, the problem with a foobar is that it generalizes what the world ought to be. To the extent that a foobar allows space for deviation or alternate approaches to architecture, it's only with the implicit understanding that those deviations are on some level, a kind of small sin.

Not all foobars are necessarily wrong, but in the world of software, they are particularly dangerous, and should be approached with caution. Under a foobar, a rebase isn't an organization strategy, it's a "white lie". A writer isn't optimizing for a specific audience or purpose, they're "honerable". An agreed-upon set of rules for everyone accessing a repo can be "dishonest".

Different people have different standards for this kind of thing -- but is it really all that weird or abnormal to worry that this kind of language can encourage toxicity in a community, or that it could encourage developers to think of architectural outcomes as personal validations or attacks? To me, that language sounds very foobar, and it makes me nervous about what experience I'm going to have if I adopt Fossil and then start asking questions to the community about how to use it in unconventional ways.

To be clear, there are other pages in Fossil's documentation that are much, much better about this kind of thing (particularly the Fossil vs Git page).

But even on those pages, the thing is: I use Git constantly. I am intimately familiar with its strengths and flaws. I really don't need the documentation to tell me that Git's storage is an "ad-hock pile-of-files", because I've worked with those files before and built 3rd-party tools to manipulate them, and while there are flaws, sometimes being able to do a completely dependency-free read on any OS/platform to find the current HEAD is quite useful.

When I read the docs, I just want to know what makes your software different. You're not going to convince me that actually all of my experiences were wrong, and everything I like about Git is secretly terrible. You might be able to convince me that there are specific problems Git isn't optimized for, and that Fossil can solve them.

When Fossil is talking about Bazaar and Cathedral development, I'm really interested in learning more. When Fossil is taking cheap shots at purposeful design decisions in Git that are actually really good for certain classes of problems, I lose confidence that the docs know what they're talking about.

For what it’s worth, I could not agree more, and I wish I could upvote this twice.

If I were to attempt to help with the terminology, instead of sorting out the definition of ideology, I might say you’re talking about dogma and wyoung2 was referring to philosophy most directly above, but indirectly using philosophy to justify dogma.

There’s a fairly stark irony here in using words like ‘lie’ and ‘dishonest’ to judge this git workflow while at the same time taking cheap shots... but in the end I suppose the Fossil devs can describe things any way they want, and I don’t have to like it or use Fossil.