7 ms·

Fossil is extremely frustrating to me. There are so many parts that I'm drawn to, but then are there showstoppers that prevent real adoption (by me). I've used

by LVB 6d ago

Fossil is extremely frustrating to me. There are so many parts that I'm drawn to, but then are there showstoppers that prevent real adoption (by me). I've used it in earnest a number of times. Their immutability stance is at the root of the problems. Lack of rebase is most infamous, but you can't even edit a ticket description! Make a typo or error in the description, and you're expected to append more notes, or delete and recreate the ticket. I really love the idea of a powerful, shrink-wrapped scm + ticketing etc. system, and I'm a sqlite fan, but fossil hasn't worked out for me.

thunderbong 6d ago
Every time fossil comes up, I hear this same issue - "why is there no rebase?" And honestly, I've never been able to get this argument. It's a version management system! It's supposed to maintain the history of what's been done, both good and bad. In fact, that's the whole point of a VCS, isn't it? IMHO, if we want to show a different path than what's been actually taken for the codebase to reach where it is now, we might as well use a network drive to store the different versions. Why bother with a VCS then?
- ok_dad 6d ago
  Your definition of version control isn’t the same as mine, probably. Why even ask this? People have preferences and different beliefs.
- jiehong 6d ago
  How about temporary commits locally, that then get squashed to ensure each build cleanly? Or secrets that shouldn’t have been committed? Maybe it what an ironical question ^^
  - otherme123 6d ago
    I use both, and I prefer fossil. But my coworkers hate fossil because they can't fake their commits to make them look good. This is something I actually like about fossil: git has tools just to make things look pretty even if they can cause serious headaches (rebase), so users are skewed towards good looking timelines made with dirty commits then rearranged and squashed. OTOH fossil forces you to do your best but accept that sometimes you botch it, and have to mark a commit as "does not build". And I don't know why (forces you to review and cofirm?), but I had never commited unwanted stuff with fossil. But I had with git, probably by using the -am flag without realising a whole new dir is now in the scope.
    - omnimus 6d ago
      This sounds more like some elitism. Who cares how your coworkers got there, the point is to have good history at the origin. People don't need to see your dirty laundy, there is nothing interesting about it.
      - otherme123 6d ago
        > People don't need to see your dirty laundy, there is nothing interesting about it. We disagree here, thus we prefer different tools. Nothing elitist here. I have seen git people throwing away repos and start again just to hide mistakes/pivoting and look "pro" and "right from the start". Or worse, I have seen people botching repos to others rewritting history just to make them look clean. I embrace mistakes, and sometimes they become useful later to replay train of thoughs.
      - specialist 6d ago
        Agreed. In teams, only the history of what is committed to shared repo is important.
    - rgoulter 6d ago
      This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened". There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy. From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed". What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.
      - bigstrat2003 5d ago
        > but this has significant disadvantages and practically no advantages (other than "accuracy of what happened". ...which is a very big advantage, big enough that it outweighs the disadvantages in my opinion.
  - ivell 6d ago
    Secrets that is committed anyway has to be assumed as compromised. So those secrets must be immediately changed. Removing it from history would help a bit, but is not a reliable mitigation.
- LVB 6d ago
  And this highlights my frustration. I don’t want to have this debate. The tool should allow its operator to set whatever level of strictness or purity they want for their project. Fossil already offers a million settings. Add another and make me turn on “dangerously-unsafe-rebase” to get the feature if need be.
  - spit2wind 6d ago
    What you're wanting is against their philosophy. However, there is removal via shunning. There's also the query langauge to control the view. So, there's everything you need to do what you want. Obviously that's going to take some figuring out for queries and aliases. But it seems doable to me. Awkward, yes, but doable. AFAICT, they've provided a way to do things that go against their philosophy should anyone be inclined.
- ncphillips 6d ago
  History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
- pampas 6d ago
  Suppose a secret like some personally identifying information was recently leaked into the main branch. You are legally required to scrub it. How do you fix it? Ideally a repo needs to reflect the state of every event that happened. Practically there are edge cases when it's just best to rewrite history.
spit2wind 6d ago
I think it's less about immutability and more about visibility. The argument made by the Fossil project, AFAIU, is that it has a better log view than git and has better traceability through SQL based search in addition t the cli and web interface. What kind of note are you using? There are several and, if I recall correctly, that affects the view a bit. See the "Auxiliary notes attached to check-ins or branches" https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki To me, associating a wiki page to a commit makes way more sense than as a commit message that's part of the commit. This way the message can give a summary and then the detail is given in full-fledged markup file that has its own version history. Totally fair if that's not something that works for you, though.

by LVB 6d ago

thunderbong 6d ago

Every time fossil comes up, I hear this same issue - "why is there no rebase?" And honestly, I've never been able to get this argument. It's a version management system! It's supposed to maintain the history of what's been done, both good and bad. In fact, that's the whole point of a VCS, isn't it? IMHO, if we want to show a different path than what's been actually taken for the codebase to reach where it is now, we might as well use a network drive to store the different versions. Why bother with a VCS then?

ok_dad 6d ago
Your definition of version control isn’t the same as mine, probably. Why even ask this? People have preferences and different beliefs.
jiehong 6d ago
How about temporary commits locally, that then get squashed to ensure each build cleanly? Or secrets that shouldn’t have been committed? Maybe it what an ironical question ^^
- otherme123 6d ago
  I use both, and I prefer fossil. But my coworkers hate fossil because they can't fake their commits to make them look good. This is something I actually like about fossil: git has tools just to make things look pretty even if they can cause serious headaches (rebase), so users are skewed towards good looking timelines made with dirty commits then rearranged and squashed. OTOH fossil forces you to do your best but accept that sometimes you botch it, and have to mark a commit as "does not build". And I don't know why (forces you to review and cofirm?), but I had never commited unwanted stuff with fossil. But I had with git, probably by using the -am flag without realising a whole new dir is now in the scope.
  - omnimus 6d ago
    This sounds more like some elitism. Who cares how your coworkers got there, the point is to have good history at the origin. People don't need to see your dirty laundy, there is nothing interesting about it.
    - otherme123 6d ago
      > People don't need to see your dirty laundy, there is nothing interesting about it. We disagree here, thus we prefer different tools. Nothing elitist here. I have seen git people throwing away repos and start again just to hide mistakes/pivoting and look "pro" and "right from the start". Or worse, I have seen people botching repos to others rewritting history just to make them look clean. I embrace mistakes, and sometimes they become useful later to replay train of thoughs.
    - specialist 6d ago
      Agreed. In teams, only the history of what is committed to shared repo is important.
  - rgoulter 6d ago
    This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened". There are cases where you really do want an append-only leger, where tampering with history is malicious. -- But, generally, it's preferable to be presented with something tidy. From some other comment in this thread, I get the impression it's possible to re-present a set of changes in a clean/tidy way? That seems a better way of putting it. "You can still have a clean view into a set of changes while preserving an accurate history of what changed". What's hard to understand is why you'd be against the idea of tidy communication/presentation of changes in the first place.
    - bigstrat2003 5d ago
      > but this has significant disadvantages and practically no advantages (other than "accuracy of what happened". ...which is a very big advantage, big enough that it outweighs the disadvantages in my opinion.
- ivell 6d ago
  Secrets that is committed anyway has to be assumed as compromised. So those secrets must be immediately changed. Removing it from history would help a bit, but is not a reliable mitigation.
LVB 6d ago
And this highlights my frustration. I don’t want to have this debate. The tool should allow its operator to set whatever level of strictness or purity they want for their project. Fossil already offers a million settings. Add another and make me turn on “dangerously-unsafe-rebase” to get the feature if need be.
- spit2wind 6d ago
  What you're wanting is against their philosophy. However, there is removal via shunning. There's also the query langauge to control the view. So, there's everything you need to do what you want. Obviously that's going to take some figuring out for queries and aliases. But it seems doable to me. Awkward, yes, but doable. AFAICT, they've provided a way to do things that go against their philosophy should anyone be inclined.
ncphillips 6d ago
History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
pampas 6d ago
Suppose a secret like some personally identifying information was recently leaked into the main branch. You are legally required to scrub it. How do you fix it? Ideally a repo needs to reflect the state of every event that happened. Practically there are edge cases when it's just best to rewrite history.

spit2wind 6d ago

I think it's less about immutability and more about visibility. The argument made by the Fossil project, AFAIU, is that it has a better log view than git and has better traceability through SQL based search in addition t the cli and web interface. What kind of note are you using? There are several and, if I recall correctly, that affects the view a bit. See the "Auxiliary notes attached to check-ins or branches" https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki https://fossil-scm.org/home/doc/trunk/www/wikitheory.wiki To me, associating a wiki page to a commit makes way more sense than as a commit message that's part of the commit. This way the message can give a summary and then the detail is given in full-fledged markup file that has its own version history. Totally fair if that's not something that works for you, though.