6 ms·

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 ironi

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 4d 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 4d 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 4d 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 4d ago
    Agreed. In teams, only the history of what is committed to shared repo is important.
- rgoulter 4d 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 3d 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 4d 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.

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 4d 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 4d 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 4d 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 4d ago
  Agreed. In teams, only the history of what is committed to shared repo is important.
rgoulter 4d 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 3d 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 4d 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.