3 ms·

This prioritises accuracy/history of what happened, but this has significant disadvantages and practically no advantages (other than "accuracy of what happened"

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 20d 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.
- rgoulter 19d ago
  Can you help provide examples from your development experience where "knowing the accurate history of what happened" was a very big advantage, to the extent where not having this knowledge would have made things very difficult?
  - otherme123 19d ago
    Here a developer thought that redis would be a good add to the stack, so we decided he should try. It turned out that it didn't fit, mainly because it needed to touch code in more places than anticipated. We went back to starting point, but the project now carries a "no more redis/cache attempts before reading this one, please" fossil. New attempts can't say "oh, I didn't know this was attempted before". With git, this kind of experiment would be hidden with a "reset hard", and probably will happen again when people forgets, someone says "didn't we try that a year ago?" but we have no records. This is very helpful in small private teams, not so much in biggest teams (kernel), pass-by PR environments (github), or public CV-oriented repos (no mistakes allowed there, only pretty linear timelines).

bigstrat2003 20d 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.

rgoulter 19d ago
Can you help provide examples from your development experience where "knowing the accurate history of what happened" was a very big advantage, to the extent where not having this knowledge would have made things very difficult?
- otherme123 19d ago
  Here a developer thought that redis would be a good add to the stack, so we decided he should try. It turned out that it didn't fit, mainly because it needed to touch code in more places than anticipated. We went back to starting point, but the project now carries a "no more redis/cache attempts before reading this one, please" fossil. New attempts can't say "oh, I didn't know this was attempted before". With git, this kind of experiment would be hidden with a "reset hard", and probably will happen again when people forgets, someone says "didn't we try that a year ago?" but we have no records. This is very helpful in small private teams, not so much in biggest teams (kernel), pass-by PR environments (github), or public CV-oriented repos (no mistakes allowed there, only pretty linear timelines).