If the object has a size of zero, then we already have its object: it's
the empty file, and we shouldn't need to download it from anywhere. If
we inquire if it exists, then say it does, and say its location is the
system's equivalent of /dev/null.
The only tricky case is if we're de-duplicating, linking, or writing to
a file, in which case we should not try to use a link or replace on the
file, since we neither want to link nor replace the system's /dev/null.
We set the "color.diff" Git configuration directive to "always"
in several tests which exercise the scanning and parsing of
"git log -p" output in order to validate that they still
succeed even with ANSI color code escape sequences in the
Git diff output.
Unfortunately, at the present time, the tests will no longer
succeed as a result of this change, but we intend to resolve
that problem in a subsequent commit.
When a commit contains a change from tracked to untracked or vice versa,
the log output can contain long lines of text. These cause a hang in
the log parser.
In each of our tests of the "git lfs prune" command
when it follows the "git stash" command, we add LFS
objects on a branch and stash them before the branch
is deleted. In all cases we expect the additional
stashed objects to be retained by "git lfs prune"
while unreferenced objects on the deleted branch are
pruned.
Note that these chnanges also ensure we are test
the "git lfs prune" command with multiple stashed
entries rather than just a single stash entry.
We add unreferenced LFS objects on a separate branch
to our tests of the "git lfs prune" command when it
follows a "git stash" command, and expect that in all
cases the unreferenced objects will be pruned.
We slightly reorder the assertions following the
"git stash" command in several of our tests of the
"git lfs prune" command so that the assertions are
made in the same order as the stashed modifications.
This will ease the addition of more assertions in
subsequent commits.
We also drop the unnecessary cleanup of the stash
and working tree at the end of one test.
When looking for Git LFS pointers in the Git stash in order
to avoid pruning the corresponding local objects during a
"git lfs prune" command, we want to avoid looking further
back in the Git log file than necessary; otherwise, we may
potentially find many LFS object references which we should
prune but incorrectly consider to be part of the stashes.
We therefore proceed in two steps; first looking solely
at each stash entry's WIP merge commit using the command
"git log -m --first-parent <stash-sha>^..<stash-sha>",
and then looking at each entry's index merge commit and
possible additional untracked files merge commit using
the command "git log <stash-sha>^..<stash-sha>". By
limiting these commands' commit ranges to just the stash
merge commits, we skip improperly traversing the full log.
We update the relevant tests to include older commits,
one of which should be pruned in each case; note that
with these changes the tests fail with the previous
version of the "git lfs prune" logic for stashes.
We also add stashes to two other tests and confirm that
in both cases the LFS objects from the stashed commits
are retained, but no additional objects are also
unexpectedly retained as a result of the stash.
Certain file paths are associated with diff textconv patterns with Git
for Windows, and these are invoked by default when using git log.
However, when we're using git log to scan data to find LFS objects, we
don't want to invoke those programs.
Let's fix this by passing appropriate options to disabled these
invocations. In the test, we set the driver to false, since Git will
fail if the process it calls also fails.
Some users really want to minimize the amount of data they store on the
local system, especially for large checkouts. Let's add two options,
--recent and --force, the former which ignores the recency settings and
the latter which additionally prunes objects which are currently checked
out. We will never prune objects that are unpushed, even with these
options, including stashed objects.
Add tests and documentation for both of these options.
Per PR advice from bk2204, we switch to using printf instead of
echo in the t-prune.go tests of stashed changes.
We also fixup one code comment to match the count of processes
in commands/command_prune.go.
It was impossible to pop a stash with LFS data successfully
after running any lfs prune command before this fix, because
prune would consider stashed data unreferenced.
This fixes#4206
Currently, our default branch in tests is "master". This is the Git
default, but the Git default will likely change in the future, so it
makes sense to update our testsuite to be explicit about the branch
name. We'll ensure this continues by building against older versions of
Git as well as newer versions.
We use "main" for the new branch name, since that's the proposed value
upstream.
This commit was made entirely by automated means using the following
command:
git grep -l master t | xargs sed -i -e 's/master/main/g'
We use package 'tasklog' to print progress messages to the command line
interface, as in the case of 'git-migrate-import(1)' or
'git-lfs-prune(1)'.
This package aims to mimic the style of upstream Git's progress log
lines, which are identical in every way, except for the trailing period
at the end of 'done'.
Git does print this period, but Git LFS does not. Let's make the two
more similar by having LFS print this period, too.
