mirror of
https://github.com/newren/git-filter-repo.git
synced 2024-07-06 02:12:17 +02:00
df6c8652a2
There's also a fix in here to make sure to throw an error if users are trying to rename paths and use --invert-paths; it's not clear at all what that would even mean. But that also becomes important later... Due to the ability to either filter wanted paths (default), or to just specify unwanted paths (with --invert-paths), I keep a special args.inclusive variable to track whether a "match" means we want the path or not. There are some special cases, notably when there are no filters present (meaning e.g. no --path specifications, at most there are some --path-rename values provided). When there are no filters present, that means we should keep paths even if we don't "find a match" against any of the filters. Now, since the rename code was embedded in the same loop as the filter checks, it unfortunately was also being checked against the args.inclusive setting despite never setting whether it found a match. That happened to work in the special case that there were no filtering paths but only because of the special logic for that case. Since renaming only makes sense if --invert-paths is not specified, any path we rename is one we always want to keep. Make sure we do. Reported-by: Nadège (@nagreme on GitHub) Signed-off-by: Elijah Newren <newren@gmail.com> |
||
|---|---|---|
| .. | ||
| t9390 | ||
| t9391 | ||
| run_coverage | ||
| t9390-filter-repo.sh | ||
| t9391-filter-repo-lib-usage.sh | ||
| t9392-python-callback.sh | ||
| test-lib-functions.sh | ||
| test-lib.sh | ||