This is a re-implementation of git-filter-branch that is nearly
perfectly bug compatible (it can replace git-filter-branch and still
pass the git testsuite). It deviates in one minor way that should not
matter to real world usecases, but allows it to run a few times faster
than filter-branch.
Signed-off-by: Elijah Newren <newren@gmail.com>
Being able to find the new commit hash for either an abbreviated commit
hash or a full commit hash is much more useful than only working for a
full commit hash.
Signed-off-by: Elijah Newren <newren@gmail.com>
When I wrote git_fast_filter.py, I was unaware of and did not forsee
libgit2. So, although the license said the project could be used under
whatever license git.git was, there was still a potential barrier for
usage by libgit2. I'm not sure if libgit2 will ever want to use
filter-repo, but I don't want the barrier there and I would like to
avoid a repeat of this problem. (Also, since filter-repo is for the
most part a one-shot usage tool, I doubt that the normal copyleft
provisions could provide much value.)
MIT is widely used, compatible with just about everyting, and is
preferred by Palantir (my current employer) for open source
contributions. So, I contacted all other contributors (Jim is still at
Sandia) and got permission to relicense.
Signed-off-by: Elijah Newren <newren@gmail.com>
Commit 346f2ba891 (filter-repo: make reencoding of commit messages
togglable, 2019-05-11) made reencoding of commit messages togglable but
forgot to add parsing and outputting of the encoding header itself. Add
such ability now.
Signed-off-by: Elijah Newren <newren@gmail.com>
Now that we are tracking exported and imported refs, we no longer need
to rely on _orig_refs and _seen_refs for deletion of "unused" refs at
the end of the run. Verify that we correctly tracked exported and
imported refs by using them instead for the post-run ref deletion. This
removes the last use of _seen_refs, which will be removed in a
subsequent commit.
Signed-off-by: Elijah Newren <newren@gmail.com>
We previously nuked all refs not seen in the import using _seen_refs, by
comparing to a full list of original refs. That works okay when doing a
full repository rewrite, but fails for partial history rewrites.
Further, external rewriting tools that wants to implement a tweak of
this behavior would have had to access the internal _seen_refs field,
but might not be able to rely on _orig_refs if they were doing a partial
history rewrite. Fix both by tracking both which refs were exported
from the source repository, and which were ultimately imported into the
target repository (they may differ due to pruned commits, renamed
branches or tags, etc.). Make both available via a new public API,
get_exported_and_imported_refs().
Signed-off-by: Elijah Newren <newren@gmail.com>
External rewrite tools using filter-repo as a library may want to add
additional objects into the stream. Some examples in t/t9391 did this
using an internal _output field and using syntax that did not seem so
clear. Provide an insert() method for doing this, and convert existing
cases over to it.
Signed-off-by: Elijah Newren <newren@gmail.com>
When we prune a commit for being empty, there is no update to the branch
associated with the commit in the fast-import stream. If the parent
commit had been associated with a different branch, then the branch
associated with the pruned commit would not be updated without
additional measures. In the past, we resolved this by recording that
the branch needed an update in _seen_refs. While this works, it is a
bit more complicated than just issuing an immediate Reset. Also, note
that we need to avoid calling callbacks on that Reset because those
could rename branches (again, if the commit-callback already renamed
once) causing us to not update the intended branch.
There was actually one testcase where the old method didn't work: when a
branch was pruned away to nothing. A testcase accidentally encoded the
wrong behavior, hiding this problem. Fix the testcase to check for
correct behavior.
Signed-off-by: Elijah Newren <newren@gmail.com>
We previously did this incorrectly, but due to our assumptions of
full-history rewriting and deleting of unseen refs, we got away with it.
Fix this for partial history rewrites.
Signed-off-by: Elijah Newren <newren@gmail.com>
Commit 1f0e57bada ("filter-repo: avoid pruning annotated tags that we
have seen", 2019-03-07) left behind the setting of a variable,
full_ref, that is no longer used. Remove it.
Signed-off-by: Elijah Newren <newren@gmail.com>
Add a flag allowing for specifying a file filled with blob-ids which
will be stripped from the repository.
Signed-off-by: Elijah Newren <newren@gmail.com>
Fix a few issues and add a token testcase for partial repo filtering.
Add a note about how I think this is not a particularly interesting or
core usecase for filter-repo, even if I have put some good effort into
the fast-export side to ensure it worked. If there is a core usecase
that can be addressed without causing usability problems (particularly
the "don't mix old and new history" edict for normal rewrites), then
I'll be happy to add more testcases, document it better, etc.
Signed-off-by: Elijah Newren <newren@gmail.com>
Make several fixes around --source and --target:
* Explain steps we skip when source or target locations are specified
* Only write reports to the target directory, never the source
* Query target git repo for final ref values, not the source
* Make sure --debug messages avoid throwing TypeErrors due to mixing
strings and bytes
* Make sure to include entries in ref-map that weren't in the original
target repo
* Don't:
* worry about mixing old and new history (i.e. nuking refs
that weren't updated, expiring reflogs, gc'ing)
* attempt to map refs/remotes/origin/* -> refs/heads/*
* disconnect origin remote
* Continue (but only in target repo):
* fresh-clone sanity checks
* writing replace refs
* doing a 'git reset --hard'
Signed-off-by: Elijah Newren <newren@gmail.com>
Add a flag for filtering out blob based on their size, and allow the
size to be specified using 'K', 'M', or 'G' suffixes.
Signed-off-by: Elijah Newren <newren@gmail.com>
Create a new function, GitUtils.get_blob_sizes() to hold some logic
that used to be at the beginning of RepoAnalyze.gather_data(). This
will allow reuse of this functionality within RepoFilter.
Signed-off-by: Elijah Newren <newren@gmail.com>
Although fast-import can take file changes in any order, trying to debug
by comparing the original fast-export stream to the filtered version is
difficult if the files are randomly reordered. Sometimes we aren't
comparing the filtered version to the original but just looking at the
stream passed to fast-import, in which case having the files in sorted
order may help.
Our accumulation of file_changes into a dict() in order to check for
collisions when renaming had the unfortunate side effect of sorting
files by internals of dictionary ordering. Although the files started
in sorted order, we don't in general want to use the original order
because renames can cause filenames to become out-of-order. Just apply
a simple sort at the end.
Signed-off-by: Elijah Newren <newren@gmail.com>
I suspect at some point someone will try to pass -M or -C to
fast-export; may as well leave a note in the code about another place
that's incompatible while I'm thinking about it.
Signed-off-by: Elijah Newren <newren@gmail.com>
Imperative form sounds better than --empty-pruning and
--degenerate-pruning, and it probably works better with command line
completion.
Signed-off-by: Elijah Newren <newren@gmail.com>
The reset directive can specify a commit hash for the 'from' directive,
which can be used to reset to a specify commit, or, if the hash is all
zeros, then it can be used to delete the ref. Support such operations.
Signed-off-by: Elijah Newren <newren@gmail.com>
For other programs importing git-filter-repo as a library and passing a
blob, commit, tag, or reset callback to RepoFilter, pass a second
parameter to these functions with extra metadata they might find useful.
For simplicity of implementation, this technically changes the calling
signature of the --*-callback functions passed on the command line, but
we hide that behind a _do_not_use_this_variable parameter for now, leave
it undocumented, and encourage folks who want to use it to write an
actual python program that imports git-filter-repo. In the future, we
may modify the --*-callback functions to not pass this extra parameter,
or if it is deemed sufficiently useful, then we'll rename the second
parameter and document it.
As already noted in our API compatibilty caveat near the top of
git-filter-repo, I am not guaranteeing API backwards compatibility.
That especially applies to this metadata argument, other than the fact
that it'll be a dict mapping strings to some kind of value. I might add
more keys, rename them, change the corresponding value, or even remove
keys that used to be part of metadata.
Signed-off-by: Elijah Newren <newren@gmail.com>
Location of filtering logic was previously split in a confusing fashion
between FastExportFilter and RepoFilter. Move all filtering logic from
FastExportFilter into RepoFilter, and rename the former to
FastExportParser to reflect this change.
One downside of this change is that FastExportParser's _parse_commit
holds two pieces of information (orig_parents and had_file_changes)
which are not part of the commit object but which are now needed by
RepoFilter. Adding those bits of info to the commit object does not
make sense, so for now we pass an auxiliary dict with the
commit_callback that has these two fields. This information is not
passed along to external commit_callbacks passed to RepoFilter, though,
which seems suboptimal. To be fair, though, commit_callbacks to
RepoFilter never had access to this information so this is not a new
shortcoming, it just seems more apparent now.
Signed-off-by: Elijah Newren <newren@gmail.com>
I introduced this over a decade ago thinking it would come in handy in
some special case, and the only place I used it was in a testcase that
existed almost solely to increase code coverage. Modify the testcase to
instead demonstrate how it is trivial to get the effects of the
everything_callback without it being present.
Signed-off-by: Elijah Newren <newren@gmail.com>
The specially constructed callbacks in RepoFilter.run() were
superfluous; we already had special callback functions. Instead of
creating new local functions that call the real callbacks and then do
one extra step, just put the extra wanted code into the real callbacks.
Signed-off-by: Elijah Newren <newren@gmail.com>
Using fast-import's feature done capability, any output sent to it after
the 'done' directive will be ignored. We do not intend to send any such
information, but there have been a couple cases where an accident while
refactoring the code resulted in some information being sent after the
done directive. To avoid having to debug that again, just close the
output stream after sending the 'done' directive to ensure that we get
an immediate and clear error if we ever run into such a situation again.
Signed-off-by: Elijah Newren <newren@gmail.com>
The upcoming git-2.22 release will not have the --reencode option to
fast-export; however, since we default to --reencode=yes and that was
the default behavior in all existing versions of git (only to change in
git-2.23), we can just silently leave the option off if we detect we are
running with this version. However, the diff-tree --combined-all-paths
option from git-2.22 is still mandatory; we cannot run with git versions
older than that (well, with -rc or built-from-source versions, but that
won't matter to most users).
Signed-off-by: Elijah Newren <newren@gmail.com>
Translating "Parsed %d commits" a hundred thousand times (once per
commit), turned out to be somewhat expensive -- especially since we
were only going to print it out once every few thousand commits.
Translate it once and cache the result, shaving off about 20% of
execution time for a simple rewrite of a test repository (rails).
Signed-off-by: Elijah Newren <newren@gmail.com>
This allows the user to put a whole bunch of paths they want to keep (or
want to remove) in a file and then just provide the path to it. They
can also use globs or regexes (similar to --replace-text) and can also
do renames. In fact, this allows regex renames, despite the fact that I
never added a --path-rename-regex option.
Signed-off-by: Elijah Newren <newren@gmail.com>
Using an exact path (file or directory) for --path-rename instead of a
prefix removes an ugly caveat from the documentation, makes it operate
similarly to --path, and will make it easier to reuse common code when I
add the --paths-from-file option. Switch over, and replace the
startswith() check by a call to filename_matches().
Signed-off-by: Elijah Newren <newren@gmail.com>
This new flag allows people to filter files solely based on their
basename rather than on their full path within the repo, making it
easier to e.g. remove all .DS_Store files or keep all README.md
files.
Signed-off-by: Elijah Newren <newren@gmail.com>
