We update the comment describing the scanRefsToChan() internal
function to match the one for the newer scanRefsToTree() function,
which was added in commit 608bc8d
in PR git-lfs#4525.  The older comment for the scanRefsToChan() function
has been out of sync with the function's actual signature and
usage since at least commit 3085dc3
in PR git-lfs#1743, when the function was changed to invoke a provided
callback instead of return a channel of pointer object wrappers.

We update the comment describing the scanRefsToChan() internal
function to match the one for the newer scanRefsToTree() function,
which was added in commit 608bc8d
in PR git-lfs#4525.  The older comment for the scanRefsToChan() function
has been out of sync with the function's actual signature and
usage since at least commit 3085dc3
in PR git-lfs#1743, when the function was changed to invoke a provided
callback instead of return a channel of pointer object wrappers.

The internal parseLogOutputToPointers) function was used only
by logPreviousSHAs() and only until commit
d8ca610 of PR git-lfs#1743 in 2016,
so we can remove it now.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files
referenced only by recent commits previous to a recent ref.
This could result in the unexpected consequence that an object
in HEAD would be pruned because it matched the "lfs.fetchexclude"
filter, but its previous version was not pruned.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects the
"lfs.fetchexclude" configuration option, that it applies it to all
files except those referenced by unpushed commits or stashes, and
that it uses gitignore(5)-style path matching, as per our change in
a prior commit in this PR.  This test will fail if gitattributes(5)-
tyle matching is used, and will also fail if files are not filtered
when they are referenced by recent previous commits.

Note that we also add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.

The internal parseLogOutputToPointers) function was used only
by logPreviousSHAs() and only until commit
d8ca610 of PR git-lfs#1743 in 2016,
so we can remove it now.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files
referenced only by recent commits previous to a recent ref.
This could result in the unexpected consequence that an object
in HEAD would be pruned because it matched the "lfs.fetchexclude"
filter, but its previous version was not pruned.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects the
"lfs.fetchexclude" configuration option, that it applies it to all
files except those referenced by unpushed commits or stashes, and
that it uses gitignore(5)-style path matching, as per our change in
a prior commit in this PR.  This test will fail if gitattributes(5)-
tyle matching is used, and will also fail if files are not filtered
when they are referenced by recent previous commits.

Note that we also add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.

The internal parseLogOutputToPointers) function was used only
by logPreviousSHAs() and only until commit
d8ca610 of PR git-lfs#1743 in 2016,
so we can remove it now.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files
referenced only by recent commits previous to a recent ref.
This could result in the unexpected consequence that an object
in HEAD would be pruned because it matched the "lfs.fetchexclude"
filter, but its previous version was not pruned.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects
the "lfs.fetchexclude" configuration option insofar as it prunes
Git LFS objects for files whose paths match a pattern in the filter,
both when they appear in commits directly referenced by a recent ref
and when they only appear in commits previous to those.

Our test also checks that "git lfs prune" applies the file using
gitignore(5)-style path matching, as per our change in a prior commit
in this PR.  This test will fail if gitattributes(5)-style matching
is used, and will also fail if files are not filtered when they
are referenced by recent previous commits.

Note that we also add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files
referenced only by recent commits previous to a recent ref.
This could result in the unexpected consequence that an object
in HEAD would be pruned because it matched the "lfs.fetchexclude"
filter, but its previous version was not pruned.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects
the "lfs.fetchexclude" configuration option insofar as it prunes
Git LFS objects for files whose paths match a pattern in the filter,
both when they appear in commits directly referenced by a recent ref
and when they only appear in commits previous to those.

Our test also checks that "git lfs prune" applies the file using
gitignore(5)-style path matching, as per our change in a prior commit
in this PR.  This test will fail if gitattributes(5)-style matching
is used, and will also fail if files are not filtered when they
are referenced by recent previous commits.

Note that we also add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.

The internal parseLogOutputToPointers() function was used only
by logPreviousSHAs() and only until commit
d8ca610 of PR git-lfs#1743 in 2016,
so we can remove it now.

The internal parseLogOutputToPointers() function was used only
by logPreviousSHAs() and only until commit
d8ca610 of PR git-lfs#1743 in 2016,
so we can remove it now.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files
referenced only by recent commits previous to a recent ref.
This could result in the unexpected consequence that an object
in HEAD would be pruned because it matched the "lfs.fetchexclude"
filter, but its previous version was not pruned.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects
the "lfs.fetchexclude" configuration option insofar as it prunes
Git LFS objects for files whose paths match a pattern in the filter,
both when they appear in commits directly referenced by a recent ref
and when they only appear in commits previous to those.

Our test also checks that "git lfs prune" applies the file using
gitignore(5)-style path matching, as per our change in a prior commit
in this PR.  This test will fail if gitattributes(5)-style matching
is used, and will also fail if files are not filtered when they
are referenced by recent previous commits.

Note that we also add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files referenced
only by recent commits previous to a recent ref.  This can result in
the unexpected consequence that an object in HEAD is pruned because
it is referenced only by a file that matches the "lfs.fetchexclude"
filter, but a recent previous version of the object is not pruned
despite also only being referenced by the same file.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects
the "lfs.fetchexclude" configuration option insofar as it prunes
Git LFS objects for files whose paths match a pattern in the filter,
both when they appear in commits directly referenced by a recent ref
and when they only appear in commits previous to those.

Note too that we add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.

In commit d2221dc of PR git-lfs#2851
the "git lfs prune" command was changed to respect the
"lfs.fetchexclude" configuration option such that objects would
always be pruned if they were referenced by files whose paths
matched one of the patterns in the configuration option (unless
they were referenced by an unpushed commit).

However, while this filter was applied to files referenced by
recent refs (including HEAD), it was not applied to files referenced
only by recent commits previous to a recent ref.  This can result in
the unexpected consequence that an object in HEAD is pruned because
it is referenced only by a file that matches the "lfs.fetchexclude"
filter, but a recent previous version of the object is not pruned
despite also only being referenced by the same file.

We therefore add equivalent filtering to the logPreviousSHAs()
internal function which is called by the ScanPreviousVersions()
GitScanner method used by pruneTaskGetPreviousVersionsOfRef()
in the "git lfs prune" command's main phase.

(Note that in PR git-lfs#1743 the Git log scanning functions were refactored,
and a common parseScannerLogOutput() internal function was created to
be used when performing log scans during "git lfs prune" commands.
This replaced the original logPreviousSHAs() function, which had
support for path-based filtering; however, that functionality was
apparently never used.)

We also add a test which confirms that "git lfs prune" respects
the "lfs.fetchexclude" configuration option insofar as it prunes
Git LFS objects for files whose paths match a pattern in the filter,
both when they appear in commits directly referenced by a recent ref
and when they only appear in commits previous to those.

Note too that we add one extra check to the existing "prune
unreferenced and old" test for consistency with our new test.