51–60 of 164 posts
I'm not hosting this on the public Internet, so maybe it's not a fair comparison, but thought it was worth mentioning that there are lighter/easier forge options than Gitlab.
This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo. So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and push…
This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo. So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and push…
It really depends on what you're optimizing for.
> Sometimes people just can’t work out how to send me patches at all. Yeah indeed. I have written but not submitted patches to a project (OpenSBI) because it made the submission process super complicated, requiring signing up to a mailing list, learning how to set up git send-email. I don't see how he can think creating a GitHub account (which almost everyone already has) is a big barrier when he freely admits his pr…
A traditionally configured mailing list allows posts from non-subscribers.
All the mailing lists I operate are like this.
If you have good anti-spam-fu, you can get away with it. Plus, it's possible to have posts from non-members be held for moderation, and you can whitelist non-members who write legitimate posts.
Projects which require people to sign up to their mailing lists to participate are erecting a barrier that costs them users; it's a stupid thing to do, and unnecessary.
Whenever I have to interact with some mailing list, I begin by just sending my query to the list address. If it bounces due to nonmembership, I usually move on, unless it's some important matter.
By the way, some modern lists allow posts from non-members but then rewrite the headers in such a way that the nonmember does not receive replies! This happens in more than one way, I think. One of them is Reply-To Munging: the list robot sets the Reply-To: header redirecting replies to be directed to the list address. The Reply-To throws away the content of the original To and Cc fields.
When this happens to me, I usually refrain from further interaction with the list. I check for replies in their archive. If I'm satisfied with what they said, that's the end of it.
Earlier quoted context omitted.
Yup. +1 for fossil. I wanted an issue tracker that wasn’t text files in the repo. Lots of git-based things that were heavier (gitea and friends) or hackier than I wanted. Decided to finally try out fossil and I think it’s really really neat.
In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?
- The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again.
- For published repos, I've gotten in the habit of creating them directly on my webserver and then pulling 'em down with 'fossil clone https://${FOSSIL_USER}@fsl.yellowapple.us/foo'
- The "Fossil way" is to automatically push and pull ("auto-sync") whenever you commit. It feels scary coming from Git, but now that I'm used to it I find it nice that I don't have to remember to separately push things; I just 'fossil ci -m "some message"' and it's automatically pushed. I don't even need to explicitly stage modified files (only newly-created ones), because...
- Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'.
- 'fossil status' doesn't default to showing untracked files like 'git status' does; 'fossil status --differ' is a closer equivalent.
It's the goth subculture of software development! Because it's popular, it must be eschewed.
Geez.
Earlier quoted context omitted.
You could write a static site generator to generate a website from the repo, so you’re still just serving static files.
I once explored doing just that: https://github.com/nhanb/boast However I never got around to finishing it, mainly because I couldn't decide on where to stop: should I also generate commits from all non-master branches etc. I flirted with the idea of a browser-side repo viewer too, but re-implementing git packfile parsing in js didn't seem like something I'd want to spend my time on, so I moved on. Glad to see others…
That said, JavaScript libgit2 is a thing [1], so doing it "properly" in a client app is totally possible.
[1]: https://github.com/libgit2/libgit2/issues/4376 | https://github.com/petersalomonsen/wasm-git
This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo. So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and push…
(tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each. It really depends on what you're optimizing for.