Use the 'feature done' ability to mark when the fast-import stream is
finished, so that an aborted run (due to running into some kind of bug
while filtering, whether a bug in the code, or an error in the repo or
flags specified for the case under consideration) won't cause the repo
to be rewritten.
Signed-off-by: Elijah Newren <newren@gmail.com>
It may be that the only time a reference is shown in the fast-export stream
is for a commit which will become empty due to the filtering. We do not
want such refs to be left out and thus not be updated; we want them to
instead be set to the nearest non-empty ancestor. Only if it has no
non-empty ancestor would we want it to be stripped out.
Signed-off-by: Elijah Newren <newren@gmail.com>
Slightly re-order the code to make input, output, and filtering sections
distinct. Also, avoid running `git fast-import` at all when we're in
--dry-run mode.
Signed-off-by: Elijah Newren <newren@gmail.com>
We always called record_id_rename with handle_transitivity set to True, and
I do not know of a use case that would do otherwise so let's just hardcode
that value.
Signed-off-by: Elijah Newren <newren@gmail.com>
My idea to use --export-marks and --import-marks to avoid the need for the
id_offset was not tested and apparently a bad idea. When splicing together
multiple repositories, the second will croak if we pass it --import-marks
with a file having sha1sums that don't exist in that repository.
I'm afraid this might conflict with the --import-marks stuff used in collab
so I've only enabled it for streams beyond the first. So there might be an
issue using --import-marks on a second or later fast-export output stream,
but I can't think of a use case for that...
Signed-off-by: Elijah Newren <newren@gmail.com>
Filtering input from multiple repositories can still be done; however, to
avoid overloading of mark numbers, one should pass --export-marks=<file>
to the first git fast-export and pass --import-marks=<file> to the second.
Signed-off-by: Elijah Newren <newren@gmail.com>
git-fast-import requires that file changes listed in a merge commit be
relative to the first parent. Thus, if I've added new files on a branch
being merged in from the second or later parents, I need to manually
modify the list of files in the merge commit as well. In order to do that,
as soon as I splice in any commit, I have to record the list of new files
for both that commit and every descendant it has.
Signed-off-by: Elijah Newren <newren@gmail.com>
Also, provide an OutputStream class, to make it easy to still direct all
output to some file rather than always sending to git fast-import.
Signed-off-by: Elijah Newren <newren@gmail.com>
Automatically do renaming of references to commits that were skipped, and
automatically remove skipped blobs from the output of commits that
reference them.
Signed-off-by: Elijah Newren <newren@gmail.com>
Elijah Newren
James Foucar