You can call bytes.replace() or re.sub(), but you can't call
bytes.sub(). Oops. Fix the example in the documentation.
Reported-by: John Gietzen <john@gietzen.us>
Signed-off-by: Elijah Newren <newren@gmail.com>
git fast-import, in an attempt to be friendly, allows the same file to
be specified multiple times within a commit and just takes the last
version of the file listed. It determines whether files are the same
via fspathncmp, which is defined differently depending on the setting of
core.ignorecase. Unfortunately, this means that if someone is trying to
do filtering of history and using a broken (case-insensitive) filesystem
and the history they are filtering has some paths that differed in name
only, then fast-import will delete whichever of the "colliding" files is
listed first.
Avoid these problems by just turning off core.ignorecase while
fast-import is running. This will prevent silently modifying the repo
in an unexpected way. Users on such filesystems may have difficulty
checking out commits with files which differ in case only, but that is
a separate problem for them to deal with after rewriting history.
Signed-off-by: Elijah Newren <newren@gmail.com>
A few changes:
* Include notes about git-2.24.0 changes
* Make it clearer that messing with the first parent could have
negative side-effects if the file_changes aren't also updated.
* Fix wrapping of a line that was too long.
Also, update the README.md:
* Note the upstream improvements made in (not yet released) git-2.24.0
Signed-off-by: Elijah Newren <newren@gmail.com>
Partial history rewrites were possible before with the (previously
hidden) --refs flag, but the defaults were wrong. That could be worked
around with the --source or --target flags, but that disabled --no-data
for fast-export and thus slowed things down, and also would require
overridding --replace-refs. And the defaults for --source and --target
may diverge further from what is wanted/needed for partial history
rewrites in the future.
So, add --partial as a first-class supported option with scary
documentation about how it permits mixing new and old history. Make
--refs imply that flag. Make the behavioral similarities (in regards to
which steps are skipped) between --source, --target, and --partial more
clear. Add relevant documentation to round it out.
Signed-off-by: Elijah Newren <newren@gmail.com>
Allow folks to periodically update the export of a live repo without
re-exporting from the beginning. This is a performance improvement, but
can also be important for collaboration. For example, for sensitivity
reasons, folks might want to export a subset of a repo and update the
export periodically. While this could be done by just re-exporting the
repository anew each time, there is a risk that the paths used to
specify the wanted subset might need to change in the future; making the
user verify that their paths (including globs or regexes) don't also
pick up anything from history that was previously excluded so that they
don't get a divergent history is not very user friendly. Allowing them
to just export stuff that is new since the last export works much better
for them.
Signed-off-by: Elijah Newren <newren@gmail.com>
Elijah Newren