15 ms·

SQLite Doesn't Use Git

181 points by bkq 4y ago

donatj 4y ago
> I still believe that a squash+merge (or sometimes, rebase) workflow pairs better with pull requests Unpopular opinion, but I find the value of having the actual surrounding context in which the code was developed more valuable than having a flat history.
- discussDev 4y ago
  I'm not sure this is too unpopular. In our groups not rebasing seems to be winning.
  - deleted 4y ago
    [deleted]
- cube00 4y ago
  It depends on that context, if they're the end of day "work in progress" or "typo" commits, I don't see the value in retaining those. A non-linear commit history is much more difficult to run a bisect on which was enough to sell linear for me.
  - donatj 4y ago
    The bisect might be easier to do, but it's vastly less useful if you're looking for why and not what since the commits are not actually the authors originals and the state of the project you find is not the state the author authored them within.
    - cube00 4y ago
      For us only the original authors squash and tidy up their own commits so they can add as much context as they want. That's not to say each PR is one commit, if there are multiple distinct parts of a PR that could be cherry picked in a way that they make sense on their own they'd still be separate commits.
      - Izkata 4y ago
        > That's not to say each PR is one commit This thread is about squash merge, which converts the whole branch into a single commit.
  - mildred593 4y ago
    typo commits might be really useful, especially if you can bisect a bug from one of those commits. it happened to me.
  - WorldMaker 4y ago
    `git bisect --first-parent` is just as easy as a bisect on linear history. (It just follows the "linear" line down merge commits via their first parent, which by convention should be their "base" parent.) Plus it gives you the option to bisect "inside" a branch if you need to inspect something "low level" once you've narrowed down the "branch" based on merge commit. I think if `--first-parent` were the default to git bisect a lot more people would care a lot less about "linear commit history". But it is still an easy flag to apply yourself.
- beermonster 4y ago
  > I find the value of having the actual surrounding context in which the code was developed more valuable But only if those commits are real atomic changes of code which compiles and not a series of 'oops', 'tests pass once again!' , 'forgot to commit this file' type inner-monologue type history. And then there are shops where less technical authors are contributing solely via the GitHub WebUI. So you get a commits of the ilk 'Updated <Filename>' or ''Files added via upload'.
72deluxe 4y ago
I use Fossil at home since it's just me. The single file approach takes up less space than the comparable git tree. Fossil has the ability to push to git, which I do periodically just for curiosity.
- teknolog 4y ago
  Your dev environment is so resource constrained that the size of the repo is a factor?
  - bayindirh 4y ago
    Some of us likes to optimize for footprint, and that's OK. I run an OrangePi Zero with 512MB of RAM as a home server since it both works and is a fun experience.
  - samatman 4y ago
    There are a lot of things which make Fossil attractive for solo and small developers. An example would be the excellent diffing tools accessible through localhost, as well as things like issue tracking, which git doesn't understand as a concept. There were some deal-breakers for me (kind of esoteric) and I switched back to git, but not without some annoyance.
    - afiori 4y ago
      The web interface is one of the main benefits in my opinion, especially if you develop on wsl2, on a server, or inside a container.
  - riskable 4y ago
    On Windows git performance isn't the greatest due to the sheer number of tiny little files (NTFS is absolutely awful). If you have a lot of small commits the number of tiny files grows and grows and grows and git can feel really slow compared to something like fossil. Especially if you're regularly copying your repo from one filesystem/machine to the next (without compressing it into something like a .zip first).
hprotagonist 4y ago
I’d use fossil more for personal work if i wasn’t hopelessly addicted to magit.
- w0m 4y ago
  I feel like the (outside-in) discussions of magit/orgmode are a stealth campaign for emacs adoption. Whenever I experiment with a vim/neovim migration it always seems... underwhelming, and I chalk it up to 'bad port'.
  - hprotagonist 4y ago
    pretty much :) there are lots of people who use emacs for those two things and other editors/ides for other things. i use emacs for more than the two, but certainly not for everything.
sshine 4y ago
SQLite also doesn't use CVS, SVN, or Perforce. If this title were "SQLite uses Fossil", it'd be more apparently just another ad for Fossil.
- bayindirh 4y ago
  The author likes to have this slightly edgy tone, as far as I understood by reading a couple of his posts. He likes to "engage" his audience in a way.
  - rat9988 4y ago
    Which is not something I hold in high regard.
    - bayindirh 4y ago
      I personally don't like this style of writing and/or discussions either, but wanted to point the fact in most neutral way I can manage. From my observations, some people think that they can extract more arguments or have a more fruitful discussion by being slightly spiky like that. I do not share this view.
- citrin_ru 4y ago
  There is an element of click bait but for many young developers Git is the only VCS they ever knew so Git in the title would give more hints about the article content.
  - account-5 4y ago
    Also because of the mention of "fossil" would have meant nothing to these young developers. The use of "git" immediately brings to mind version control and the question: what does sqlite use then?
  - oneplane 4y ago
    On the other hand, the internet isn't just for young developers, and even if there are a billion other VCS options to pick from, the ones with the most traction are the most relevant. If you put "I can do Fossil and Subversion" on your CV but everyone is hiring for Git, you're not a great match.
samatman 4y ago
Author confuses SQLite's development model with Fossil's at the end, the latter welcomes contributions: https://www.fossil-scm.org/home/doc/trunk/www/contribute.wiki https://www.fossil-scm.org/home/doc/trunk/www/contribute.wik...
- pxeger1 4y ago
  I think it's just ambiguously written. The way I first read it, I thought the author was indeed referring to SQLite.
ddevault 4y ago
Important note mentioned here is that sqlite doesn't accept external contributions and has a very small team. The Fossil folks and the sqlite folks are also essentially the same team. Fossil is a boutique VCS which essentially only exists for sqlite.
- gwd 4y ago
  ...and that also has certain consequences for Fossil's design and workflow; namely, an aversion to the "rebase"-style development [1]. A project with a handful of known contributors could reasonably use Fossil; for a project with dozens of contributors, which also wanted to be able to accept "drive-by" contributions, Fossil would be unworkable. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
  - sigzero 4y ago
    Exactly. The Tcl Core Team (TCT) uses Fossil.
int_19h 4y ago
I really like the notion of having the whole repo including issue tracking in a single file that can be easily copied around. But Fossil's stance on history - specifically, the deliberate refusal to implement history-editing functionality like squash and rebase - is a showstopper, and their rationale for it reads very much along the lines of "you're holding it wrong".
- ARandomerDude 4y ago
  Apparently it does support squashing. > Fossil does not support rebase. Here's an article from the author titled, Rebase Considered Harmful. While Fossil has the ability to squash merges, the primary workflow supported is merging.
  - masukomi 4y ago
    Rebase Considered Harmful article is here: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
    - simiones 4y ago
      In my opinion, the worse part of the article is that it only shows the simple cases of feature branch history. In particular, they show the following comparison: Merge: -> C3 -> C5 -> C7 / / C1 -> C2 -> C4 -> C6 Rebase: -> C3 -> C5] -> C3' -> C5' / / C1 -> C2 -> C4 -> C6 However, a more realistic example of a feature branch that lives for even a few days looks like this: Merge: -> C3 -> C5 -> C7 -> C9 -> C11 -> C13 --------> C15 / / / / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 -> C18 The final history after rebase being: -> C3' -> C5' -> C9' -> C13' / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 --------------------------> C18 A much much simpler history to follow, and obviously shorter. And the complexity without rebase grows even more if more people are doing local merges and pushing to the same remote branch.
benreesman 4y ago
The SQLite people not using git or hg is like the Bell Labs people and three-button-mouse heavy sam/acme: when you’re right about everything 99/100 times, that 100th time you’re really going to double down on some dumb-ass thing. In what possible world is telling the most successful set of design decisions about document management in the history of documents or management to get fucked not just “I’ve got goodwill to burn, let’s ride.”? SQLite is indeed badass, but cool it djb, I’m already stressing about the zero bugs ever thing.
- HelloNurse 4y ago
  Do you know SQLite is a few years older than Git?
  - benreesman 4y ago
    Indeed. I started paying serious attention to SQL in 1994 once I had read Stroustrup so many times I could recite it aloud, when did you get into databases? Edit: I’d like to apologize for mouthing off like that. I’ve earned some amount of cranky old-timer cred, but not enough to just be a dick, which that was.
- moeris 4y ago
  > three-button-mouse heavy sam/acme Acme is great. I haven't been able to find another editor that integrates as tightly with the operating system. The closest I've gotten is Kakoune. And I wish mouse chording were a thing more generally. If we're going to use mice, we should optimize their utility.
  - benreesman 4y ago
    https://www.nbcnews.com/technolog/how-fast-fast-some-pro-gamers-make-10-moves-second-8c11422946 https://www.nbcnews.com/technolog/how-fast-fast-some-pro-gam... claims that effective APM can hit 600, that sounds high to me but not by a lot. 10hz on the keyboard is probably not a realistic sustained rate for a hardcore vi/emacs user. I easily hit 4hz at the end of a 20 hour coding bender, and I’m old: the hot shit kids on modafinil must be doing 1.5x my decrepit ass. If you can really move on the keyboard? Touch the mouse? I’ll grab a coffee while I’m at it. Edit: It turns out that “fast emacs” doesn’t turn up a video of a real pro easily on Google. You can see a code God like Russ Cox being slow and clumsy as fuck if you want: https://youtu.be/dP1xVpMPn8M https://youtu.be/dP1xVpMPn8M. It’s a good thing thing he gets everything right on the first try (not sarcasm, Cox is an alien life form optimized for doing the impossible) because if he didn’t he’d finish pound-defining everything by about next March.
headsup2022 4y ago
The single file repository is super convenient for one person projects, but just a word of caution to fossil users - backup the repo file often. A while back I downgraded the fossil binary (by accident) and committed a change to a local repo which caused it to be corrupted. It was a repeatable thing, and was annoying at the time, but not a showstopper. I only lost a day's worth of work. I wish fossil had done a version check between the binary and the repo to refuse to alter the repo if the binary version was incompatible.
RockingGoodNite 4y ago
The sound of it from the article reminds me some of https://trac.edgewall.org/ https://trac.edgewall.org/
gwbas1c 4y ago
Anyone use Fossil for professional / team development? I'd love to hear some real-world experiences.
- indymike 4y ago
  I use it for payment MSP software (Python based) that I license to a couple of companies. I'm a mostly solo on this project, and switched off Github and git about two years ago. I prefer prefer a "merge only, if possible, please" workflow in git, so fossil was pretty easy. Fossil does not have ubiquitous ide support like Git does, so if you are an IDE lover, it may not fit well. Also, for solo use autosync is nice - commits are automatically pushed. Like SQLite, Fossil is very nice software.
vouaobrasil 4y ago
To be honest, I hate Git. The commands don't really make sense outside some basic stuff. For certain organizational setups it seems like overkill. I am not a full-time programmer but I do programming for my job and for personal projects sometimes and I never enjoy using Git.
- BowBun 4y ago
  It's not intuitive, but it's an amazing tool that has stood the test of time for decades. I used to struggle with Git, but after putting in a little extra time and studying it more, now I feel like it's a crucial tool in my toolbox and I can use it for much more than _just_ storing my code. Git helps me understand what my colleagues wrote, gives me incredible control over breaking my work apart, and gives me tools to troubleshoot issues (bisect).
  - cholantesh 4y ago
    I keep hearing that Mercurial does all of this and is more ergonomic, which begs the question as to why it never captured mindshare the way git did.
    - yjftsjthsd-h 4y ago
      > why it never captured mindshare the way git did. If nothing else, network effects. Linux uses git, github is popular.
    - asciimov 4y ago
      Git is part of the official doctrine of the Cult of Torvalds, anything else is heresy.
    - seabrookmx 4y ago
      How much it matters for the average repo is debatable, but git is considerably faster than hg.
  - simiones 4y ago
    After moving to Git from Perforce for ~5 years now, I still miss P4V's Timeline view so much when trying to understand when and why some code changes happened. It's like a kind of blame + log in a single UI, in Git terms, and is just wonderful for quickly moving through the entire history of a file.
masukomi 4y ago
Richard Hipp (SQLite guy) spoke about the thinking behind writing Fossil instead of using Git on Corecursive episode 66. If i remember correctly, it wasn't that they had any real problem with git, but that git didn't really fit with how they wanted to work, so they created their own thing. https://corecursive.com/066-sqlite-with-richard-hipp/ https://corecursive.com/066-sqlite-with-richard-hipp/
2143 4y ago
Fun fact: Fossil uses sqlite. And sqlite uses fossil. Think about that. SQLite is what I consider a well-engineered product. And Richard Hipp is an excellent engineer. Listen to his podcast episodes on the changelog. It's fun. His mentality is interesting. https://changelog.com/person/drh/podcasts#feed https://changelog.com/person/drh/podcasts#feed
- vitiral 4y ago
  It has bootstrapped it's VCS!
adaga 4y ago
Alt title - SQLite doesn't Git it Great read :D
dier 4y ago
With regard to rebase and fossil vs git when you have a small team of trusted developers rebase is harmful because you lose information that could help you understand the _why_ of something. In contrast if you are working with thousands of untrusted developers you need a way to increase the signal-to-noise at the cost of some granularity. This comes about from their development styles (see: http://www.catb.org/~esr/writings/cathedral-bazaar/ http://www.catb.org/~esr/writings/cathedral-bazaar/). - Use fossil if you prefer the cathedral style of development SQLite is open source but does not accept contributions. - Use Git if you prefer the bazaar style of development. You want to accept hit-and-run style contributions from anyone.
- cwilkes 4y ago
  I don’t understand the dislike of rebase — do you want hundreds of commits that say “linter fix” and “reformatting”? If there’s commits like “fixed off by one issue in refactor” then it should be a comment in the code so that future will explorers won’t make the same mistake. Rebase by itself isn’t bad, it just has to contain a good description of what was done and why. Edit: after posting I realize that I confounded rebase and squash — which is kind of ingrained in my head as that’s how I use GitHub to merge PRs.
  - Double_a_92 4y ago
    They are better than one single commit with 100s of changed files. Especially when you are debugging things and want to know why exactly some line was changed in that way and by whom.

181 points by bkq 4y ago

> I still believe that a squash+merge (or sometimes, rebase) workflow pairs better with pull requests Unpopular opinion, but I find the value of having the actual surrounding context in which the code was developed more valuable than having a flat history.

discussDev 4y ago
I'm not sure this is too unpopular. In our groups not rebasing seems to be winning.
- deleted 4y ago
  [deleted]
cube00 4y ago
It depends on that context, if they're the end of day "work in progress" or "typo" commits, I don't see the value in retaining those. A non-linear commit history is much more difficult to run a bisect on which was enough to sell linear for me.
- donatj 4y ago
  The bisect might be easier to do, but it's vastly less useful if you're looking for why and not what since the commits are not actually the authors originals and the state of the project you find is not the state the author authored them within.
  - cube00 4y ago
    For us only the original authors squash and tidy up their own commits so they can add as much context as they want. That's not to say each PR is one commit, if there are multiple distinct parts of a PR that could be cherry picked in a way that they make sense on their own they'd still be separate commits.
    - Izkata 4y ago
      > That's not to say each PR is one commit This thread is about squash merge, which converts the whole branch into a single commit.
- mildred593 4y ago
  typo commits might be really useful, especially if you can bisect a bug from one of those commits. it happened to me.
- WorldMaker 4y ago
  `git bisect --first-parent` is just as easy as a bisect on linear history. (It just follows the "linear" line down merge commits via their first parent, which by convention should be their "base" parent.) Plus it gives you the option to bisect "inside" a branch if you need to inspect something "low level" once you've narrowed down the "branch" based on merge commit. I think if `--first-parent` were the default to git bisect a lot more people would care a lot less about "linear commit history". But it is still an easy flag to apply yourself.
beermonster 4y ago
> I find the value of having the actual surrounding context in which the code was developed more valuable But only if those commits are real atomic changes of code which compiles and not a series of 'oops', 'tests pass once again!' , 'forgot to commit this file' type inner-monologue type history. And then there are shops where less technical authors are contributing solely via the GitHub WebUI. So you get a commits of the ilk 'Updated <Filename>' or ''Files added via upload'.

72deluxe 4y ago

I use Fossil at home since it's just me. The single file approach takes up less space than the comparable git tree. Fossil has the ability to push to git, which I do periodically just for curiosity.

teknolog 4y ago
Your dev environment is so resource constrained that the size of the repo is a factor?
- bayindirh 4y ago
  Some of us likes to optimize for footprint, and that's OK. I run an OrangePi Zero with 512MB of RAM as a home server since it both works and is a fun experience.
- samatman 4y ago
  There are a lot of things which make Fossil attractive for solo and small developers. An example would be the excellent diffing tools accessible through localhost, as well as things like issue tracking, which git doesn't understand as a concept. There were some deal-breakers for me (kind of esoteric) and I switched back to git, but not without some annoyance.
  - afiori 4y ago
    The web interface is one of the main benefits in my opinion, especially if you develop on wsl2, on a server, or inside a container.
- riskable 4y ago
  On Windows git performance isn't the greatest due to the sheer number of tiny little files (NTFS is absolutely awful). If you have a lot of small commits the number of tiny files grows and grows and grows and git can feel really slow compared to something like fossil. Especially if you're regularly copying your repo from one filesystem/machine to the next (without compressing it into something like a .zip first).

hprotagonist 4y ago

I’d use fossil more for personal work if i wasn’t hopelessly addicted to magit.

w0m 4y ago
I feel like the (outside-in) discussions of magit/orgmode are a stealth campaign for emacs adoption. Whenever I experiment with a vim/neovim migration it always seems... underwhelming, and I chalk it up to 'bad port'.
- hprotagonist 4y ago
  pretty much :) there are lots of people who use emacs for those two things and other editors/ides for other things. i use emacs for more than the two, but certainly not for everything.

sshine 4y ago

SQLite also doesn't use CVS, SVN, or Perforce. If this title were "SQLite uses Fossil", it'd be more apparently just another ad for Fossil.

bayindirh 4y ago
The author likes to have this slightly edgy tone, as far as I understood by reading a couple of his posts. He likes to "engage" his audience in a way.
- rat9988 4y ago
  Which is not something I hold in high regard.
  - bayindirh 4y ago
    I personally don't like this style of writing and/or discussions either, but wanted to point the fact in most neutral way I can manage. From my observations, some people think that they can extract more arguments or have a more fruitful discussion by being slightly spiky like that. I do not share this view.
citrin_ru 4y ago
There is an element of click bait but for many young developers Git is the only VCS they ever knew so Git in the title would give more hints about the article content.
- account-5 4y ago
  Also because of the mention of "fossil" would have meant nothing to these young developers. The use of "git" immediately brings to mind version control and the question: what does sqlite use then?
- oneplane 4y ago
  On the other hand, the internet isn't just for young developers, and even if there are a billion other VCS options to pick from, the ones with the most traction are the most relevant. If you put "I can do Fossil and Subversion" on your CV but everyone is hiring for Git, you're not a great match.

samatman 4y ago

Author confuses SQLite's development model with Fossil's at the end, the latter welcomes contributions: https://www.fossil-scm.org/home/doc/trunk/www/contribute.wiki https://www.fossil-scm.org/home/doc/trunk/www/contribute.wik...

pxeger1 4y ago
I think it's just ambiguously written. The way I first read it, I thought the author was indeed referring to SQLite.

ddevault 4y ago

Important note mentioned here is that sqlite doesn't accept external contributions and has a very small team. The Fossil folks and the sqlite folks are also essentially the same team. Fossil is a boutique VCS which essentially only exists for sqlite.

gwd 4y ago
...and that also has certain consequences for Fossil's design and workflow; namely, an aversion to the "rebase"-style development [1]. A project with a handful of known contributors could reasonably use Fossil; for a project with dozens of contributors, which also wanted to be able to accept "drive-by" contributions, Fossil would be unworkable. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
- sigzero 4y ago
  Exactly. The Tcl Core Team (TCT) uses Fossil.

int_19h 4y ago

I really like the notion of having the whole repo including issue tracking in a single file that can be easily copied around. But Fossil's stance on history - specifically, the deliberate refusal to implement history-editing functionality like squash and rebase - is a showstopper, and their rationale for it reads very much along the lines of "you're holding it wrong".

ARandomerDude 4y ago
Apparently it does support squashing. > Fossil does not support rebase. Here's an article from the author titled, Rebase Considered Harmful. While Fossil has the ability to squash merges, the primary workflow supported is merging.
- masukomi 4y ago
  Rebase Considered Harmful article is here: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
  - simiones 4y ago
    In my opinion, the worse part of the article is that it only shows the simple cases of feature branch history. In particular, they show the following comparison: Merge: -> C3 -> C5 -> C7 / / C1 -> C2 -> C4 -> C6 Rebase: -> C3 -> C5] -> C3' -> C5' / / C1 -> C2 -> C4 -> C6 However, a more realistic example of a feature branch that lives for even a few days looks like this: Merge: -> C3 -> C5 -> C7 -> C9 -> C11 -> C13 --------> C15 / / / / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 -> C18 The final history after rebase being: -> C3' -> C5' -> C9' -> C13' / \ C1 -> C2 -> C4 -> C6 -> C8 -> C10 -> C12 -> C14 -> C16 -> C17 --------------------------> C18 A much much simpler history to follow, and obviously shorter. And the complexity without rebase grows even more if more people are doing local merges and pushing to the same remote branch.

benreesman 4y ago

The SQLite people not using git or hg is like the Bell Labs people and three-button-mouse heavy sam/acme: when you’re right about everything 99/100 times, that 100th time you’re really going to double down on some dumb-ass thing. In what possible world is telling the most successful set of design decisions about document management in the history of documents or management to get fucked not just “I’ve got goodwill to burn, let’s ride.”? SQLite is indeed badass, but cool it djb, I’m already stressing about the zero bugs ever thing.

HelloNurse 4y ago
Do you know SQLite is a few years older than Git?
- benreesman 4y ago
  Indeed. I started paying serious attention to SQL in 1994 once I had read Stroustrup so many times I could recite it aloud, when did you get into databases? Edit: I’d like to apologize for mouthing off like that. I’ve earned some amount of cranky old-timer cred, but not enough to just be a dick, which that was.
moeris 4y ago
> three-button-mouse heavy sam/acme Acme is great. I haven't been able to find another editor that integrates as tightly with the operating system. The closest I've gotten is Kakoune. And I wish mouse chording were a thing more generally. If we're going to use mice, we should optimize their utility.
- benreesman 4y ago
  https://www.nbcnews.com/technolog/how-fast-fast-some-pro-gamers-make-10-moves-second-8c11422946 https://www.nbcnews.com/technolog/how-fast-fast-some-pro-gam... claims that effective APM can hit 600, that sounds high to me but not by a lot. 10hz on the keyboard is probably not a realistic sustained rate for a hardcore vi/emacs user. I easily hit 4hz at the end of a 20 hour coding bender, and I’m old: the hot shit kids on modafinil must be doing 1.5x my decrepit ass. If you can really move on the keyboard? Touch the mouse? I’ll grab a coffee while I’m at it. Edit: It turns out that “fast emacs” doesn’t turn up a video of a real pro easily on Google. You can see a code God like Russ Cox being slow and clumsy as fuck if you want: https://youtu.be/dP1xVpMPn8M https://youtu.be/dP1xVpMPn8M. It’s a good thing thing he gets everything right on the first try (not sarcasm, Cox is an alien life form optimized for doing the impossible) because if he didn’t he’d finish pound-defining everything by about next March.

headsup2022 4y ago

The single file repository is super convenient for one person projects, but just a word of caution to fossil users - backup the repo file often. A while back I downgraded the fossil binary (by accident) and committed a change to a local repo which caused it to be corrupted. It was a repeatable thing, and was annoying at the time, but not a showstopper. I only lost a day's worth of work. I wish fossil had done a version check between the binary and the repo to refuse to alter the repo if the binary version was incompatible.

RockingGoodNite 4y ago

The sound of it from the article reminds me some of https://trac.edgewall.org/ https://trac.edgewall.org/

gwbas1c 4y ago

Anyone use Fossil for professional / team development? I'd love to hear some real-world experiences.

indymike 4y ago
I use it for payment MSP software (Python based) that I license to a couple of companies. I'm a mostly solo on this project, and switched off Github and git about two years ago. I prefer prefer a "merge only, if possible, please" workflow in git, so fossil was pretty easy. Fossil does not have ubiquitous ide support like Git does, so if you are an IDE lover, it may not fit well. Also, for solo use autosync is nice - commits are automatically pushed. Like SQLite, Fossil is very nice software.

vouaobrasil 4y ago

To be honest, I hate Git. The commands don't really make sense outside some basic stuff. For certain organizational setups it seems like overkill. I am not a full-time programmer but I do programming for my job and for personal projects sometimes and I never enjoy using Git.

BowBun 4y ago
It's not intuitive, but it's an amazing tool that has stood the test of time for decades. I used to struggle with Git, but after putting in a little extra time and studying it more, now I feel like it's a crucial tool in my toolbox and I can use it for much more than _just_ storing my code. Git helps me understand what my colleagues wrote, gives me incredible control over breaking my work apart, and gives me tools to troubleshoot issues (bisect).
- cholantesh 4y ago
  I keep hearing that Mercurial does all of this and is more ergonomic, which begs the question as to why it never captured mindshare the way git did.
  - yjftsjthsd-h 4y ago
    > why it never captured mindshare the way git did. If nothing else, network effects. Linux uses git, github is popular.
  - asciimov 4y ago
    Git is part of the official doctrine of the Cult of Torvalds, anything else is heresy.
  - seabrookmx 4y ago
    How much it matters for the average repo is debatable, but git is considerably faster than hg.
- simiones 4y ago
  After moving to Git from Perforce for ~5 years now, I still miss P4V's Timeline view so much when trying to understand when and why some code changes happened. It's like a kind of blame + log in a single UI, in Git terms, and is just wonderful for quickly moving through the entire history of a file.

masukomi 4y ago

Richard Hipp (SQLite guy) spoke about the thinking behind writing Fossil instead of using Git on Corecursive episode 66. If i remember correctly, it wasn't that they had any real problem with git, but that git didn't really fit with how they wanted to work, so they created their own thing. https://corecursive.com/066-sqlite-with-richard-hipp/ https://corecursive.com/066-sqlite-with-richard-hipp/

2143 4y ago

Fun fact: Fossil uses sqlite. And sqlite uses fossil. Think about that. SQLite is what I consider a well-engineered product. And Richard Hipp is an excellent engineer. Listen to his podcast episodes on the changelog. It's fun. His mentality is interesting. https://changelog.com/person/drh/podcasts#feed https://changelog.com/person/drh/podcasts#feed

vitiral 4y ago
It has bootstrapped it's VCS!

adaga 4y ago

Alt title - SQLite doesn't Git it Great read :D

dier 4y ago

With regard to rebase and fossil vs git when you have a small team of trusted developers rebase is harmful because you lose information that could help you understand the _why_ of something. In contrast if you are working with thousands of untrusted developers you need a way to increase the signal-to-noise at the cost of some granularity. This comes about from their development styles (see: http://www.catb.org/~esr/writings/cathedral-bazaar/ http://www.catb.org/~esr/writings/cathedral-bazaar/). - Use fossil if you prefer the cathedral style of development SQLite is open source but does not accept contributions. - Use Git if you prefer the bazaar style of development. You want to accept hit-and-run style contributions from anyone.

cwilkes 4y ago
I don’t understand the dislike of rebase — do you want hundreds of commits that say “linter fix” and “reformatting”? If there’s commits like “fixed off by one issue in refactor” then it should be a comment in the code so that future will explorers won’t make the same mistake. Rebase by itself isn’t bad, it just has to contain a good description of what was done and why. Edit: after posting I realize that I confounded rebase and squash — which is kind of ingrained in my head as that’s how I use GitHub to merge PRs.
- Double_a_92 4y ago
  They are better than one single commit with 100s of changed files. Especially when you are debugging things and want to know why exactly some line was changed in that way and by whom.