[HN Gopher] Fossil Chat
___________________________________________________________________
Fossil Chat
Author : brobdingnagians
Score : 232 points
Date : 2021-03-25 10:51 UTC (12 hours ago)
(HTM) web link (www.fossil-scm.org)
(TXT) w3m dump (www.fossil-scm.org)
| rkeene2 wrote:
| I think this is great. I will upgrade ChiselApp.com to use Fossil
| 2.15 as soon as it's released.
|
| A bit off-topic, but the thing I miss most when I use Fossil
| (versus GitHub.com) is the ability to do code reviews and leave
| in-line comments on code.
|
| Also, pull requests [0] would be awesome for some of my more
| public projects.
|
| [0] https://fossil-
| scm.org/forum/forumpost/01d77b7259ea0b00b7065...
| chillfox wrote:
| Interesting, I could see using fossil for public projects if
| the pull requests gets implemented.
|
| Currently I only use it for private projects. So my top wish
| list feature would be basic CI.
| rkeene2 wrote:
| I started Fossil CI [0] for this, but I have not finished it
| up.
|
| [0] https://chiselapp.com/user/rkeene/repository/fossil-
| ci/index
| sigzero wrote:
| Is there a way to donate to the chiselapp effort?
| rkeene2 wrote:
| I added some ways to donate to my profile on here
| sigzero wrote:
| Excellent
| jayd16 wrote:
| 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.
| danpalmer wrote:
| > Fossil chat is not intended as a replacement or competitor for
| <list of chat platforms>
|
| So what is it for? If it's another inbox to check that's a bit of
| a productivity drain.
|
| I could understand if it was explicitly designed to compete with
| other chat platforms. This would seem to fit with Fossil's
| mission well.
| Thursday032521 wrote:
| > 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.
| butterisgood wrote:
| Sounds like a privileged "finger" for a collective ".plan"
| style uh... thingy.
| mgreenleaf wrote:
| 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.
| jayd16 wrote:
| >Then the core members don't need to have a dedicated channel
| somewhere else.
|
| But isn't that "a replacement"?
| exDM69 wrote:
| Fossil is offline. You sync up when connected and then you have
| code, issues, wiki, chat that work offline, and sync when
| connected again.
|
| It's not an instant messenger, more like a mail box or a
| bulletin board. Which works when network is down.
| chillfox wrote:
| The chat does not sync
| rkeene2 wrote:
| There are Forums within Fossil for this kind of thing,
| though.
| samatman wrote:
| 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!
| scambier wrote:
| 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.
| wyoung2 wrote:
| 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.
| NoodleIncident wrote:
| I forsee an addition to this diagram with "the chat tab of
| a shared fossil repo", as one of the completely isolated
| bubbles to the side
|
| https://xkcd.com/1810/
| jnwatson wrote:
| Another instance of Zawinski's Law: "Every program attempts to
| expand until it can read mail".
| bachmeier wrote:
| Well actually...
|
| 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.
| whereistimbo wrote:
| I'm looking forward to email client in Fossil, preferably on
| the next April 1st!
| swiley wrote:
| git: version control over messaging
|
| fossil: messaging over version control
| alberth wrote:
| Has anyone seen a demo?
|
| 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)
| wyoung2 wrote:
| 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
| exikyut wrote:
| See my comment over at
| https://news.ycombinator.com/item?id=26579872
| exikyut wrote:
| HI!
|
| 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).
| Tenal wrote:
| Yikes.
|
| Tip: Hire a designer.
| butterisgood wrote:
| Not able to login a chat:chat
| exikyut wrote:
| FIXED
|
| _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.]
| nattaylor wrote:
| Some seems to have changed the password already :/
|
| Too bad it isn't allowed for logged-in anonymous users to chat
| (though that would be confusing!)
| exikyut wrote:
| Fixed and fixed. You can now go directly to
| http://54.79.202.57/register
| tomphoolery wrote:
| i mean, this site is called "hacker" news so...
| exikyut wrote:
| Yeah, enabling _all the things(tm)_ 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
| SQLite wrote:
| Thanks for the demo server, exikyut.
|
| 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.
| exikyut wrote:
| :O hi!
|
| Done, that's a really cool feature.
| SQLite wrote:
| 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.
| exikyut wrote:
| Thanks. For completeness, this was fixed.
| j-pb wrote:
| 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!"
| [deleted]
| kevincox wrote:
| 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.
| sgbeal wrote:
| > 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.)
| billfruit wrote:
| 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.
| [deleted]
| mgreenleaf wrote:
| 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.
| halfmatthalfcat wrote:
| 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.
| sigzero wrote:
| Pretty much what I'd expect...
|
| https://imgur.com/a/EQ2wSQi
| exikyut wrote:
| See my comment over at
| https://news.ycombinator.com/item?id=26579872
| julianlam wrote:
| So they built their own chat room feature?
|
| 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.
| supportlocal4h wrote:
| Heh. Building an scm is a great way to become so busy you don't
| have time for your actual work. Building a db is another great
| way.
|
| If I could be so unproductive...
| sgbeal wrote:
| > If I could be so unproductive...
|
| It goes much further than that...
|
| 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.
| ephaeton wrote:
| 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.
| sgbeal wrote:
| > 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.
| gglitch wrote:
| What's the text editor? If anything could get me off Emacs,
| it'd come from the Hippoverse.
| barkingcat wrote:
| 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.
| mscrnt wrote:
| 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.
| sgbeal wrote:
| > 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.
| orf wrote:
| mdel, ltime, mtime. Why do people insist on oft unreadable short
| column names?
| oblio wrote:
| Because they're cdevs.
| exikyut wrote:
| Dear diary,
|
| I was today years old when I learned I was a character
| device.
|
| I'm not surprised; I _do_ emit a lot of bytes all day.
| orf wrote:
| 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.
| onychomys wrote:
| Surely we should instead use cdv, in case there's only one
| of them in a row. And boom, 25% space savings from that
| little change!
| orf wrote:
| This is a 25% decrease in storage and a 25% increase in
| raw typing throughput. Truly increadible.
| oblio wrote:
| > 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) :-)
| sgbeal wrote:
| > mdel, ltime, mtime. Why do people insist on oft unreadable
| short column names?
|
| You forgot to mention vfile.chnged. i've been contributing to
| fossil since 2008 and that missing "a" still, to this day,
| agitates me ;).
| HeckFeck wrote:
| 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.
| silasdb wrote:
| 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.
| arsome wrote:
| SQLite is probably the best known user of it
|
| https://sqlite.org/src/doc/trunk/README.md
|
| https://www.sqlite.org/whynotgit.html
| Tomte wrote:
| SQLite obviously. Probably some other projects in the Tcl and
| SQLite world.
| sigzero wrote:
| The TCT (Tcl Core Team) uses it heavily. They seem to like it a
| lot.
| exikyut wrote:
| Ah, due to (who would've thunk) the SQLite connection.
| sigzero wrote:
| That probably had a lot to do with it I am sure.
| bch wrote:
| > 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]
|
| The ties are interesting and deep.
|
| [0] https://sqlite.org/tclsqlite.html
|
| [1] https://www.tcl.tk/community/tcl2017/assets/talk93/Pa
| per.htm...
| KwanEsq wrote:
| SQLite famously does so:
|
| https://www.sqlite.org/cgi/src
| chillfox wrote:
| 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".
| mgreenleaf wrote:
| 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.
| petre wrote:
| Yes, we use it. It's awesome. Thank you again D. Richard Hipp.
| Hendrikto wrote:
| Fossil looks very interesting, but I completely disagree with
| their [stance on rebasing](https://fossil-
| scm.org/home/doc/trunk/www/rebaseharm.md). This is a
| dealbreaker for me.
|
| 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.
| iudqnolq wrote:
| 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.
| BeetleB wrote:
| 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.
| dahart wrote:
| 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.
| SQLite wrote:
| 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.
| dahart wrote:
| > 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.
| mscrnt wrote:
| 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.
| taberiand wrote:
| 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.
| harryvederci wrote:
| 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.
| bachmeier wrote:
| > 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.
| dahart wrote:
| Well said. Exactly. I agree 100%.
|
| > I never understood why people want to change commit
| history in Git
|
| FWIW, by and large, they don't, not after it's been
| pushed. That's one of the major problems with this
| critique.
| justin66 wrote:
| Thanks for explaining the rationale of that feature (or
| lack thereof) here.
|
| Also for the online Fossil docs, which are great.
| rubyist5eva wrote:
| 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.
| [deleted]
| mscrnt wrote:
| 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.
| rkeene2 wrote:
| 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.
|
| [0] https://chiselapp.com/
| AnonHP wrote:
| 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.
| rkeene2 wrote:
| 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.
| emodendroket wrote:
| It seems to me like you'd want it to be obviously way superior
| for some reason to go so far away from the herd.
| mscrnt wrote:
| 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?
| sgbeal wrote:
| > Does anyone use Fossil?
|
| 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.
| theamk wrote:
| 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.
| rkeene2 wrote:
| 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.
| everybodyknows wrote:
| >modifying the commit directly.
|
| 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_.
| rkeene2 wrote:
| Fossil preserves the journal of activities forever, and
| across clones.
| mscrnt wrote:
| You could always try "fossil amend" as a commit amendment
| tool for starters.
| sgbeal wrote:
| > I avoid it because of complete lack of commit amendment
| tools.
|
| That's downright wrong: https://fossil-
| scm.org/home/help/amend
| rcarmo wrote:
| I used it for quite some time, still have archived repos on it
| because they're a single file and very easy to move around.
|
| Mostly moved to gitea on a home NAS for the GitHub sync
| capability (makes it easy to have a local copy of dependencies,
| etc.)
|
| But I do miss the straightforwardness (and sometimes bluntness)
| of fossil sometimes. Much easier to deal with for personal
| projects.
| zzo38computer wrote:
| 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.
| satya71 wrote:
| Reminds me of Unix talk and write. They were so simple when
| sharing little bits of information with people already logged
| into the system.
| wyoung2 wrote:
| 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.
| candiddevmike wrote:
| How is the security with Fossil? I'm always leery of hosting
| (niche) web facing services written in C.
| sgbeal wrote:
| > 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.
| pmarin wrote:
| What web server do you use?
| candiddevmike wrote:
| 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.
| exikyut wrote:
| 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.
| zie wrote:
| 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.
| iudqnolq wrote:
| I just saw today it's "aviation certified", which I
| assumed was the same but turned out to be literally true.
| pmarin wrote:
| Do you know the author of Fossil is the same person who
| wrote sqlite?
| exikyut wrote:
| Apache and nginx are C
|
| As is stunnel, which is what the canonical fossil website uses
| to handle HTTPS
| mscrnt wrote:
| And httpd and relayd.
| wyoung2 wrote:
| 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.
| SQLite wrote:
| 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.
___________________________________________________________________
(page generated 2021-03-25 23:01 UTC)