You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
821
848
1.`git reset --hard`
822
849
1.`git reflog expire --expire=now --all`
@@ -843,15 +870,10 @@ Some notes or exceptions on each of the above:
843
870
be passed to fast-export. But when we don't need to work on blobs,
844
871
passing `--no-data` speeds things up. Also, other flags may change
845
872
the structure of the pipeline as well (e.g. `--dry-run` and `--debug`)
846
-
1. Selection of files based on paths could cause every commit in the
847
-
history of a branch or tag to be pruned, resulting in the branch or
848
-
tag needing to be pruned. However, filter-repo just works by
849
-
stripping out the 'commit' and 'tag' directives for each one that's
850
-
not needed, meaning fast-import won't do the branch or tag deletion
851
-
for us. So we do it in a post-processing step to ensure we avoid
852
-
mixing old and new history. Also, we use this step to write replace
853
-
refs for accessing the newly written commit hashes using their
854
-
previous names.
873
+
1. We use this step to write replace refs for accessing the newly written
874
+
commit hashes using their previous names. Also, if refs were renamed
875
+
by various steps, we need to delete the old refnames in order to avoid
876
+
mixing old and new history.
855
877
1. Users also have old versions of files in their working tree and index;
856
878
we want those cleaned up to match the rewritten history as well. Note
857
879
that this step is skipped in bare repos.
@@ -954,16 +976,17 @@ the user when it detects an issue:
954
976
filter-repo.
955
977
956
978
* Partial-repo filtering does not mesh well with filter-repo's "avoid
957
-
mixing old and new history" design. filter-repo has some capability in
958
-
this area but it is undocumented, mostly untested, and may require
959
-
multiple non-obvious flags to be set to make sane use of it. While
960
-
there might be valid usecases for partial-repo filtering, the only ones
961
-
I've run into in the wild are sidestepping filter-branch's insanely
962
-
slow execution on commits that would not be changed by the filters in
963
-
question anyway (which is largely irrelevant since filter-repo is
964
-
multiple orders of magnitude faster), or to do operations better suited
965
-
to git-rebase(1) and which rebase grew special options for years ago
966
-
(e.g. the `--signoff` option).
979
+
mixing old and new history" design. filter-repo has some capability
980
+
in this area but it is intentionally underdocumented and mostly left
981
+
for use by external scripts which import filter-repo as a module (some
982
+
examples in contrib/filter-repo-demos/ do use this). The only real
983
+
usecases I've seen for partial repo filtering, though, are
984
+
sidestepping filter-branch's insanely slow execution on commits that
985
+
would not be changed by the filters in question anyway (which is
986
+
largely irrelevant since filter-repo is multiple orders of magnitude
987
+
faster), or to do operations better suited to git-rebase(1) and which
988
+
rebase grew special options for years ago (e.g. the `--signoff`
0 commit comments