6 ms·

What large team workflows require rewriting history? I’m genuinely curious as someone who is always looking for a better team git workflow.

dmtroyer 4y ago
ahh, right, thanks for the responses. I was confusing not being able to rewrite history on remote branches with not being able to rewrite history at all. I rewrite it locally all the time but almost never remotely.
peterhunt 4y ago
Some engineer checks in a customer’s personal data as a test fixture and it has to be purged from git history to be compliant with gdpr/ccpa.
- spiffytech 4y ago
  Fossil has a 'purge' command for this purpose, though it's marked as a work-in-progress.
  - sgbeal 4y ago
    (A fossil dev here...) "Purge" is really only intended for use with fossil's "bundle" feature, bundles being essentially feature-rich patches which record all of the historical state of the bundle. (Yes, it's long been flagged as experimental, but it's also been unchanged since it was added so i'll look into getting that notice removed or amended.) The idea of fossil's bundles is that a person not associated with a project can submit a patch in the form of a bundle, a developer imports that bundle into their repo and either retains it or "purges" it, leaving the developer's repo clone back in a clean pre-bundle state. That feature can, however, and sometimes is, used for "popping" the top-most commit from a repository (so long as it has not yet been pushed to a remote). So long as a local repo has not been synced with any remotes, and so long as there are no branch points to interfere with it, repeated applications the bundle/purge combo can be used to pop the top-most checkin multiple times, effectively wiping out as-yet-unsynced changes even if they span multiple checkins.
- somat 4y ago
  fossil has the concept of shunning an artifact, this has the interesting side effect that that artifact will now never be allowed in the repository(without additional work to un shun it). https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki
spiffytech 4y ago
I hear a lot of larger teams insist on squash commits for PRs. Fossil isn't a fan of squashing.
- cortesoft 4y ago
  Squash commits aren’t rewriting history.
  - sshine 4y ago
    Squashing literally requires `git rebase`. Perhaps you think of squashing as a GitHub button and not a series of rewriting commands? Technically, any rewrite is equivalent to some arbitrary construction of history from some point in time, but I think a reasonable definition of rewriting history is if you need to rebase or cherry-pick when using the command-line.
    - cortesoft 4y ago
      You can create a squash commit on the main branch while leaving the feature branch untouched.
    - dahart 4y ago
      We don’t need a reasonable definition of rewriting history, we need a better conversation about what our tools are even for. Git isn’t a tool for preserving history, it’s a tool for keeping track of code changes. Git rebase provides a new, second, altered sequence of commits. It doesn’t replace the original. We often choose to preserve the rebased sequence, but this distinction is not academic, it’s critically important because as a part of a version control system, rebase can be undone, precisely because it does not write over the old history. Git never promised a “history” per se, not in the form of an immutable record of events. The framing of git rebase as a history rewrite, the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. I’m in favor of better VCSs, but the claim that rebase is a history rewrite is hyperbolic, and the judgement on top of that is silly and misguided. Rebase is a tool designed to reorder a sequence of commits, mostly for the purposes of making local changes presentable before pushing them, and has other legitimate uses too.
andix 4y ago
Inside feature branches it can be quite useful. To fix the history, squash things, …
dahart 4y ago
Private rebasing to clean up a series of commits before pushing anywhere, for one. While there’s a genuine distinction to be made between private pre-merge history and published post-merge history, Fossil’s stance is that no amount of pre-push cleanup should ever be allowed, that code commits should be immutable history from the moment of inception.
- Patrol8394 4y ago
  > no amount of pre-push cleanup should ever be allowed That’s horrible, sounds like a blockchain oO ! In my workflow I constantly create throw away commits. Once I am satisfied with the code changes I cleanup history and open a PR.
  - dahart 4y ago
    Right, you’ll definitely think twice about committing early and often if commits are suddenly etched in stone. Feels like the wrong incentive/message for a VCS. That said, I believe Fossil may be better equipped to explore a presentation layer that users have control over, and separately examine commit history when needed. Git wasn’t designed that way. I don’t agree with Fossil’s dogmatic stance on git, but Fossil might be workable in the sense that your history of noisy throwaway work can be mostly muted. I think?
    - recursive 4y ago
      Not true for everyone. I commit early and often, and treat them as if they're etched in stone. Plus I use git.
      - nimchimpsky 4y ago
  - judge2020 4y ago
    > sounds like a blockchain Both bitcoin and git use merkle trees to prevent (unwanted) history rewrites :)
devoutsalsa 4y ago
When the newbie commits a multi gigabyte file in one commit, then doubles down by deleting that file in a follow up commit.

dmtroyer 4y ago

ahh, right, thanks for the responses. I was confusing not being able to rewrite history on remote branches with not being able to rewrite history at all. I rewrite it locally all the time but almost never remotely.

peterhunt 4y ago

Some engineer checks in a customer’s personal data as a test fixture and it has to be purged from git history to be compliant with gdpr/ccpa.

spiffytech 4y ago
Fossil has a 'purge' command for this purpose, though it's marked as a work-in-progress.
- sgbeal 4y ago
  (A fossil dev here...) "Purge" is really only intended for use with fossil's "bundle" feature, bundles being essentially feature-rich patches which record all of the historical state of the bundle. (Yes, it's long been flagged as experimental, but it's also been unchanged since it was added so i'll look into getting that notice removed or amended.) The idea of fossil's bundles is that a person not associated with a project can submit a patch in the form of a bundle, a developer imports that bundle into their repo and either retains it or "purges" it, leaving the developer's repo clone back in a clean pre-bundle state. That feature can, however, and sometimes is, used for "popping" the top-most commit from a repository (so long as it has not yet been pushed to a remote). So long as a local repo has not been synced with any remotes, and so long as there are no branch points to interfere with it, repeated applications the bundle/purge combo can be used to pop the top-most checkin multiple times, effectively wiping out as-yet-unsynced changes even if they span multiple checkins.
somat 4y ago
fossil has the concept of shunning an artifact, this has the interesting side effect that that artifact will now never be allowed in the repository(without additional work to un shun it). https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

spiffytech 4y ago

I hear a lot of larger teams insist on squash commits for PRs. Fossil isn't a fan of squashing.

cortesoft 4y ago
Squash commits aren’t rewriting history.
- sshine 4y ago
  Squashing literally requires `git rebase`. Perhaps you think of squashing as a GitHub button and not a series of rewriting commands? Technically, any rewrite is equivalent to some arbitrary construction of history from some point in time, but I think a reasonable definition of rewriting history is if you need to rebase or cherry-pick when using the command-line.
  - cortesoft 4y ago
    You can create a squash commit on the main branch while leaving the feature branch untouched.
  - dahart 4y ago
    We don’t need a reasonable definition of rewriting history, we need a better conversation about what our tools are even for. Git isn’t a tool for preserving history, it’s a tool for keeping track of code changes. Git rebase provides a new, second, altered sequence of commits. It doesn’t replace the original. We often choose to preserve the rebased sequence, but this distinction is not academic, it’s critically important because as a part of a version control system, rebase can be undone, precisely because it does not write over the old history. Git never promised a “history” per se, not in the form of an immutable record of events. The framing of git rebase as a history rewrite, the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. I’m in favor of better VCSs, but the claim that rebase is a history rewrite is hyperbolic, and the judgement on top of that is silly and misguided. Rebase is a tool designed to reorder a sequence of commits, mostly for the purposes of making local changes presentable before pushing them, and has other legitimate uses too.

andix 4y ago

Inside feature branches it can be quite useful. To fix the history, squash things, …

dahart 4y ago

Private rebasing to clean up a series of commits before pushing anywhere, for one. While there’s a genuine distinction to be made between private pre-merge history and published post-merge history, Fossil’s stance is that no amount of pre-push cleanup should ever be allowed, that code commits should be immutable history from the moment of inception.

Patrol8394 4y ago
> no amount of pre-push cleanup should ever be allowed That’s horrible, sounds like a blockchain oO ! In my workflow I constantly create throw away commits. Once I am satisfied with the code changes I cleanup history and open a PR.
- dahart 4y ago
  Right, you’ll definitely think twice about committing early and often if commits are suddenly etched in stone. Feels like the wrong incentive/message for a VCS. That said, I believe Fossil may be better equipped to explore a presentation layer that users have control over, and separately examine commit history when needed. Git wasn’t designed that way. I don’t agree with Fossil’s dogmatic stance on git, but Fossil might be workable in the sense that your history of noisy throwaway work can be mostly muted. I think?
  - recursive 4y ago
    Not true for everyone. I commit early and often, and treat them as if they're etched in stone. Plus I use git.
    - nimchimpsky 4y ago
- judge2020 4y ago
  > sounds like a blockchain Both bitcoin and git use merkle trees to prevent (unwanted) history rewrites :)

devoutsalsa 4y ago

When the newbie commits a multi gigabyte file in one commit, then doubles down by deleting that file in a follow up commit.