Here's Fossil 2.15 running on EC2: http://54.79.202.57/register - this link will allow you to create a new account.
Alternatively, the "chat" user (password "chat") can be used if you don't want to make an account. [It used to have the ability to create additional users (with admin privs), with the result that the fossil instance rapidly began spouting SQL errors and I had to reset it, twice. That was fun...]
The instance is completely ephemeral. If this comment is more than a week or so old, expect the above IP to be dead (I'll be cycling the VM).
And yes - note that it's going over HTTP, not HTTPS :P (that would have taken an extra, uhh, while)
--
If you're using 'chat': once you've opened the above link, go to "login", login, then locate the new "chat" tab. You can optionally go to Admin > Users and make yourself a new account (the "Add" link is a little hard to see, it's to the far left immediately under the tab bar; also be sure to select "Chatroom" from the far right in the permissions list).
Maybe: Go to the Setup/Access page and select the "Allow users to register themselves" checkbox, and add permission "C" to "Default privileges". Then press Apply. With that setup change, users will have a "Create New Account" button on the login page.
Newly registered users still don't have access to chat. I think if you add the "C" privilege to the generic "reader" user, that will solve the problem.
I don't understand why these tools always have so much styling, when they would look a lot better if they just never did it in the first place.
Drop-shadows, rounded corners, borders, colouring, fades. All extra work, all a pain to look at.
Is like watching Picasso paint a painting on a glass wall, the first half you're "wow this is great", and then you just want to start screaming "STOP! NO! IT WAS BETTER BEFORE!"
> Drop-shadows, rounded corners, borders, colouring, fades. All extra work, all a pain to look at.
i have it on exceedingly good authority (as the one who implemented it) that the look and feel was about 90% personal preference and 10% feedback from other project members during development. The "extra work" you mention is relative - with modern browser dev tools such things can (with a bit of CSS know-how) often be completely styled in a matter of minutes, then copy/pasted over into CSS. The much more time-consuming part was getting the messages to pop up from the bottom, but the difference in readability between that and top-down posts made that effort well worth it.
There's obviously no accounting for taste, but (A) you're the first person i've seen actually complain about the CSS styles and (B) any given fossil site can restyle be restyled to do its admins' personal tastes - they're not stuck with mine.
MORE INFORMATION: since comment threads lock after a period of time, I made a small google doc with further info that I'll be able to update in the future:
Yeah, enabling all the things™ for the chat account produced unsolicitedly predictable results. Users can now create their own accounts, and the 'chat' account I linked can only access the chat page.
This evening was a fun howtobasic in like 15 minutes
Realizes people can change the password woops <insert cartoon punching fight cloud here> argh
OK. Because Fossil is awesome you can disallow people from changing their own passwords, while also making it possible to create further accounts that can change their own passwords. Nice!
[EDIT: A few misconceptions here. No, you can't do the above; if a user couldn't change their password but could create new admin accounts, said new admin account could just change the initial user pw.]
I think the idea is so that core developers have a quick way to chat with one another over design ideas w/o needing to register or setup other infrastructure, then move the best over to the permanent forum record or wiki.
Then the core members don't need to have a dedicated channel somewhere else. If they did, then that would be another inbox to check; instead they can check the fossil chat when they are on the project site looking over commits or documentation.
So it is just another source of information on the main "fossil channel" instead of another channel to check. Viewing it in that way, it is reducing the number of channels by simply inlining it.
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.
> Fossil chat is designed for use by insiders - people with check-in privileges or higher. It is not intended as a general-purpose gathering place for random passers-by on the internet. Fossil chat seeks to provide a communication venue for discussion that does not become part of the permanent record for the project. For persistent and durable discussion, use the Forum. Because the conversation is intended to be ephemeral, the chat messages are local to a single repository. Chat content does not sync.
Most Fossil projects are on the smaller (smallest?) side, apart from 2-3 outliers. They certainly don't have a dedicated IM channel, and they certainly don't need it... except when they do.
I could see this as a useful feature when you need to chat with contributors once in a while in a less-formal way than issue comments.
Yes. Developers working independently is best for productivity, but sometimes you need to coordinate something, which then brings up the question: what to use? The last time I tried to list it, I came up with over a dozen options, all of which either require some sort of admin setup hassle or put you into the claws of some megacorp. With Fossil chat, you've already got Fossil set up, so it becomes the low-friction path.
Agh this is a weird combination of accurate and not.
Fossil works offline! But leaving a local server up is pretty normal, and that way you get new stuff just as soon as other servers publish it.
Also, and unique to fossil, the server is just... fossil, same fossil that runs locally. No Gogs, no Gitlab, just your fossil, their fossil, and fossil on the server, maybe with a "real" webserver in front of it, maybe not.
The chat room is clearly intended to be run on an always-on server instance, but there's nothing stopping you from setting it up locally and inviting people to jump on your IP. Well, NAT might well be stopping you... but in principle!
I feel that's a bit short-sighted, but I'll admit I'm only a random opinionated passer-by. You can certainly do it, but you'll run quickly into issues and be buried in feature requests because like it or not, a chat room isn't just "a couple messages being passed back and forth"
Hand rolling your own communication tool is a great way to become so busy you don't have time for your actual work.
In the context of fossil-scm, it does make sense. The idea of fossil is that it's 1 embedded database (sqlite) that contains the entirety of your development activities.
scm, wiki, defect tracking, a little bit of project management, and now chat room.
The entire idea of fossil is that you shouldn't need to use another website or another tool for anything related to tracking your development. It's the "I am stranded on a tropical island, what do I use for hacking on a project if I can't have github or irc or slack or any other tools out there."
In the context of fossil, chat is just a couple messages being passed around with no account taken at all for any other concerns. It's not a "chat" tool, it's a chat tool for the fossil-scm. Especially if you look at the Ephemeral feature - they delete chat messages after a certain configurable time - so they don't even have to worry about keeping messages.
> I feel that's a bit short-sighted, ... You can certainly do it, but you'll run quickly into issues and be buried in feature requests
(Disclaimer: i wrote 99%+ of the fossil chat front-end code.)
FWIW...
When Richard (our Alpha Coder) first posted about his proof-of-concept app for the chat feature my inner reaction was very similar to yours. However, writing a chat front-end sounded like an interesting way to spent Christmas, so dove right in.
Now, exactly 3 months later, we've been using chat 24/7 within the Fossil project and i use it heavily on one of my own projects (hosted over CGI, and my biggest initial skepticism was whether chat could work reasonably well that way). Despite my early doubts it's been a genuine help to us within the project. i don't recall us getting more than 1 small feature request since then, and that was cut off the same way the hypothetical deluge would be: point them to the feature's scope document and redirect such users to Discord or Facebook or whatever the cool kids are using these days.
It's been remarkably low-maintenance so far. The only notable development in the /chat code in the past 3 months was the recent replacement of window.fetch with more conventional XHR because of compatibility issues with window.fetch for some clients, and that took all of 90 minutes or so to do.
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.
I had to build chat functionality into my own project. All I support is text and image/webm uploads. No, emojis. No edits, no quoting, no direct messaging. I wish there was a standard for this with implementations in every programming language. The only thing that I want to build myself is the UI.
When one views a fossil-hosted forum post from the main fossil site or sqlite's site, they are looking at...
- A forum post rendered by software Richard wrote.
- Piped out to you via an HTTP server he wrote.
- Served from an SCM he wrote.
- Stored on a database package he wrote.
- All coded in a text editor he wrote.
Complete vertical integration. He's written, or had a majority hand in, every part of the chain except for the browser. We're all awaiting his announcement about his browser project. It's only a matter of time.
I'd rather he'd announce his MTA & MUA so we can reinstate the fossil mailing list. Going to its own quirky (at the time, haven't checked since the switch) forums meant I lost interest in being part of the (dev) community.
> I'd rather he'd announce his MTA & MUA so we can reinstate the fossil mailing list.
It's demonstrably become impossible to manage spam in such an environment without the resources of mega-corps, whereas fossil aims to be a entirely SCM environment in a single binary hosted from modest hardware (e.g. a Raspberry Pi).
The inability to manage spam was the driving factor for the forum. It is somewhat quirky, but it works well and our spam rate has been literally one single spam in nearly three years of operation (and that one was subtle - hiding an ad link inside a markdown hyperlink which enclosed only a single period). Similarly, the sqlite forum (which was migrated only relatively recently) is also spam-free.
If you have found a way to develop a fully spam-proof, mailing-list-based solution then, by all means, show us the code. Until then, the forum has proven to completely solve the problem it set out to: provide a spam-free communication channel for fossil and sqlite.
> What's the text editor? If anything could get me off Emacs, it'd come from the Hippoverse.
It's a basic tk-based app, IIRC. i peaked at it once when he posted a link to it, but that was 7+ years ago and i don't recall where it lives. No syntax highlighting, no configurable options (beyond editing the source code), very much built for his personal coding style.
You don't want to leave emacs. Emacs loves you. Trust emacs.
Fossil supports CGI extensions and Thunderbird saves your messages in an sqlite database. I plan to read my email from within Fossil repos. Why? Because I routinely download email messages and commit them to the repo. This will give me a web interface to read messages and, if I want, copy them into the tickets database. I can then query all the email messages related to a project using SQL.
I realize your message was not serious, but it's a real use case.
Does anyone use Fossil? I'm considering it for my personal projects. I like all it offers for the relatively low resource usage.
The only use of it I've seen in the wild is Ripcord (https://dev.cancel.fm/issues), which is interestingly also relatively low resource usage compared to its competitor.
I use Fossil and run a Fossil hosting service called ChiselApp [0].
I've used Fossil for all kinds of projects big (commercial Linux distributions, with installer ISO as the result of the CI/CD pipeline stored as Fossil Unversioned content artifacts) to small (a single file demo), but primarily with only a small number of developers.
Could you please put up a post on the ChiselApp website about your motivations for running a free service, how you manage it, etc.? It’s always interesting to see these free services without a commercial angle, and makes me wonder why they’re there, how they sustain themselves, what restrictions they impose on users, and related matters.
I run it because I use Fossil a lot and want a low-friction way to create new repos. It doesn't cost me anything to run since I already had extra CPU, RAM, and Disk capacity on my personal server.
I use it for most of my projects, with git covering the rest of them. I prefer the cli usage, philosophy, single binary / single file repository, and having all the notes/issues transfer across when I push makes it easier to develop and test across windows/linux/bsd. Autosync and other things are well-thought out details too; generally feels well designed. Otherwise, day to day usage isn't much different.
I decided to give it a try on a new project and, although it seemed strange at first (coming from years using git), I fell in love with it and I'm converting all my own projects to fossil. It does everything other SCMs do. It also can do everything git does, but in a saner way.
Also, the self-hosting capabilities in a few MB binary are astonishing and you just don't pay for what you don't use. In my own repositories, I don't use chat nor wiki pages, but I do use forum, the ticket system and technotes.
The community and developers are very nice to answer questions too, and are open for suggestions. There is room for even further improvement and it is more a matter of someone showing up willing to develop the specific feature of the project.
I do not consider having 10 buggy commits per feature instead of 1 working one an advantage. It just complicates reading history and hinders debugging (e.g. bisect). I get their arguments, I just disagree.
The theory is that you don't see those 10 commits unless you choose to.
I think they're right in theory that a Sufficiently Smart^TM scm should be able to work better by not throwing data away, but I haven't tested if it actually works in practice.
> The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.
This is what private branches are for - when you merge them and sync they show up as a single commit on the mainline branch - not too different from git merge --squash.
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.
Agreed. In particular “Rebasing is lying about the project history” is misleading and frankly, just downright lame hyperbole. I actually want to try Fossil, but this text is so dishonest and hyperbolic, it’s off-putting and preventing me from trying Fossil. This feels like a sign that Fossil might not be focused on real world user needs.
It’s not uncommon to bump into this claim in threads about git, I don’t think the Fossil devs came up with this idea, but they sure are running with it. This is an argument whose time has passed and needs to die. It’s not helpful.
Please @Fossil devs, come up with better and more honest reasons to compare Fossil to git. If I don’t have to rebase again, that’s great! If Fossil avoids merge conflicts more often, and handles merge conflicts better, absolutely fantastic.
But, please, come on. Rebase is “lying” exactly just as much as hitting backspace is “lying”. Am I lying if I fix a typo or a bug before I commit? Do you really want to preserve all keystrokes ever typed on your keyboard during development? Does Fossil actually capture all keystrokes? If not, then are you sure Fossil is not lying about development history by your definition? Being able to clean and organize your development history before you share it with others is an intentional feature, not a bug. Attempting to claim a moral high ground over what is purely a technical and workflow issue is making Fossil look ignorant to me, it’s doing the opposite of what you want.
I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.
The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A transaction is created by the "commit" command. Git and Fossil make no record of the stuff that happens in between two commits. They only record what is in each commit. So you can backspace and edit and change all you want to before typing "commit". But once you type "commit", all that you've done since the previous commit becomes part of the permanent record. Rebase violates that constraint. It changes the permanent record. Rebase makes the repository say that the sequence of commits is different from the order in which they actually happened.
You can call that whatever you like. "Telling a compelling story." "Generating a clean history." I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
It is useful to have a simplified overview of project history, to aid the reader's comprehension. There is no sin in this as long as you are truthful to state that the simplified history is in fact a simplification that skips or revises some of the messy details of reality. The alternatives to rebase that Fossil provides do exactly that - they suppress the unimportant details of the history to provide a simplified and more readable history. The difference is that the original, truthful history is still provided, for auditing and for those who care. In other words, the repository reports both "what we should have done" and/or "the best way to think about what we did" in addition to "what actually happened".
I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative. But I think that a source code repository should be a true history of a project. If you view a source repository as a true history, as I do, then rebase is a tool for lying about the history.
> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
This is exactly the kind of dishonest hyperbole daheart mentioned.
The purpose isn‘t to deceive the reader. Does the reader really need to see the "tmp" commit I made when switching from my desktop to my laptop? I do not think so, and squashing this commit is not intended to deceive anybody. Your comment on the other hand…
In my view, what I am doing with rebase is creating project history, not changing it. The history becomes immutable and "the truth" once the feature branch is merged.
> I think that a source code repository should be a true history of a project.
You repeatedly claim this without justification. Seems like many people do not see the value in "WIP" and "tmp" commits and failed design decisions littering history.
You do provide good reasons for why this isn‘t useful though:
> So you can backspace and edit and change all you want to before typing "commit"
So you agree correcting mistakes is useful, and not everything should be recorded.
> It is useful to have a simplified overview of project history, to aid the reader's comprehension.
> I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative.
Exactly.
Consider "I ate a sandwich." vs "I though about eating a watermelone (typo), but when I opened the fridge, I changed my mind and decided to make a sandwich instead. During the process I dropped my knife on the floor and had to clean it. Then I ate a sandwich."
The second one is a much more detailed and truthful account of what happened, yet it does not provide any value. The first, much shorter and easier to follow, history conveys exactly what I wanted to tell you: What I ate.
> If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.
I use rebase to clean up the history of my feature branches before merging to release branches.
In that sense I don’t see a moral difference between not committing my work at all until it’s complete and rebasing. It doesn’t seem like any more of a rewriting of history than just editing text before each commit.
The nice thing about rebasing is that future readers don’t need to see the 20 commits I created titled “wip” just so I could back up my work at the end of the day or push to a test server.
There is a better way to achieve your goal of removing uninteresting commits from the project history. Rather than explain it here, I will write an article about it and post it on HN. Stay tuned.
My philosophy is that the true transaction event and accurate immutable history of the project is the artifact built for release (in our process, the merge to master drives this and therefore commits to it map to the transaction event). The stumbles and trips along the way are irrelevant keystrokes that get backspaced / rebased out.
Big fan of SQLite here (thank you!), and very interested in Fossil as well.
I never understood why people want to change commit history in Git, so for me it won't be an issue to not have that in Fossil.
Having said that, one point of feedback on the "lying" part: I personally interpret that type of negative phrasing as pointing at a different tool and saying: "Look! They're doing it wrong!"
You make amazing tools, man! There is no need to speak negatively about the behaviour of other players if you're a fantastic player yourself. I'd personally just mention: "Git allows you to change history. Fossil is never going to allow changing history, because that could cause issues X, Y and Z. If you do need to change history for some reason, by all means try something like Git." Keep it factual, and get right back to pointing out what makes Fossil great.
I love how SQLite doesn't downplay any alternatives, it just says: "Look at me. I'm awesome. But if you need to do <unsupported thing>, you probably don't want to use me."
It would be great if the Fossil website had that same awesome attitude.
TL/DR: Random guy X that never created a successful product gave marketing advice to the person who created one of the most successful products of all time. Random guy X is an idiot.
> There is no need to speak negatively about the behaviour of other players
I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburger and they give you a chicken sandwich, maybe it doesn't bother you since you like both, but it would indeed be lying if someone asks what you're eating and you say it's a cheeseburger.
What history, exactly, is being preserved? If I fix a bug before I commit, then I’m okay. If I commit the bug, then commit the fix, then squash, all locally on my own machine before I push anything, I’m “lying”?
You don’t want the ability to edit your own mistakes before showing them to other people, even if you find them before you push?
Fossil is not capturing my pre-commit keystrokes, so I can write code and delete it without turning it into a ‘transaction’. Is that lying?
What’s sacred about my local branch before I push? In practice, nobody rebases things in public branches except by accident or to fix big mistakes. Rebase is almost entirely a local pre-push workflow. Why should I be preserving my local pre-push history, and why are you calling that “project history”?
If “project history” is so sacred that all commits should be declared immutable, how do you suggest fixing accidents like someone checking in SSH keys? Is it impossible to fix security accidents in Fossil? If so, is that good?
Why is the word “lying” being used instead of saying something like “the project’s history of transactions is being changed”? Do you think the phrasing is not intentional? Do you believe it’s good faith to accuse tool writers and tool users of being deceitful for just using a tool the way it’s designed? Do you believe the write up on rebase is impartial?
I think (a) all of this was explained clearly in the post by SQLite (Fossil creator), and (b) you're overly sensitive to a disagreement about the definition of terms. I agree with him. You don't. That's fine - no kittens will be put to death depending on who is right.
Hehe, true, no kittens will die. I'm just debating, so don't get overly sensitive just because I disagree.
I don't feel like it was clearly explained, which is why I asked those questions. There's no distinction between local private history and public history shared with others, there's no explanation for the arbitrary line drawn on transaction boundaries, or why those are more sacred than other kinds of project history. There's no clear explanation of why "project history" should be immutable, or even what constitutes "project history" exactly. It sounds generally like a good idea to keep history to me, heck I'm on board! But the reasons to be absolute about it have not at all been clearly established, only stated dogmatically.
Everyone jumping on me is defending the use of the words "dishonest", "fabricate", "white-wash", "lying", and "deceive" as though they're merely accurate and not what they are: intentional attempts to induce shame about rebase. My point is, simply, that this is spin and it's misplaced because git was not designed to take away your freedom to modify your commit history.
I once ordered a cheeseburger and got a “burger” without a beef patty or any other kind of meat, not even the veggie pretend meat. Just bread, sauce, pickles and a single slice of cheese.
I felt pretty disappointed with that “cheeseburger”.
Anyway, my point is that the real world lying about cheeseburgers situation is a lot worse than pulling a fast one and handing over a chicken sandwich.
I would begrudgingly have accepted a chicken sandwich.
It is a little better, and I’d like to acknowledge that you were open to the idea and thank you for taking action.
I haven’t been entirely persuasive here, so I’m reflecting on how to better elaborate my thoughts. The singular word “lying” isn’t really the main thrust of my objection.
Maybe the biggest issue I see still there is the assertions about the intent behind rebase, which means the intent of git’s developers and git rebase users. It’s not really true that rebase intends to “deceive”, that’s not how the authors of the feature talk about it or frame the feature. In my opinion, it’s a semantic cop-out to claim the words are factual and non-judgemental, when the negative thrust of your choice of language is evident, and when there are clearly less loaded words available to you.
It is in that sense - your assertion that the primary intent behind rebase is to deceive people - that I feel like the Fossil documentation is still not being particularly truthful with the facts.
One way to look at this is to ask what would happen if git removed rebase. Right now, if that happened, and git didn’t change anything else about it’s design, it would be somewhat frustrating and unusable. Rebase doesn’t exist on an island, and removing it would have negative consequences, and need to be replaced with other features. Git doesn’t have a way to present a clean history without rebase there. It would be awesome for Fossil’s story to note how the fundamental design is an improvement over git.
I know your framing and language is intentional because you believe strongly in the idea of preserving project history. That is an acceptable, even laudable goal. I’m for it. Git did not have that goal when it was designed, and it’s not fair to selectively leave out that fact when criticizing. Aren’t there better ways to make the point without presuming to proclaim what the intent of rebase is? Can’t the harmful implications of rebase be demonstrated rather than framing it as “fictitious”, “fabricated”, “counter-factual”? Could you talk about it without accusing innocent bystanders of “white-washing” and being “untruthful”?
BTW, I think the Pro Git book commentary isn’t that fair to hold up as evidence for two reasons - they didn’t design rebase, and they are also trying to softly address the very argument you’re putting forward, because it keeps coming around. The existence of their comments doesn’t somehow prove that git designed rebase to “lie”, it only shows that they heard you.
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.
> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
Do you have any better reasons to avoid rebase that don’t depend on your own negative interpretation of git’s design intent, an interpretation that contradicts git documentation?
You could be focusing on positives instead of trash talking. You could be talking about the interesting idea of providing multiple views of history, one un-editable for details and one editable for presentation. That’s interesting and useful. Instead you choose to take cheap shots at a system that was designed differently than your ideal, without acknowledging its intent. You are breaking Hanlon’s razor and consciously choosing to assuming malice... for something that has a written history of discussion about why it exists.
Are you aware that rebase openly advertises the fact that it reorders commits, and was designed that way intentionally? Are you aware that git openly makes zero guarantees about the order of transaction events, intentionally, to allow me to have control over my presentation? Are you aware that rebase is primarily used on local commits before push, and not often used after push?
I would speculate that you are aware of these things, and not simply ignorant about git. If so, that means you are lying here and now, if not it means you don’t know what you’re talking about. I think you know git’s design intent, so it seems like you are intentionally misrepresenting the design intent of rebase. The only deceit here is coming from you, ironically.
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.
Why are you calling it “lying”? That’s a framing with a value judgement that is accusing people who rebase of being malicious. Do you believe use of rebase is malicious?
Who are you lying to, if the other people on your team expect your merges to be rebased before you push?
What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed?
Rebase is not intending to trick someone, it is not concealing a truth that needs to be otherwise preserved. Rebase is not hiding something that should not be hidden. Rebase is for cleanup and fixing mistakes.
Please stop using inappropriate words. It’s completely fine to preserve your messy edit history. It’s completely fine to want to preserve your mess. But it is not “lying” to clean it up before you push.
It’s funny you suggest I’m rephrasing it, when you are the one using different (negative) language than the git manual.
The Fossil manual is pretty clear about calling it deceit. “By discarding parentage information, rebase attempts to deceive the reader about how the code actually came together.”
> where I’m from “rewriting history” is lying...
What history? Rebase is normally used before push. Rebase is used before it’s “history” to someone other than yourself.
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.
Why not just focus on the useful idea of separating presentation from commits, as a +1 bit of design thinking and evolution beyond git? I don't get this pretend crusade for nothing more than facts and truth, when the value judgement in the Fossil docs is thick and plain as day.
I don't even care that Fossil is attacking the competition, really. I am a huge fan of SQLite. I just wish this silly "lying" argument would go away. It does not put Fossil in a good light. It does not make a meaningful contribution to understanding version control workflows. It does not give git (or any other VCS) the benefit of the doubt or it's due credit in the context of it's own design decisions, even if those design decisions are inferior by today's standards or in Dr. Hipp's opinion. But, it's clear I didn't make any progress here, I'll just think about why I'm not being persuasive and try again later. This claim about lying would be just as "true" but even sillier applied to Perforce or Subversion or RCS or SCCS... think about 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.
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.
Welcome to Hacker News. Since you’re new here, you seem to be unaware of the fact that the person who’s opinion you’re referring to and attempting to dismiss is one of the moderators of HN, and one of the authors and keepers of this site’s guidelines.
First, it sounds like you're looking for squash - not rebase.
This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways.
In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar.
Looking at this subthread: Wow! People really get triggered when it comes to Git.
I guess you’re referring to me, and I guess it’s fair. It has nothing to do with git though, I’m triggered when it comes to arguments that I feel like aren’t being made in good faith.
Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.
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.
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.
If you watch a single branch and deactivate the "related" branches, you can avoid seeing all the "buggy commits": all merges in Fossil are what Git does when indicating "--no-ff". No branches are ever deleted, so the individual commits remain in the branch; the merge commit is always a single one.
I avoid it because of complete lack of commit amendment tools.
It seems like quarter of the time I make a commit I mess up either a commit message or a file list, and have to "git amend". I have no idea how the sqlite devs live without the feature, they must be much more careful programmers than I am.
There has pretty much always been a way to amend commits -- the difference is in Fossil this amendment is done by writing a new journal entry (artifact) noting which commit is being amended and how, rather than modifying the commit directly.
Generally, the compiled version (base+resultant set of amendments) is displayed to the user, but the entries which modified the commit are also available to be seen.
Git preserves a record of the origial commit, plus amendments leading up to the final - git-reflog. The reflog is however subject to periodic pruning by default - see git-gc.
> Ah, due to (who would've thunk) the SQLite connection.
The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing support, maintenance, and enhancement of SQLite would not be possible without TCL, and would be seriously inconvenienced without Tk.” [0][1]
Brad! You're alive! In case you hadn't heard: libfossil was recently revived, has been brought up to date with regards to SHA3 hashes, and got both "update" and "revert" APIs within the past week or two. The "last" major day-to-day feature it's missing is merge. We have the merge algo (it's used by update), but not yet the equivalent of the merge command. Your account is still active on the repo (https://fossil.wanderinghorse.net/r/libfossil).
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.
I use Fossil for my own projects. However, I do not use the forum feature, chat feature, etc. They don't belong there in my opinion, nor do I like the implementation much; I use external software.
There are a few other things I dislike about the design of Fossil; it doesn't have very good low level access, for one thing (there are other concerns too, although rebase isn't one of them). I have started to make my own implementation, which I intend to support the Fossil protocol and deconstruction format. Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, while I consider it important (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it). As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.
> Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority,
That's me (https://fossil.wanderinghorse.net/r/libfossil). The protocol is irrelevant to the implementation of the underlying core algorithms and data format. The sync protocol is a completely separate layer which can be reimplemented any number of ways without affecting the underlying data model. Without the core data model and algos implemented, the sync protocol is useless because it has nothing to sync.
Ergo: first implement the data model, then the sync.
> (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it)
That's a really interesting topic, actually. The core data model is 100% independent of any given schema (or storage model, for that matter), so anyone implementing a compatible (at the data model level) tool is free to use whatever storage or schema they want. The fact is, though, that libfossil could never have gotten as far as it has without re-using much of what Richard has already designed, and that includes the schema and core SCM-relevant algorithms. As a long-time fossil contributor, it's important to me that the libfossil tools be as compatible as feasible with fossil, and that means using the same schema (for better or worse).
That said: i would very much like to see the core data model implemented on top of another schema, just to see it done. Alas, i don't have the energy to create, from scratch, such a beast, nor to maintain it, so my path is one of lower resistance: re-use what's already been designed and which works well within the fossil project. i'd love to see what you have when you're ready to post it, though. (i recall you(?) posting about this in the fossil forum before - feel free to announce your project there when you're ready.)
> As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.
What else would one call a "container of cards"? :)
I use it for any personal projects that are large enough that I want a few pages of documentation and a ticket system to keep track of planned features.
The ticket system can be configured quite a bit, so I usually set it up like a todo list with: “to do, doing, done”.
Almost literally every day since Christmas break of 2007.
> I like all it offers for the relatively low resource usage.
And setting it up to run over CGI (e.g. over a $5/month shared hoster) takes about 90 seconds and requires no additional apps. That was the initial Killer Feature for me, and is still critical for me. i host dozens of repositories over CGI on an inexpensive shared hoster (https://fossil.wanderinghorse.net), and couldn't do that with any other SCM.
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?
Well yeah because git is, I find, good enough that I don’t have much desire to experiment with other SCM tools. Some people love customizing every part of their tool chain but to me it’s better to stick with something familiar with things like that so I can focus on solving my actual problem.
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.
Pretty much everyone already uses git and some kind of issue tracker so the question is more if it's so much better to justify learning a new thing, not if it is slightly better in the abstract. It is not immediately obvious to me that bundling all these things into one tool is going to give better results, especially when you have non-developer users in the mix.
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.
The biggest difference was that write(1) was 1:1, whereas this lets any number of people participate. It's got a bit of formatting control as well, though not full Markdown, alas.
I tried to created an account to see it live at https://www.fossil-scm.org/home/chat but it appears they have /chat locked down to authorized accounts.
(Regardless of what others might be saying in this thread, I think this functionality is great. It reinforces the centralization of your dev related work. Plus, presumably they are using SQLite on the backend - so /chat might result in now additional functionality being added to SQLite that might also be beneficiary e.g. removing blocking on writes, etc)
Yes, chat messages are stored in a table in the SQLite DB backing the repository you're chatting about, which allows you to close the browser window when you need some peace to concentrate on work, then revisit the chat room later and see what's been going on while you were away.
As for the dream of making SQLite faster or better, I doubt it. Fossil works best for small teams with projects sized reasonably for those teams, and chat privilege isn't generally given out to the masses. There's only one chat room per repo. Therefore, there simply isn't enough I/O involved to drive much in the way of SQLite changes.
Fossil proper has resulted in SQLite improvements, though, such as the recursive CTE feature added in 3.34.0. That directly supported a feature for tracing the history of files through renames across repository history using a single efficient (though complicated) SQL query: https://fossil-scm.org/forum/forumpost/5631123d66
As others have said, the fact that this isn't geared as a replacement implies that its an additional distraction on top of established chat.
Perhaps a better iteration would be as a consistent proxy to other chat hosts? As in, once configured, this chat feature would mirror to IRC, Slack, Discord, Telegram, Google Hangouts, etc.
Fossil users could have barebones but consistent access to team chats without the multiple inboxes problem? Or they could use the established chat host directly and never look at this chat again.
It's a fair question. I need to better document the security features built into Fossil. Here is a quick off-the-top-of-my-head summary:
(1) Fossil is designed to run inside a minimal chroot jail. The stand-alone "fossil" binary needs its repository database file, /dev/null, and /dev/random and nothing else. It can run inside a sparse jail. So even if somebody manages to find an RCE in Fossil, the damage potential is limited. They cannot shell-out because there is no /bin/sh in the jail.
(2) Fossil processes each HTTP request in a separate process.
(3) Custom static-analysis tools run over the Fossil sources at compile-time, and abort the built if any problems are seen. The source code and docs to these tools is in the Fossil source tree.
> How is the security with Fossil? I'm always leery of hosting (niche) web facing services written in C.
Fossil's been available for nearly 14 years now and we've had to make only a single security-relevant release in that time (in late Summer 2020).
Fossil's primary architect, Richard Hipp (edit: HN user "SQLite"), is no stranger to code hardening and continues to add security-related APIs to all levels of the code, from how we internally build SQL queries or encode URL arguments to the recent (late 2020) ability for the db to lock down regions of the db until/unless that protection is toggled off for the brief blocks of code which need to modify those regions, ensuring that other areas of the code cannot modify parts of the database which they aren't directly responsible for. Security against malicious inputs has never been treated as an afterthought in fossil.
Fossil is a single executable with low system requirements operating on a single SQLite database file, so it's really easy to chroot. It'll even chroot itself if started as root: https://www.fossil-scm.org/home/doc/trunk/www/chroot.md
If you want something more complicated (BSD jails, Docker, etc.) the same properties make it easy to box up that way instead.
Caddy, though I have used NGINX and HAProxy in the past. I get your point, but those projects have corporate backing and a lot of scrutiny. A niche C project seems less likely to have that.
SQLite3 is the only project I have ever seen that casually makes (non-normative, non-legally-binding) confident reference to its suitability for use in medical devices.
My understanding is, if you pay for a support contract, they are happy to make it legally binding.
It's literally the most used database in the world, but a giant margin. Every Android and iOS device and every mac and linux machine use SQLite. I haven't ever bothered to check Windows, but I bet they use it too.
I think you mean cdvs, the e is clearly overkill, takes up more bytes on disk, increases compile times and eats up valuable screen real estate! The last one is especially bad, because it will make the code that uses it harder to read.
> I think you mean cdvs, the e is clearly overkill, takes up more bytes on disk, increases compile times and eats up valuable screen real estate!
Also one more extra letter to type for people who can type 100+ words per minute and over an entire day probably only need to type 2 words per minute on average (the rest of the time spent thinking, debugging, reading documentation, being in meetings, etc) :-)
Where are the screenshots?? How infuriating is it to go to a project's homepage that has a UI and not see any goddamn screenshots. This is absolutely table stakes if you want me to use your product.
edit: Oh haha, the website is literally Fossil. Ok but I wanna see what the chat UI and other stuff looks like.
All I can think is that it seems a bit early for April Fool's jokes.
It isn't clear what makes bundling a chat program into your SCM beneficial. The only benefit I can see is linking to other things in the SCM like wikis and issues, but since these are available on the web anyways you can just use regular URLs in any old chat app.
The other possible benefit would be keeping chat with you for local searching and keeping it with the history of the repo, however this is designed to be ephemeral so throwing that possible benefit away. (I guess you are supposed to use Forums for that https://www.fossil-scm.org/home/doc/trunk/www/forum.wiki)
I'm not a Fossil user, so maybe I just don't understand, but I see little to no value in this feature.
If you already have a chat infrastructure set up with all the bells and whistles, then you probably don't need this; it is a different kind of workflow.
But one workflow for it would be open source projects that prefer not to have to maintain additional infrastructure and just want to inline ephemeral communication w/o having to keep it forever; then they make a design decision and have everything that is finalised moved over and documented in the wiki.
Lack of a direct messaging/email feature is one of the major lacuna of Git hub. In that light may be having some sort of integrated channel is a good thing.
> It isn't clear what makes bundling a chat program into your SCM beneficial. ... you can just use regular URLs in any old chat app.
You just answered your own question: trying to get any given group of people to use the same 3rd-party chat platform, especially one hosted by Big Megacorp (and aren't they all nowadays?), is like herding cats. Every developer on a fossil project already has an account they can use, not hosted by Big Megacorp, which they can chat over (provided the project admin permits it - they are not required to give devs chat access).
i admit that i had several reservations when Richard proposed /chat on the fossil mailing list, but i'm a 100% convert, and now use it 24/7 on two projects and get tremendous value from it.
(Disclaimer: i wrote the /chat front-end, so am inherently biased, but i'm biased towards it because it's useful, low/zero-maintenance, and low-friction, not because i've invested many hours into its development.)
What it looks like: https://imgur.com/a/PaHExsp
Here's Fossil 2.15 running on EC2: http://54.79.202.57/register - this link will allow you to create a new account.
Alternatively, the "chat" user (password "chat") can be used if you don't want to make an account. [It used to have the ability to create additional users (with admin privs), with the result that the fossil instance rapidly began spouting SQL errors and I had to reset it, twice. That was fun...]
The instance is completely ephemeral. If this comment is more than a week or so old, expect the above IP to be dead (I'll be cycling the VM).
And yes - note that it's going over HTTP, not HTTPS :P (that would have taken an extra, uhh, while)
--
If you're using 'chat': once you've opened the above link, go to "login", login, then locate the new "chat" tab. You can optionally go to Admin > Users and make yourself a new account (the "Add" link is a little hard to see, it's to the far left immediately under the tab bar; also be sure to select "Chatroom" from the far right in the permissions list).