SVN revision numbers from svn:externals property, which are a multiple
of 1024 (2^10), are transformed by SubGit to contain a binary suffix
("k", "m" and "g" have been checked) in .gitsvnextmodules file.
These aren't valid revision numbers in SVN either.
Examples:
1024 -> 1k
2048 -> 2k
1048576 -> 1m
1049600 -> 1025k
1073741824 -> 1g
This led to the following error:
svn_rev = int(parsed_config[section]['revision'])
ValueError: invalid literal for int() with base 10: '1k'
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Elijah Newren <newren@gmail.com>
This is meant to be a post-processing step after SVN-to-Git conversion
by SubGit (https://subgit.com/), which creates a ".gitsvnextmodules"
file that we will use for svn:externals conversion.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Elijah Newren <newren@gmail.com>
Commit 3e153806ff (lint-history: Add --refs argument, 2021-12-30)
added a --refs argument to lint-history, but attempting to inject it
directly into the parsed args fields, bypassing some of the important
logic from FilteringOptions.parse_args() -- particularly the bit where
it translates an empty --refs into a request for '--all' as as list of
references. I somehow overlooked this in my earlier review. Fix the
problem now.
Signed-off-by: Elijah Newren <newren@gmail.com>
Some users may want to take advantage of setting TMPDIR to another
location that might be faster for the linting process.
Reported-by: @ruv on GitHub
Signed-off-by: Elijah Newren <newren@gmail.com>
It was not clear for some users that the filenames would be relative
paths from the toplevel of the repository. Add some text to explain
this.
Reported-by: @ruv on GitHub
Signed-off-by: Elijah Newren <newren@gmail.com>
Users could specify relative paths on the command line, and then also
provide a directory other than '.' for the repo. Since we did an
unconditional os.chdir() to move into the repo, that would invalidate
the original relative paths. Fix that by changing the relative paths
into absolute paths.
Signed-off-by: 林博仁(Buo-ren Lin) <Buo.Ren.Lin@gmail.com>
[en: tweaked commit message to explain the problem]
Signed-off-by: Elijah Newren <newren@gmail.com>
This fixes the "TypeError: a bytes-like object is required, not 'str'"
problem on Windows, letting t9391 pass.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We had a lingering issue in the conversion from python2 to python3; as
reported by @thebrandre on GitHub:
any(x==b'1' for x in b"123")
# returns True in Python2 and False in Python3 because different
# types are returned on iteration:
[type(x) for x in b"123"]
# Python2: [<type 'str'>, <type 'str'>, <type 'str'>]
# Python3: [<class 'int'>, <class 'int'>, <class 'int'>]
Replace the
any(x==b"0" for x in blob.data[0:8192])
construct with
b"\0" in blob.data[0:8192]
to fix this.
Suggested-by: @thebrandre on GitHub
Signed-off-by: Elijah Newren <newren@gmail.com>
In repositories with annotated tags filter-lamely crashes with the
message: "NameError: name 'Reset' is not defined".
This is because of a missing "fr" module prefix in the code, which this
commit adds.
Signed-off-by: Marius Renner <marius@mariusrenner.de>
"no-op" might suggest that it doesn't do anything, when in reality it
does exactly what filter-repo does. Rename it to barebones-example.
Signed-off-by: Elijah Newren <newren@gmail.com>
The desire to format or lint code throughout history has arisen several
times. It's more natural to do this in filter-branch since it somewhat
forces people to run external commands, but we have an example contrib
demo that shows how to run an external command on each file in history
that I created even before any of these requests came in and yet I still
periodically get requests about it.
Make lint-history ever-so-slightly easier to apply to a subset of
filenames, and include its usage as an extra cheat sheet comparison for
filter-branch-vs-filter-repo commands.
Signed-off-by: Elijah Newren <newren@gmail.com>
The purpose of this example is to solely show what to import and run to
recover filter-repo's behavior as-is. It doesn't modify any behavior,
but instead exists as an example so people can easily find a good
starting point for making their own modifications.
Signed-off-by: Elijah Newren <newren@gmail.com>
filter-lamely does not handle filenames with special characters (such as
äöü or even \n and \t) properly when using a tree filter or index
filter. It either does not quote the input to git correctly or parses
git output incorrectly, causing affected filenames to be mangled with
extraneous double quotes in the history or even crashing the program.
Make filter-lamely correctly handle such filenames by using
NUL-delimited input and output modes for the affected git commands.
Signed-off-by: Marius Renner <marius@mariusrenner.de>
When a file is deleted, there is nothing to lint, so we can just keep
the deletion as-is.
Reported-by: Thorben Kröger <dev@thorben.net>
Signed-off-by: Elijah Newren <newren@gmail.com>
In commit f2729153 (filter-repo: workaround Windows' insistence that cwd
not be a bytestring, 2019-10-19), filter-repo was made to use a special
SubprocessWrapper class instead of the normal subprocess calls, due to
what appears to be in bugs in the python implementation on Windows not
working with arguments being bytestrings. Add the same workarounds to
bfg-ish and filter-lamely.
Signed-off-by: Elijah Newren <newren@gmail.com>
Make it clearer that absolute paths should not be used for pathnames
within a git repository. Also, fix the comment about how the
insert-beginning script could be implemented as a one-liner; the
example commented-out code should have used bytestrings.
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>
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>
Markus Heidelberg
Elijah Newren
Robert Haschke
Francis Charette Migneault
林博仁(Buo-ren Lin)
Johannes Schindelin
Marius Renner