3 ms·

Nobody wants to correct published history. Yet it still happens. Not that long ago at my office I pulled updates via git to what is to me a read only repo. I ne

Nobody wants to correct published history. Yet it still happens. Not that long ago at my office I pulled updates via git to what is to me a read only repo. I never make changes to it. Yet after pulling updates, my repo was in a state claiming I had changes to commit. The whole problem was someone who did rewrite published history. In my case the 'fix' was easy. Delete my clone and reclone. If it had been a project I needed to commit to as well, I doubt fixing the problem would have been nearly as straightforward. Sure, "rewriting history" with fossil could be done by anyone with sufficient skill and patience. The lack of such functionality as "first class features" of the software mean that it is unlikely to happen.

wereHamster 11y ago
You lay the burden to ensure that you can't make mistakes (rewrite history) on the developers of fossil. If, for some reason, fossil allowed to rewrite the history it would be considered a bug and promptly fixed. Yet, for some reason, you don't expect the same from the sysadmins who set up the git repository (ie. set it up so that non-fast forward updates are rejected). We can debate whether Git's default is sensible or not.
- CasaDeRobison 11y ago
  I'm not sure I understand what you're getting at. Sure I expect sysadmins to configure things properly. I also expect people to be human and make mistakes. My only point was that despite everyone's best intentions, it can still happen and it can be a pain to fix. If the functionality was not there, it would have been a non-issue. Is fossil perfect? Is any software perfect? Of course not. I was merely describing a single pain point I recently experienced that would not have happened without the ability to make changes to published history.
jimktrains2 11y ago
Doing a pull like that would force a merge and would be very noticeable. Also, there are other, many other, options beyond the nuclear delete and clone.
- CasaDeRobison 11y ago
  Doing an update like that would force a merge, but there was nothing to merge. I made no changes. It was a read only (to me) repository. It should have just worked, and would have had someone else on the team not rewritten history. I'm aware there are more options than delete and clone. My options were to spend time trying to fix my clone to which I had made no changes, or I could delete and reclone from the origin. The pragmatic solution was obvious and got me back to work more quickly than I would have otherwise been able to. The fact that there are more options to allow fixing a broken clone are nice, but irrelevant. Had git not allowed removing published history, it would not have been an issue. I'm all for the ability to amend history, which fossil does allow (to an extent). What it doesn't support deletion of old history followed by the creation of new history.

wereHamster 11y ago

You lay the burden to ensure that you can't make mistakes (rewrite history) on the developers of fossil. If, for some reason, fossil allowed to rewrite the history it would be considered a bug and promptly fixed. Yet, for some reason, you don't expect the same from the sysadmins who set up the git repository (ie. set it up so that non-fast forward updates are rejected). We can debate whether Git's default is sensible or not.

CasaDeRobison 11y ago
I'm not sure I understand what you're getting at. Sure I expect sysadmins to configure things properly. I also expect people to be human and make mistakes. My only point was that despite everyone's best intentions, it can still happen and it can be a pain to fix. If the functionality was not there, it would have been a non-issue. Is fossil perfect? Is any software perfect? Of course not. I was merely describing a single pain point I recently experienced that would not have happened without the ability to make changes to published history.

jimktrains2 11y ago

Doing a pull like that would force a merge and would be very noticeable. Also, there are other, many other, options beyond the nuclear delete and clone.

CasaDeRobison 11y ago
Doing an update like that would force a merge, but there was nothing to merge. I made no changes. It was a read only (to me) repository. It should have just worked, and would have had someone else on the team not rewritten history. I'm aware there are more options than delete and clone. My options were to spend time trying to fix my clone to which I had made no changes, or I could delete and reclone from the origin. The pragmatic solution was obvious and got me back to work more quickly than I would have otherwise been able to. The fact that there are more options to allow fixing a broken clone are nice, but irrelevant. Had git not allowed removing published history, it would not have been an issue. I'm all for the ability to amend history, which fossil does allow (to an extent). What it doesn't support deletion of old history followed by the creation of new history.