5 ms·

> Git is a complex tool because it’s tackling a complex problem. Fossil tackles much the same sort of problem, yet it's far simpler to use. Most of Git's prob

> Git is a complex tool because it’s tackling a complex problem. Fossil tackles much the same sort of problem, yet it's far simpler to use. Most of Git's problems are due to purposeful choices, but they're design choices, not inherent aspects of how a DVCS must behave. We've laid out our case for the differences here: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

munmaek 7y ago
> their thing: Sprawling, incoherent, and inefficient > our thing: Self-contained and efficient This is not biased in any way and makes me want to continue reading. /s Also, you can’t claim something to be “efficient” when it’s doing many different things like scm, issues/tickets, a web forum/ui .... Then you have non-issues like git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). And then you take Gitlab and conflate Gitlab’s issues with problems with Git. I guess gogs/gitea don’t exist? This page needs to be rewritten to simply list the differences in neutral language. There are good points but they’re lost in unnecessary epithets like “caused untold grief for git users”. I get it: git bad, our product good. Switch! — Personally, I don’t want something that tries to do many different things all at once.
- wyoung2 7y ago
  > This is not biased in any way Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top. Here's the direct link for that particular point: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki#efficient https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik... Now, if you want to debate section 2.2 on its merits, we can get into that. > you can’t claim something to be “efficient” when it’s doing many different things We can when all of that is in a single binary that's 4.4 MiB, as mine here is. A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient." But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading. > git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there. On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself. If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.) > This page needs to be rewritten to simply list the differences in neutral language. We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it. > unnecessary epithets like “caused untold grief for git users” You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language. > I don’t want something that tries to do many different things all at once. Not a GitHub user, then?
Frondo 7y ago
Hey, are you a fossil dev? I haven't used nor looked at fossil in maybe 5 years, but had a couple of questions. Does fossil now have any kind of email support built in to the ticket manager? I remember when I tried to use fossil for actual production use, there was no way to trigger emails sent when, e.g. tickets were submitted, and one of the devs said to just write a script to monitor the fossil rss feed and send the appropriate email, which seemed like a baroque and fragile (and time-consuming) solution. And is any more of the command-line behavior configurable (like the mv/rm behavior -- affecting the file on disk as well as the repository, or just marking the file as (re)moved in the repository)?
- wyoung2 7y ago
  > Hey, are you a fossil dev? I have commit access, yes, but mainly I work on the docs. > Does fossil now have any kind of email support built in to the ticket manager? Yes. It was added in support of the forum feature last year, but it also applies to several other event types: https://fossil-scm.org/fossil/doc/trunk/www/alerts.md https://fossil-scm.org/fossil/doc/trunk/www/alerts.md > one of the devs said to just write a script to monitor the fossil rss feed Probably me. :) > seemed like a baroque and fragile (and time-consuming) solution. A dozen lines of Perl; easy-peasy. That and a pile of CPAN modules, but that's easily fetched with `cpanm`. > the mv/rm behavior -- affecting the file on disk as well as the repository The default you're referring to was changed a few years ago: the old `--hard` option is now the default.
jnurmine 7y ago
By the way, the "one checkout per repository" is not strictly true. You can use "git worktree"; this is a lightweight way to reuse an existing git repository and have each worktree use a different branch. It's a nice feature, and I use it daily. Also, a comment about the argumentation in "test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow. Certainly, one can push untested stuff to the remote server by mistake; but, even so, this should be OK, because if one can push directly to important branches like master or similar without going through any reviews and other sanity checks, one has a problem... and the problem isn't really Git :)
- wyoung2 7y ago
  > By the way, the "one checkout per repository" is not strictly true. You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git. I suspect this is because git-worktree is a relatively recent feature of Git (2.5?) so most tutorials aren't written to assume use of it, so most tools don't focus on making it work well, so bugs and weaknesses with it don't get addressed. Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place. > test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow. That just brings you back to the problems you buy when separating commit from push, which we cover elsewhere in that doc, primarily here: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki#devorg https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...
  - jnurmine 7y ago
    > You must be referring to just the table at the top, not to the detailed argument below Well, not entirely, because in my opinion the detailed argument kind of hand-waves away the entire git worktree. Continuously switching branches inside a single large Git repo is certainly a suboptimal way to work with Git, but most of the time one should be able to avoid that with the worktree (though the worktree stuff is, of course, not a miracle cure for everything).

munmaek 7y ago

> their thing: Sprawling, incoherent, and inefficient > our thing: Self-contained and efficient This is not biased in any way and makes me want to continue reading. /s Also, you can’t claim something to be “efficient” when it’s doing many different things like scm, issues/tickets, a web forum/ui .... Then you have non-issues like git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). And then you take Gitlab and conflate Gitlab’s issues with problems with Git. I guess gogs/gitea don’t exist? This page needs to be rewritten to simply list the differences in neutral language. There are good points but they’re lost in unnecessary epithets like “caused untold grief for git users”. I get it: git bad, our product good. Switch! — Personally, I don’t want something that tries to do many different things all at once.

wyoung2 7y ago
> This is not biased in any way Of course we're biased, but every row in that table corresponds to a section below where we lay out our argument for the few words up in the table at the top. Here's the direct link for that particular point: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki#efficient https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik... Now, if you want to debate section 2.2 on its merits, we can get into that. > you can’t claim something to be “efficient” when it’s doing many different things We can when all of that is in a single binary that's 4.4 MiB, as mine here is. A Git installation is much larger, particularly if you count its external dependencies, yet it does less. That's what we mean when we say Git is "inefficient." But I don't really want to re-hash the argument here. We laid it out for you already, past the point where you stopped reading. > git being installed via a package manager instead of dragging and dropping a binary. Yeah, this is such a huge problem that concerns people, better switch to Better Project (tm). It is on Windows, where they had to package 44-ish megs of stuff in order to get Git to run there. On POSIX platforms, the package manager isn't much help when you want to run your DVCS server in a chroot or jail. The more dependencies there are, the more you have to manually package up yourself. If your answer to that is "just" install a Docker container or whatever, you're kind of missing the original point. `/home/repo/bin/fossil` chroots itself and is self-contained within that container. (Modulo a few minor platform details like /dev/null and /dev/urandom.) > This page needs to be rewritten to simply list the differences in neutral language. We accept patches, and we have an active discussion forum. Propose alternate language, and we'll consider it. > unnecessary epithets like “caused untold grief for git users” You don't have to go searching very hard to find those stories of woe. They're so common XKCD has satirized them. We think the characterizations are justified, but again, if you think they're an over-reach, propose alternate language. > I don’t want something that tries to do many different things all at once. Not a GitHub user, then?

Frondo 7y ago

Hey, are you a fossil dev? I haven't used nor looked at fossil in maybe 5 years, but had a couple of questions. Does fossil now have any kind of email support built in to the ticket manager? I remember when I tried to use fossil for actual production use, there was no way to trigger emails sent when, e.g. tickets were submitted, and one of the devs said to just write a script to monitor the fossil rss feed and send the appropriate email, which seemed like a baroque and fragile (and time-consuming) solution. And is any more of the command-line behavior configurable (like the mv/rm behavior -- affecting the file on disk as well as the repository, or just marking the file as (re)moved in the repository)?

wyoung2 7y ago
> Hey, are you a fossil dev? I have commit access, yes, but mainly I work on the docs. > Does fossil now have any kind of email support built in to the ticket manager? Yes. It was added in support of the forum feature last year, but it also applies to several other event types: https://fossil-scm.org/fossil/doc/trunk/www/alerts.md https://fossil-scm.org/fossil/doc/trunk/www/alerts.md > one of the devs said to just write a script to monitor the fossil rss feed Probably me. :) > seemed like a baroque and fragile (and time-consuming) solution. A dozen lines of Perl; easy-peasy. That and a pile of CPAN modules, but that's easily fetched with `cpanm`. > the mv/rm behavior -- affecting the file on disk as well as the repository The default you're referring to was changed a few years ago: the old `--hard` option is now the default.

jnurmine 7y ago

By the way, the "one checkout per repository" is not strictly true. You can use "git worktree"; this is a lightweight way to reuse an existing git repository and have each worktree use a different branch. It's a nice feature, and I use it daily. Also, a comment about the argumentation in "test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow. Certainly, one can push untested stuff to the remote server by mistake; but, even so, this should be OK, because if one can push directly to important branches like master or similar without going through any reviews and other sanity checks, one has a problem... and the problem isn't really Git :)

wyoung2 7y ago
> By the way, the "one checkout per repository" is not strictly true. You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git. I suspect this is because git-worktree is a relatively recent feature of Git (2.5?) so most tutorials aren't written to assume use of it, so most tools don't focus on making it work well, so bugs and weaknesses with it don't get addressed. Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place. > test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relation is in a sane workflow. That just brings you back to the problems you buy when separating commit from push, which we cover elsewhere in that doc, primarily here: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki#devorg https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...
- jnurmine 7y ago
  > You must be referring to just the table at the top, not to the detailed argument below Well, not entirely, because in my opinion the detailed argument kind of hand-waves away the entire git worktree. Continuously switching branches inside a single large Git repo is certainly a suboptimal way to work with Git, but most of the time one should be able to avoid that with the worktree (though the worktree stuff is, of course, not a miracle cure for everything).