1. `git update-ref --no-deref --stdin`, fed with a list of refs to nuke, and a list of [replace refs](https://git-scm.com/docs/git-replace) to delete, create, or update.
1. `git reset --hard`
1. `git reflog expire --expire=now --all`
@ -843,15 +870,10 @@ Some notes or exceptions on each of the above:
be passed to fast-export. But when we don't need to work on blobs,
passing `--no-data` speeds things up. Also, other flags may change
the structure of the pipeline as well (e.g. `--dry-run` and `--debug`)
1. Selection of files based on paths could cause every commit in the
history of a branch or tag to be pruned, resulting in the branch or
tag needing to be pruned. However, filter-repo just works by
stripping out the 'commit' and 'tag' directives for each one that's
not needed, meaning fast-import won't do the branch or tag deletion
for us. So we do it in a post-processing step to ensure we avoid
mixing old and new history. Also, we use this step to write replace
refs for accessing the newly written commit hashes using their
previous names.
1. We use this step to write replace refs for accessing the newly written
commit hashes using their previous names. Also, if refs were renamed
by various steps, we need to delete the old refnames in order to avoid
mixing old and new history.
1. Users also have old versions of files in their working tree and index;
we want those cleaned up to match the rewritten history as well. Note
that this step is skipped in bare repos.
@ -954,16 +976,17 @@ the user when it detects an issue:
filter-repo.
* Partial-repo filtering does not mesh well with filter-repo's "avoid
mixing old and new history" design. filter-repo has some capability in
this area but it is undocumented, mostly untested, and may require
multiple non-obvious flags to be set to make sane use of it. While
there might be valid usecases for partial-repo filtering, the only ones
I've run into in the wild are sidestepping filter-branch's insanely
slow execution on commits that would not be changed by the filters in
question anyway (which is largely irrelevant since filter-repo is
multiple orders of magnitude faster), or to do operations better suited
to git-rebase(1) and which rebase grew special options for years ago
(e.g. the `--signoff` option).
mixing old and new history" design. filter-repo has some capability
in this area but it is intentionally underdocumented and mostly left
for use by external scripts which import filter-repo as a module (some
examples in contrib/filter-repo-demos/ do use this). The only real
usecases I've seen for partial repo filtering, though, are
sidestepping filter-branch's insanely slow execution on commits that
would not be changed by the filters in question anyway (which is
largely irrelevant since filter-repo is multiple orders of magnitude
faster), or to do operations better suited to git-rebase(1) and which
rebase grew special options for years ago (e.g. the `--signoff`