[HN Gopher] Fossil
___________________________________________________________________
Fossil
Author : tosh
Score : 137 points
Date : 2020-09-30 20:08 UTC (2 hours ago)
(HTM) web link (www.fossil-scm.org)
(TXT) w3m dump (www.fossil-scm.org)
| Midar wrote:
| I'm using it for a while now for https://objfw.nil.im/ and am
| quite happy with it. I wrote a little bit about that at
| https://blog.nil.im/?78.
|
| It's quite sad to see that so few projects use it. The idea of
| having everything in one repo, incl. bugs, is just great. I can
| create new bugs while offline, update bugs while offline, etc.
| and then just sync everything once I'm back online.
|
| It also has pretty good support for incrementally importing from
| and exporting to Git: https://blog.nil.im/?79
| kzrdude wrote:
| Practical aspects aside, having issue tracking in the repo
| prevents lock-in of that data - in the way that the github
| platform works, for example.
| OldHand2018 wrote:
| Thank you for posting a link to your site. It's really nice to
| see a live demonstration of Fossil. I notice that your page is
| using https - does Fossil do that or do you have something else
| in between (nginx, etc) that provides the https?
| Quekid5 wrote:
| > The idea of having everything in one repo, incl. bugs, is
| just great. I can create new bugs while offline, update bugs
| while offline, etc. and then just sync everything once I'm back
| online.
|
| The bug thing I kinda disagree with... or at least I'm
| skeptical, shall we say. Bugs are solved when the fix has been
| _deployed_ and _verified fixed in production_ , not when
| someone commits/pushes/merges a potential fix to the main
| branch. Sure you can separate the 'bug-X fixed' change to the
| bug tracker and the code commits, but then what have you gained
| over just a 'Fixes: X' annotation in the commit msg?
|
| This could be misunderstanding on my part about the
| intent/process around bug/issue handling in Fossil, so I'd
| appreciate if you could expand on what you like about and how
| it works within the larger 'deploy a fix' context.
|
| (I tried Fossil for a bit on a very small scale -- it was
| pleasant enough, but ultimately Git's network effects win out
| big time... at least for me.)
| lrem wrote:
| It isn't putting your issue tracking into an equivalent of a
| git repository. It just contains a rather standard-looking
| issue tracker, along a wiki for documentation, in the same
| sqlite. And they are distributed/synchronized just like the
| repository.
| Quekid5 wrote:
| So they're independent of what happens to the code and just
| happen to be bundled/synced when the code is?
| hexmiles wrote:
| yes
| [deleted]
| Quekid5 wrote:
| Ok, makes sense, but what is the workflow like, then?
| Would one close the bug along with the fix to the code,
| or...?
| Midar wrote:
| That is only true for projects where you need to deploy. In
| that case, yeah, you of course can only close the bug once
| you fixed production. But for normal software development,
| you can fix the bug in the software and you can update the
| bug tracker, and then push everything once you're back
| online.
|
| For example, on a flight, I can look at the bug tracker
| (since it's part of the clone), pick a bug I want to work on,
| create a few commits to fix it, then update that bug (set it
| to closed, reference the commits that fixed it), and then
| upload it all when the plane landed again.
| thunderbong wrote:
| This is really nice. How have you been hosting this? How well
| is fossil able to handle the traffic?
|
| I've read so many articles about the advantages of static site
| generators and serverless implementations for blogs so that
| they are able to handle traffic and the insane amount of
| tooling around each of those concepts. It's so great to see a
| well crafted piece of software being able to take care of all
| that so seamlessly.
|
| I'm a big fan of fossil personally and use it for all my
| projects as well as for all the projects in our organization.
| kayson wrote:
| Reading through some of the articles linked in the comments, I'm
| very hesitant to use something whose creator is so opinionated
| and vocally against another piece of software. Maybe its just the
| style of writing, and isn't actually reflected in Fossil's
| development, but this kind of attitude doesn't inspire
| confidence.
| bachmeier wrote:
| It's more that "why don't you use Github for sqlite" comes up
| six times a day, so at a certain point you have to explain why
| you use your own version control system. A lot of developers
| today know nothing other than Git and assume anything else is
| wrong by default.
| dkulchenko wrote:
| Notably used (and developed) by the SQLite authors. They explain
| their rationale here: https://sqlite.org/whynotgit.html
| rkeene2 wrote:
| I run ChiselApp.com to support publicly hosted Fossil
| repositories.
|
| The architecture behind it is pretty simple, since Fossil is
| doing all the work and I'm just orchestrating it (although I do
| allow you to execute arbitrary Tcl scripts as part of it, so
| there is some work that goes into the sandbox).
| lactobacillis wrote:
| Quick question. Is the entire thing on one SQLite db?
| rkeene2 wrote:
| Each Fossil repository is its own SQLite database.
| Additionally, there's an SQLite database which holds
| ChiselApp.com user information (which is unrelated to Fossil
| information).
| n3k5 wrote:
| > _Fossil also supports bug tracking, wiki, forum, and technotes_
|
| That sounds great, but I'm scared of checking these features out
| because I'm currently looking at the quick start guide[0] and am
| immediately put off by how awful the CSS is. Formatting running
| text such that a single line can be ~500 characters wide[1]
| results in very low readability. There's a difference between
| 'themeable' and 'configuring a custom theme is mandatory because
| the default option makes you feel sick'.
|
| In case someone working on Fossil sees this: I just bookmarked
| the site because the project seems very attractive in most other
| respects. I hope that when I eventually re-visit that link, I'll
| be able to go on a significantly deeper dive. A somewhat sane
| style sheet would certainly help.
|
| [0] https://www.fossil-
| scm.org/home/doc/trunk/www/quickstart.wik... [1]
| https://i.paste.pics/A9RQ8.png
| z2210558 wrote:
| It looks totally fine to me (lines are wrapping normally). Are
| you sure it's not something to do with your own browser?
| flohofwoe wrote:
| Not sure what you're complaining about, the page looks fine in
| a desktop browser window, the text automatically overflows when
| the window is resized.
| kipari wrote:
| I enjoy how well-crafted Fossil seems to be; just like SQLite,
| which a sibling comment also mentioned. I really want to use
| Fossil, but it would be way too hard for me to not have the
| index/staging area of Git. [1] For all the software that claims
| to be 'opinionated', Fossil really is that.
|
| [1]: https://fossil-scm.org/home/doc/trunk/www/gitusers.md
| JoshTriplett wrote:
| Agreed. I'd love to have integrated bug-tracking, and some of
| the other features, but Fossil is also trying to drive
| particular opinions about version control that are incompatible
| with how many people want to work.
|
| It's already hard to move people away from a system that has
| huge network effects. This makes it much harder.
| beagle3 wrote:
| There are several bug tracking systems that store their data
| inside the repository (and as a result, branch / merge / push
| / pull automatically) -- including the venerable "vi
| bugs.txt" system which works surprisingly well from
| experience.
|
| What fossil brings that those systems don't is indeed the
| network effect as you pointed out. It's integrated with the
| web frontend, and is thus used by everyone using fossil and
| fossil's bug tracking, based on experience with cvstrac, is
| low ceremony, easy to use and reasonably effective -- even
| more than "vi bugs.txt" which sets a remarkably low ceremony
| bar.
| JoshTriplett wrote:
| That's exactly what I'd love to have, just without the
| opinionated differences in things like rebase, staging,
| branching, and similar.
| Arnavion wrote:
| Yes. I use `git add -p` and `git stash -p` all the time and
| couldn't work without them. Fossil's equivalents appear to let
| you specify a subset of files to commit / stash, but not
| individual thunks inside them. [1] [2]
|
| Not to mention the lack of `rebase -i` to clean up local
| commits.
|
| [1]: https://www.fossil-scm.org/fossil/help?cmd=commit [2]:
| https://www.fossil-scm.org/fossil/help?cmd=stash
| rstupek wrote:
| It would seem the authors consider rebase harmful:
| https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
| aidenn0 wrote:
| Contrary to that article, squashing _aids_ bisection rather
| than hurts it.
|
| One simple example:
|
| commit 1: things work
|
| commit 2: Feature X, regress
|
| commit 4: Feature Y, break things by accident
|
| commit 5: oops, fix commit #4
|
| ...
|
| You land on commit 4 breaking your commit, but if #5 and #4
| had been squashed then you would find commit #3 much more
| easily.
|
| With a tiny history like this it's not a big deal, but with
| a larger one, it becomes an issue.
| progval wrote:
| On personal projects (using git), I use squashing only
| for small bug fixes like the one you mentioned or when
| the author of a PR made a big mess of commits (usually
| because they are a git beginner). Best of both worlds.
| Arnavion wrote:
| (Holy shit I didn't realize how long this had gotten.)
|
| I read that page. It's their opinion and I disagree with
| it.
|
| To be clear of where I'm coming from, I've never used
| fossil, and I've used git regularly for about 10 years. I
| only use git from the commandline except that I often use
| `gitk` to read a branch's commit history or inspect diffs,
| and I use `kdiff3` for interactive merging when there are
| conflicts. I actively disable git "integrations" in editors
| and IDEs.
|
| ---
|
| >1.0
|
| Whether other people struggle with rebase or not does not
| affect me, because I have no problems using it. (This logic
| also extends to people who complain the entire git CLI is
| hard to use.)
|
| Now, this might sound like the seasoned C programmer saying
| "Other people accidentally write UB but I don't, so C is
| perfectly fine." but there is a difference. UB with C is
| problematic because it's hard to know it happened, which is
| why we know the seasoned C programmer might have
| unknowingly written UB after all. This is not the case with
| `git rebase` though. Either you do it correctly or you
| don't, and I can confidently say I do it correctly.
|
| >2.1
|
| This is specifically talking about rebases that move
| commits onto new parents. Rebase does much more than that.
| For this particular use case, I agree that some projects
| even when using git prefer to have merge commits instead of
| rebased commits, and that's fine. But for projects that do
| want a linear series of commits, it's good to have the
| choice. Rebased commits also make it easier to revert just
| a single commit instead of the whole merge (though of
| course it's not impossible to revert a single commit of a
| merged branch either).
|
| >2.2
|
| This whole section is a non-sequitur because indeed the
| correct pre-rebase diff would indeed be diff(C2, C5) even
| in the git case. But if you're planning to rebase the code
| in order to merge it, you need to rebase the code to know
| what the diff will be.
|
| >3.0
|
| The Windows Vista citation starts off with the (correct)
| result that lack of communication between engineers of
| disparate components leads to bugs, but then associates it
| to mean that these disparate components were being
| developed in private branches. The cited paper does not
| talk about branches at all. Indeed, bugs happening because
| of private branches was not the case then, and is not the
| case now. The reason those bugs happen is because the
| engineers of a particular component only work with code of
| their component.
|
| The "egoless" citation is from a book, so I can't tell if
| the book specifically says private branches have anything
| to do with ego or not.
|
| At any rate, this section is fundamentally confused. Making
| branches public doesn't mean you can't rebase them. If I
| work on an OSS github project, I would certainly make my
| WIP code branch public. That doesn't mean I don't want to
| rebase it right before I send a PR to clean the cruft up.
|
| I think the article author may have read the git advice
| about not rebasing public branches and thought it meant all
| non-private branches. It actually means branches other
| people would want to pull from you and who are not
| expecting it to be rebased. Single-person development
| happens in branches only that single person cares about, so
| whether the branches are private or public makes no
| difference to that person wanting to be able to rebase
| them. If a group of people are collaborating and they agree
| that rebases are going to happen, nothing is wrong with
| letting them do that. The only problem is with rebasing
| public branches that people pull from and which those
| people do not expect to be rebased, like a public repo's
| `master`.
|
| >4.0
|
| So test each commit then. git doesn't makes it impossible
| to do that or anything. If anything, ensuring tests pass on
| each intermediate commit makes `bisect`ing easier in the
| future.
|
| Also, only using merges means the only tested commit is the
| merge commit, so you lose the ability to check which commit
| in the merged branch caused the problem.
|
| See also 7.0
|
| >5.0
|
| `git rebase --ignore-date` will reset the commit date of
| each rebased commit to the current time.
|
| >6.0
|
| It is correct that commit messages are the only way to
| associate some of the metadata that Fossil lets you
| manipulate separately. So (2) and (3) do benefit from
| Fossil's approach.
|
| (1) and especially (5) happens rarely enough in my
| experience that it isn't enough justification.
|
| I'm not sure what (4) is referring to by "routine display",
| but in general the only branches things like `gitk` will
| show you are the ones you ask for.
|
| >7.0
|
| It also throws away non-valuable garbage. When I'm
| bisecting a bug, or running a `blame` to figure out what
| commit added a particular line, I don't need to go through
| half-commits that got reverted afterwards.
|
| False starts and incorrect approaches can be documented in
| the commit message or in the code comments.
|
| Also this directly contradicts 4.0 unless we are to assume
| that only merge commits get tested, and that the user
| running `blame` does not go deeper than the merge that
| introduced the line, which has the problem I mentioned in
| 4.0
|
| >7.1
|
| This section is just a longer reiteration of 7.0, so it has
| the same rebuttal.
|
| >7.2
|
| This has switched to specifically talking about squash
| rebases, which is not necessarily the only kind of rebase
| (and is also not the kind of rebase that the diagram in 2.2
| was talking about). I also dislike squashed rebases when
| merging pulls. But if I have to squash two commits in my
| WIP branch I absolutely want to be able to.
|
| >7.3
|
| If the checkins are being rebased and are going to be
| merged without squashing, then each commit has to stand on
| its own by definition, so of course they should all have
| individual justifications.
|
| >7.4, 7.5
|
| These are the same as 7.2 and 8.0 below.
|
| >8.0
|
| This appears to be saying that fossil's cherry-pick is not
| just a wrapper around rebase like git's is. So I agree that
| (1) and (4) are benefits due to Fossil's approach.
|
| (2) is exactly the same as 4.0
|
| I don't understand what (3) is trying to say.
| mikepurvis wrote:
| I'm sympathetic to a lot of what they have to say, but this
| has always been a sticking point for me:
|
| > Cherry-picks work better with small check-ins
|
| Maybe it's just bad git tooling or me using the tools
| wrong, but if I need to cherry-pick and there are
| conflicts, it is always way easier to squash everything
| down and pick it in one go-- if I don't do that, I end up
| resolving the same conflict over and over as new commits
| pile in on top of it and meet a conflict-resolved state
| that they then have a further conflict with.
| samatman wrote:
| The author of pijul is of the opinion that cherry-picks
| only work in accordance with the developer's mental
| model, if the VCS is based on patches.
|
| I've been persuaded by his argument, and I'm really
| looking forward to the pijul rewrite landing, so I can
| play around with it again.
| aidenn0 wrote:
| I don't cherry-pick much in git, but I'm guesing rerere
| doesn't work with it?
| dognotdog wrote:
| I'm a big fan of Fossil, but I've sadly not used it in a while
| for new projects, as when stuff has to go on gitlab or github it
| is just too inconvenient.
|
| Even though one-way pushes to github/gitlab via --fast-export /
| --fast-import are relatively painless, going the other way for
| contributions is still not easy because of rebase issues, etc, at
| least to my knowledge.
| marmaduke wrote:
| I wanted to use Fossil but the division between what you do in
| CLI and what you do in the web UI was too arbitrary. I wanted to
| edit the wiki in vim, for example. Now I don't care anymore and
| just use Git and GitHub
| gw wrote:
| Yeah it's a bit bifurcated. Internally there's a lot of
| coupling -- HTML embedded directly in the C code and whatnot.
| This could be resolved if tools could be built on top of
| fossil, but the CLI code uses `exit` everywhere which makes it
| impossible to use as a library. I think they made an incomplete
| attempt at a JSON API, but what you really need is a proper
| linkable library like libgit2.
| bachmeier wrote:
| Maybe I'm not understanding, but it's pretty easy to edit the
| wiki from the command line in vim (I've used text editors for
| it before).
|
| https://fossil-scm.org/home/help?cmd=wiki
|
| To edit a page, do an export and then a commit when you're
| done. It was easy enough to add this as a menu item in Emacs.
|
| fossil wiki export foo.wiki foo.md
|
| fossil wiki commit foo.wiki foo.md
| samatman wrote:
| I have great fondness for Fossil, used it a couple of times and
| wish it were possible to keep using it.
|
| I tried to rally some interest on the mailing list behind
| separating the working parts from the UI chrome into a
| 'libfossil', which could be integrated into other programs. The
| verdict was that D. Richard Hipp doesn't really want to, since
| it's a classic C monolith where the allocation strategy doesn't
| make that separation easy. Someone started the job, but had to
| abandon it due to RSI issues.
|
| I still kinda hope someone bites the bullet, because a "libsqlite
| for versioning" would be a real boon for application developers.
| Even for fossil's central use case as a code VCS, the monolithic
| bundling of everything into one program is a mixed bag.
| michaelmure wrote:
| If you like this idea of embedding a bug-tracker (and eventually
| the code review) within a DVCS, I'm working on a project[1] that
| does that for git.
|
| [1]: https://github.com/MichaelMure/git-bug
| [deleted]
| dfischer wrote:
| Can anyone give a conceptual model breakdown of the data model of
| fossil vs git and trade offs? I've been quite interested in these
| types of structures. I need to play more with them.
| cbsks wrote:
| These web pages give a good broad overview of Git vs Fossil.
| They don't go into much detail about the internals, however.
|
| Fossil Versus Git: https://fossil-
| scm.org/fossil/doc/trunk/www/fossil-v-git.wik...
|
| Why SQLite Does Not Use Git: https://sqlite.org/whynotgit.html
|
| Hints For Users With Prior Git Experience: https://fossil-
| scm.org/home/doc/trunk/www/gitusers.md
| aidenn0 wrote:
| The first item on "why sqlite does not use git" asking for a
| timeline view. That looks almost exactly what "gitk" shows,
| which was builtin to git before github or gitlab existed.
|
| A quick scan of the other items are all more-or-less true so
| it's a shame it leads with that.
| rstupek wrote:
| Didn't the author address that by stating "people install
| graphical viewers to get around this" and that this is not
| built into default git?
| aidenn0 wrote:
| No because it's built into default git.
| sigzero wrote:
| Gitea falls into a similar category
|
| [1]: https://gitea.io
| ComputerGuru wrote:
| No, it really doesn't. Gitea is just your typical web stack
| built around forking git.exe processes.
| bachmeier wrote:
| Aside from standard version control uses, I eventually realized
| that the tickets database is just a regular sqlite database that
| lets you edit the schema and query any way you like. What's
| really cool is that it's version controlled. You can put any
| information you want into the tickets database and then pull
| changes like any other repo. You can view the timeline to see all
| the changes you've made to the database over time.
___________________________________________________________________
(page generated 2020-09-30 23:01 UTC)