mscrnt

10000000

Mind boggling

Hard disagree. The information system and its popup was vital information that the attending failed to act on. This anecdote serves as an example of user error and incompetence. And I’m a huge hater of popups.

cut a PR to improve it; that would be nice

PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created).

It's amusing if not ironic how many comments are something to the effect of "...but how messy and clumsy would the Fossil approach be when working with the Linux kernel that has 1000s of contributors pushing 1000s of commits..." when the sum total of projects approximating the size of the Linux kernel can be counted on one hand, and the authors of such comments are almost certainly not working on such projects.

Not to mention the author of Fossil has clearly stated that Git is great for Linux kernel development, and Fossil was not developed for such a project.

So you want to appeal to authority?

That looks to be someone presenting their opinion—not a statement of fact. Ironically, too, considering the guidelines they link guides users to not do what they're doing.

Can you see, though, how using rebase to "clean" the historical record—irrespective of your intentions—is in fact deceiving the reader by presenting a narrative that is in fact different to the actual events that took place? If so, please provide a better way to convey this message than how it is currently being stated. If you can't see the deception—motive notwithstanding—then we're at an impasse.

What negative language? You seem to be attributing your own negative connotations to a word that is being used descriptively—not disparagingly. And the shun page explains that you should not be removing content willy nilly but only as a last resort to, for example, remove sensitive information from the blockchain. The Fossil authors are perpetually behoving users not to use shun unless it's absolutely necessary, but provide the feature as a necessity in case someone foolishly commits sensitive information that could land them in legal trouble. Would it make you feel better if there was a note on the page that said "NOTE: By using this command you will be lying about the history of the repository and should document the removal explaining why the artifact was excised from history." Submit a patch. Improve it.

That's on you that you take it as a value judgment of your or anyone else's character. It's quite literally an accurate description of the rebase feature and the result of its use. And criticism of Git's design philosophy should not be misconstrued as a pretend crusade or personal attack. I presume the lead dev of Fossil and SQLite places a high price on auditability for not only personal philosophical reasons but professional necessity. So highlighting the foible to facilitate falsifying the historical record of a software development lifecycle is fair. But to get so vexed and try to persuade others that an emotional response to an accurate description of a software component is always going to be a tough sell. Instead, maybe try Fossil and see if it is in fact unsuitable to your workflow, then try a different persuasive approach on why Fossil is wrong. Because on this point—it isn't.

I don't know about scrub as it doesn't alter version history but user data such as passwords, IP addresses, etc.; but to shun an artifact definitely meets my criteria for falsifying history and thus lying. I neither suffer from cognitive dissonance nor feel the need to defend a piece of software's honour.

I understand if you're locked-in to using Git for work so don't have a choice in the matter. But given the almost frictionless path to trying Fossil for personal or open source projects, I don't understand the "everyone already uses git" stance. If everyone took that position with rcs or svn, everyone wouldn't already be using Git today. I appreciate the non-developer concerns, but directing laymen to one place, to one repository file, to one executable binary to use a piece of software and/or to contribute to a project, might also deliver better results; it's difficult to definitively say without trying. I can only confirm my own experience, but surmise it would be a similar better experience for most others too.

Does anyone use Fossil?

Daily, across a half dozen odd repos, and it greatly simplified my life since switching from Git. My primary wish is to have the forum compatible with email. And the next would be a partial commit option akin to 'git commit -p' although I think this is missed more than it was ever used. At first, I thought the chat was an odd addition but it's being used daily on all repos, and has really improved team cohesion and productivity. The ability to view documentation changes in the browser while still in the local checkout but not yet committed has also proved quite valuable. Having the repository contained in one file is handy, and frequenting one server for all dev related work is a huge bonus. It's unbelievably easy to setup, and the command line syntax and help is highly intuitive and simple, making transition a breeze and continued use a joy. It's a great piece of software for any team working on your typically-sized repo.

But have you tried Fossil to see if it does meet your way superior standard? Unless you're working on Linux kernel- or BSD-sized repositories, Fossil is arguably a better fit than Git. You don't need to customise anything out of the box—it's literally a single binary anywhere on your path and you have your version control, bug tracking, wiki, forum, chat, technotes, etc. in-house. Your team won't need to visit but one server—that really streamlines focusing on solving your actual problem.

In the event it's done before pushing, it's still lying, albeit to yourself—it is falsifying the record of what actually happened. The clearest way of conveying this is with the word "lying." Perhaps "falsifying" or even "manipulating" would also appropriately convey this fact. And conveying facts accurately is arguing in good faith. Not to mention it is not only ever done while contained to the local checkout, in which case it is not just lying to yourself. Being triggered over trivialities is one thing, but to be triggered over a factual representation of the feature that comports with Git's own notion is something else. Try not to let it keep you from trying something that may productively fit your workflow—it could make life simpler. And it appears that you're attaching the value judgement—no-one is accusing people of being malicious. Instead, we are truthfully reporting what has happened; when you rebase, you are presenting events not as they historically occurred—but how you would prefer it had occurred. Nonetheless, Fossil enables curating the presentation of that history however you, or I, or Thomas or Jane would like; while keeping a true and unfalsified historical record. It's the best of both worlds—you're not forced to recount your mess and mistakes every time you look at the log. But for auditing purposes, the real timeline is still intact.

You shun the secrets-leaking commit: https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

Not a replacement inasmuch as it's not a standalone chat client to be used by disparate users for various reasons. It's a chat client for developers of a given project to convene discussion about work going on in that repository at that point in time. So where Discord, for example, is for anyone to setup a server to discuss anything; Fossil chat is for devs working on projects that already use Fossil to convene discussions pertaining to that repository. You won't setup a Fossil instance just to use as a chat client—because it's not intended as a replacement or competitor for <list of chat platforms>—but if your project already uses Fossil, now you can keep your dev-related chat in-house.

You’d forsake an improvement for the sake of following the rest of the cattle? Have you used it, yet, to see if it sufficiently meets your way superior standard to break free from the herd?

Except none of that refutes the fact that changing history is lying irrespective of the motivation behind the change. You can rephrase it however your sensibilities like, it won’t change that fact.

And httpd and relayd.

That, and it's very easy to hide commits from the timeline too. You can get most if not all the benefits of rebase without losing history—that's a good thing.

You could always try "fossil amend" as a commit amendment tool for starters.

It's only for devs with commit bits—not random users. So not likely to be buried in feature requests and much more likely to be just a couple messages being passed back and forth between developers of the project. I feel it streamlines the process and improves cohesion a great deal; more of a long-sighted deal—but I'm only a random opinionated passer-by.