lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2ecc5533e1
git-lfs/t/t-prune.sh

1347 lines
53 KiB
Bash
Raw Normal View History

WIP prune tests
2015-10-09 15:55:19 +00:00
#!/usr/bin/env bash
t: load shell scripts from $(dirname) instead of 't'
2018-07-10 18:48:02 +00:00
. "$(dirname "$0")/testlib.sh"
WIP prune tests
2015-10-09 15:55:19 +00:00
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
begin_test "prune unreferenced and old"
WIP prune tests
2015-10-09 15:55:19 +00:00
(
set -e
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
reponame="prune_unref_old"
setup_remote_repo "remote_$reponame"
WIP prune tests
2015-10-09 15:55:19 +00:00
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
clone_repo "remote_$reponame" "clone_$reponame"
WIP prune tests
2015-10-09 15:55:19 +00:00
git lfs track "*.dat" 2>&1 | tee track.log
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
grep "Tracking \"\*.dat\"" track.log
WIP prune tests
2015-10-09 15:55:19 +00:00
# generate content we'll use
content_unreferenced="To delete: unreferenced"
content_oldandpushed="To delete: pushed and too old"
content_oldandunchanged="Keep: pushed and created a while ago, but still current"
oid_unreferenced=$(calc_oid "$content_unreferenced")
oid_oldandpushed=$(calc_oid "$content_oldandpushed")
oid_oldandunchanged=$(calc_oid "$content_oldandunchanged")
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
content_retain1="Retained content 1"
content_retain2="Retained content 2"
oid_retain1=$(calc_oid "$content_retain1")
oid_retain2=$(calc_oid "$content_retain2")
WIP prune tests
2015-10-09 15:55:19 +00:00
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
# Remember for something to be 'too old' it has to appear on the MINUS side
# of the diff outside the prune window, i.e. it's not when it was introduced
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
# but when it disappeared from relevance. That's why changes to old.dat on main
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
# from 7d ago are included even though the commit itself is outside of the window,
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
# that content of old.dat was relevant until it was removed with a commit, inside the window
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
# think of it as windows of relevance that overlap until the content is replaced
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
# we also make sure we commit today on main so that the recent commits measured
# from latest commit on main tracks back from there
WIP prune tests
2015-10-09 15:55:19 +00:00
echo "[
{
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
\"CommitDate\":\"$(get_date -20d)\",
WIP prune tests
2015-10-09 15:55:19 +00:00
\"Files\":[
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
{\"Filename\":\"old.dat\",\"Size\":${#content_oldandpushed}, \"Data\":\"$content_oldandpushed\"},
{\"Filename\":\"stillcurrent.dat\",\"Size\":${#content_oldandunchanged}, \"Data\":\"$content_oldandunchanged\"}]
WIP prune tests
2015-10-09 15:55:19 +00:00
},
{
\"CommitDate\":\"$(get_date -7d)\",
\"Files\":[
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
{\"Filename\":\"old.dat\",\"Size\":${#content_retain1}, \"Data\":\"$content_retain1\"}]
WIP prune tests
2015-10-09 15:55:19 +00:00
},
{
\"CommitDate\":\"$(get_date -4d)\",
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
\"NewBranch\":\"branch_to_delete\",
WIP prune tests
2015-10-09 15:55:19 +00:00
\"Files\":[
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
WIP prune tests
2015-10-09 15:55:19 +00:00
},
{
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
\"ParentBranches\":[\"main\"],
WIP prune tests
2015-10-09 15:55:19 +00:00
\"Files\":[
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
{\"Filename\":\"old.dat\",\"Size\":${#content_retain2}, \"Data\":\"$content_retain2\"}]
WIP prune tests
2015-10-09 15:55:19 +00:00
}
]" | lfstest-testutils addcommits
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git push origin main
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
git branch -D branch_to_delete
WIP prune tests
2015-10-09 15:55:19 +00:00
git config lfs.fetchrecentrefsdays 5
git config lfs.fetchrecentremoterefs true
git config lfs.fetchrecentcommitsdays 3
Fix typo in test setting, should be pruneoffsetdays not pruneoffset
2015-10-14 14:53:36 +00:00
git config lfs.pruneoffsetdays 2
WIP prune tests
2015-10-09 15:55:19 +00:00
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
git lfs prune --dry-run --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 5 local objects, 3 retained" prune.log
grep "prune: 2 files would be pruned" prune.log
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
grep "$oid_oldandpushed" prune.log
grep "$oid_unreferenced" prune.log
assert_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
assert_local_object "$oid_unreferenced" "${#content_unreferenced}"
git lfs prune
refute_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
refute_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
assert_local_object "$oid_oldandunchanged" "${#content_oldandunchanged}"
Moving to smaller tests for prune so cause for retention is clearer
2015-10-12 13:49:12 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
assert_local_object "$oid_retain2" "${#content_retain2}"
WIP prune tests
2015-10-09 15:55:19 +00:00
When lfs.fetchrecentcommitsdays=0 prune should prune previous commits This is to mirror what a manual full delete & fetch would do, should not keep previous versions (especially as this means overlapping the date so often you keep at least 1 previous version)
2015-10-12 15:58:26 +00:00
# now only keep AT refs, no recents
git config lfs.fetchrecentcommitsdays 0
commands: drop use of *Spinner in `git-lfs-prune(1)`
2017-11-28 03:31:32 +00:00
When lfs.fetchrecentcommitsdays=0 prune should prune previous commits This is to mirror what a manual full delete & fetch would do, should not keep previous versions (especially as this means overlapping the date so often you keep at least 1 previous version)
2015-10-12 15:58:26 +00:00
git lfs prune --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 3 local objects, 2 retained" prune.log
tasklog/log.go: print "done" messages with a trailing period 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.
2019-08-23 21:01:19 +00:00
grep "prune: Deleting objects: 100% (1/1), done." prune.log
When lfs.fetchrecentcommitsdays=0 prune should prune previous commits This is to mirror what a manual full delete & fetch would do, should not keep previous versions (especially as this means overlapping the date so often you keep at least 1 previous version)
2015-10-12 15:58:26 +00:00
grep "$oid_retain1" prune.log
refute_local_object "$oid_retain1"
assert_local_object "$oid_retain2" "${#content_retain2}"
WIP prune tests
2015-10-09 15:55:19 +00:00
)
end_test
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
begin_test "prune all excluded paths"
(
set -e
reponame="prune_unref_old_exclude"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
# generate content we'll use
content_oldandexcluded="To delete: pushed and too old and excluded by filter"
content_oldandunchanged="Keep: pushed and created a while ago, but still current"
content_prevandexcluded="To delete: pushed and in previous commit to HEAD but excluded by filter"
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
content_unreferencedandexcluded="To delete: unreferenced in deleted branch and pushed and excluded by filter"
content_includedandexcluded="Keep: pushed and both excluded by filter and included by another path"
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
content_excluded="To delete: pushed and in HEAD but excluded by filter"
oid_oldandexcluded=$(calc_oid "$content_oldandexcluded")
oid_oldandunchanged=$(calc_oid "$content_oldandunchanged")
oid_prevandexcluded=$(calc_oid "$content_prevandexcluded")
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
oid_unreferencedandexcluded=$(calc_oid "$content_unreferencedandexcluded")
oid_includedandexcluded=$(calc_oid "$content_includedandexcluded")
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
oid_excluded=$(calc_oid "$content_excluded")
echo "[
{
\"CommitDate\":\"$(get_date -20d)\",
\"Files\":[
{\"Filename\":\"foo/oldandexcluded.dat\",\"Size\":${#content_oldandexcluded}, \"Data\":\"$content_oldandexcluded\"},
{\"Filename\":\"stillcurrent.dat\",\"Size\":${#content_oldandunchanged}, \"Data\":\"$content_oldandunchanged\"}]
},
{
\"CommitDate\":\"$(get_date -7d)\",
\"Files\":[
{\"Filename\":\"foo/oldandexcluded.dat\",\"Size\":${#content_prevandexcluded}, \"Data\":\"$content_prevandexcluded\"}]
},
{
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
\"CommitDate\":\"$(get_date -4d)\",
\"NewBranch\":\"branch_to_delete\",
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
\"Files\":[
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferencedandexcluded}, \"Data\":\"$content_unreferencedandexcluded\"}]
},
{
\"ParentBranches\":[\"main\"],
\"Files\":[
{\"Filename\":\"foo/unreferencedandexcluded.dat\",\"Size\":${#content_unreferencedandexcluded}, \"Data\":\"$content_unreferencedandexcluded\"},
{\"Filename\":\"foo/includedandexcluded.dat\",\"Size\":${#content_includedandexcluded}, \"Data\":\"$content_includedandexcluded\"},
{\"Filename\":\"included.dat\",\"Size\":${#content_includedandexcluded}, \"Data\":\"$content_includedandexcluded\"},
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
{\"Filename\":\"foo/oldandexcluded.dat\",\"Size\":${#content_excluded}, \"Data\":\"$content_excluded\"}]
}
]" | lfstest-testutils addcommits
git push origin main
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
git branch -D branch_to_delete
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
git config lfs.fetchrecentrefsdays 5
git config lfs.fetchrecentremoterefs true
git config lfs.fetchrecentcommitsdays 3
git config lfs.pruneoffsetdays 2
# We need to prevent MSYS from rewriting /foo into a Windows path.
commands,t: gitignore matching for fetch filters The "lfs.fetchinclude" and "lfs.fetchexclude" Git configuration options, if set, are used to control the action of a number of Git LFS commands. Since PR #4556, the "git lfs clone", "git lfs fetch", and "git lfs pull" commands have strictly applied gitignore(5)-style matching rules to these configuration options. However, other commands including "git lfs filter-process" and "git lfs smudge" now apply gitattributes(5)-style matching rules to these same configuration options, leading to confusion. We therefore revise all remaining uses of these configuration options to also use gitignore-style matching rules. We also add new tests for the "git lfs filter-process" and "git lfs fsck" commands and adjust or expand existing tests for the "git lfs prune" and "git lfs smudge" commands in order to confirm that gitignore-style matching is used for all of them. These new and updated tests fail if gitattributes-style matching is used instead. (Note that the "git lfs migrate" command does not require any changes because it does not read the "lfs.fetch*" configuration options. Instead, it supplies a "false" value for the "useFetchOptions" flag to the determineIncludeExcludePaths() function, so any "lfs.fetch*" configuration values are ignored. This is significant because "git lfs migrate" deliberately uses gitattributes-style matching for any path patterns supplied via its -I/-X command-line arguments, unlike all other commands that accept -I/-X arguments as overrides for the "lfs.fetch*" configuration options.)
2022-04-18 07:24:53 +00:00
MSYS_NO_PATHCONV=1 git config "lfs.fetchexclude" "/foo"
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
git lfs prune --dry-run --verbose 2>&1 | tee prune.log
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
grep "prune: 6 local objects, 2 retained" prune.log
grep "prune: 4 files would be pruned" prune.log
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
grep "$oid_oldandexcluded" prune.log
grep "$oid_prevandexcluded" prune.log
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
grep "$oid_unreferencedandexcluded" prune.log
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
grep "$oid_excluded" prune.log
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
assert_local_object "$oid_oldandexcluded" "${#content_oldandexcluded}"
assert_local_object "$oid_prevandexcluded" "${#content_prevandexcluded}"
assert_local_object "$oid_unreferencedandexcluded" "${#content_unreferencedandexcluded}"
assert_local_object "$oid_excluded" "${#content_excluded}"
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
git lfs prune
refute_local_object "$oid_oldandexcluded" "${#content_oldandexcluded}"
assert_local_object "$oid_oldandunchanged" "${#content_oldandunchanged}"
refute_local_object "$oid_prevandexcluded" "${#content_prevandexcluded}"
commands,lfs,t: scan refs by tree when pruning In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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, this filter is applied using the GitScanner.ScanRef() method, which indirectly utilizes the internal scanRefsToChan() function, and that function only visits unique OIDs a single time each, even if they are referenced by multiple tree entries (i.e., if there are multiple files with the same content). This means that if an LFS object appears in both a file that matches a pattern from "lfs.fetchexclude" and in a file that does not match, the object may be pruned if the file path seen during the scan is the matching one regardless of whether the non-matching file would otherwise have its object retained. To resolve this we change the pruneTaskGetRetainedAtRef() function to use the GitScanner.ScanTree() method instead of ScanRef(), because ScanTree() visits all file paths in each commit. We need to pass our callback to the ScanTree() method so that we can save all non-matching files' OIDs into our list of OIDs to be retained; therefore we need to add a callback argument to ScanTree() in the same manner as is done for ScanRef() and various other GitScanner methods. We also introduce additional checks in our "prune all excluded paths" test to ensure that we always retain objects when they appear in a commit to be retained and at least one of the files referencing that object ID does not match the "lfs.fetchexclude" filter.
2022-04-22 07:14:28 +00:00
refute_local_object "$oid_unreferencedandexcluded" "${#content_unreferencedandexcluded}"
assert_local_object "$oid_includedandexcluded" "${#content_includedandexcluded}"
lfs,t: use prune exclude filter on previous SHAs In commit d2221dcecacc6a2ad38ffd2e429fca18805cb4ea of PR #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 #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.
2022-04-20 07:27:59 +00:00
refute_local_object "$oid_excluded" "${#content_excluded}"
)
end_test
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
begin_test "prune keep unpushed"
WIP prune tests
2015-10-09 15:55:19 +00:00
(
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
set -e
# need to set up many commits on each branch with old data so that would
# get deleted if it were not for unpushed status (heads would never be pruned but old changes would)
reponame="prune_keep_unpushed"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
grep "Tracking \"\*.dat\"" track.log
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
content_keepunpushedhead1="Keep: unpushed HEAD 1"
content_keepunpushedhead2="Keep: unpushed HEAD 2"
content_keepunpushedhead3="Keep: unpushed HEAD 3"
content_keepunpushedbranch1="Keep: unpushed second branch 1"
content_keepunpushedbranch2="Keep: unpushed second branch 2"
content_keepunpushedbranch3="Keep: unpushed second branch 3"
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
content_keepunpushedandexcludedbranch1="Keep: unpushed second branch 1 excluded by filter"
content_keepunpushedandexcludedbranch2="Keep: unpushed second branch 2 excluded by filter"
content_keepunpushedandexcludedbranch3="Keep: unpushed second branch 3 excluded by filter"
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
content_keepunpushedtag1="Keep: unpushed tag only 1"
content_keepunpushedtag2="Keep: unpushed tag only 2"
content_keepunpushedtag3="Keep: unpushed tag only 3"
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
oid_keepunpushedhead1=$(calc_oid "$content_keepunpushedhead1")
oid_keepunpushedhead2=$(calc_oid "$content_keepunpushedhead2")
oid_keepunpushedhead3=$(calc_oid "$content_keepunpushedhead3")
oid_keepunpushedbranch1=$(calc_oid "$content_keepunpushedbranch1")
oid_keepunpushedbranch2=$(calc_oid "$content_keepunpushedbranch2")
oid_keepunpushedbranch3=$(calc_oid "$content_keepunpushedbranch3")
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
oid_keepunpushedandexcludedbranch1=$(calc_oid "$content_keepunpushedandexcludedbranch1")
oid_keepunpushedandexcludedbranch2=$(calc_oid "$content_keepunpushedandexcludedbranch2")
oid_keepunpushedandexcludedbranch3=$(calc_oid "$content_keepunpushedandexcludedbranch3")
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
oid_keepunpushedtag1=$(calc_oid "$content_keepunpushedtag1")
oid_keepunpushedtag2=$(calc_oid "$content_keepunpushedtag2")
oid_keepunpushedtag3=$(calc_oid "$content_keepunpushedtag3")
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
echo "[
{
\"CommitDate\":\"$(get_date -40d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedhead1}, \"Data\":\"$content_keepunpushedhead1\"}]
},
{
\"CommitDate\":\"$(get_date -31d)\",
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
\"ParentBranches\":[\"main\"],
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
\"NewBranch\":\"branch_unpushed\",
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
\"Files\":[
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedbranch1}, \"Data\":\"$content_keepunpushedbranch1\"},
{\"Filename\":\"foo/file.dat\",\"Size\":${#content_keepunpushedandexcludedbranch1}, \"Data\":\"$content_keepunpushedandexcludedbranch1\"}]
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
},
{
\"CommitDate\":\"$(get_date -16d)\",
\"Files\":[
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedbranch2}, \"Data\":\"$content_keepunpushedbranch2\"},
{\"Filename\":\"foo/file.dat\",\"Size\":${#content_keepunpushedandexcludedbranch2}, \"Data\":\"$content_keepunpushedandexcludedbranch2\"}]
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
},
{
\"CommitDate\":\"$(get_date -2d)\",
\"Files\":[
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedbranch3}, \"Data\":\"$content_keepunpushedbranch3\"},
{\"Filename\":\"foo/file.dat\",\"Size\":${#content_keepunpushedandexcludedbranch3}, \"Data\":\"$content_keepunpushedandexcludedbranch3\"}]
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
},
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
{
\"CommitDate\":\"$(get_date -31d)\",
\"ParentBranches\":[\"main\"],
\"NewBranch\":\"branch_unpushed_tagged_only\",
\"Files\":[
{\"Filename\":\"file2.dat\",\"Size\":${#content_keepunpushedtag1}, \"Data\":\"$content_keepunpushedtag1\"}]
},
{
\"CommitDate\":\"$(get_date -16d)\",
\"Files\":[
{\"Filename\":\"file2.dat\",\"Size\":${#content_keepunpushedtag2}, \"Data\":\"$content_keepunpushedtag2\"}]
},
{
\"CommitDate\":\"$(get_date -2d)\",
\"Tags\":[\"tag_unpushed\"],
\"Files\":[
{\"Filename\":\"file2.dat\",\"Size\":${#content_keepunpushedtag3}, \"Data\":\"$content_keepunpushedtag3\"}]
},
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
{
\"CommitDate\":\"$(get_date -21d)\",
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
\"ParentBranches\":[\"main\"],
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedhead2}, \"Data\":\"$content_keepunpushedhead2\"}]
},
{
\"CommitDate\":\"$(get_date -0d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedhead3}, \"Data\":\"$content_keepunpushedhead3\"}]
}
]" | lfstest-testutils addcommits
git config lfs.fetchrecentrefsdays 5
git config lfs.fetchrecentremoterefs true
git config lfs.fetchrecentcommitsdays 0 # only keep AT refs, no recents
Fix typo in test setting, should be pruneoffsetdays not pruneoffset
2015-10-14 14:53:36 +00:00
git config lfs.pruneoffsetdays 2
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
# We need to prevent MSYS from rewriting /foo into a Windows path.
commands,t: gitignore matching for fetch filters The "lfs.fetchinclude" and "lfs.fetchexclude" Git configuration options, if set, are used to control the action of a number of Git LFS commands. Since PR #4556, the "git lfs clone", "git lfs fetch", and "git lfs pull" commands have strictly applied gitignore(5)-style matching rules to these configuration options. However, other commands including "git lfs filter-process" and "git lfs smudge" now apply gitattributes(5)-style matching rules to these same configuration options, leading to confusion. We therefore revise all remaining uses of these configuration options to also use gitignore-style matching rules. We also add new tests for the "git lfs filter-process" and "git lfs fsck" commands and adjust or expand existing tests for the "git lfs prune" and "git lfs smudge" commands in order to confirm that gitignore-style matching is used for all of them. These new and updated tests fail if gitattributes-style matching is used instead. (Note that the "git lfs migrate" command does not require any changes because it does not read the "lfs.fetch*" configuration options. Instead, it supplies a "false" value for the "useFetchOptions" flag to the determineIncludeExcludePaths() function, so any "lfs.fetch*" configuration values are ignored. This is significant because "git lfs migrate" deliberately uses gitattributes-style matching for any path patterns supplied via its -I/-X command-line arguments, unlike all other commands that accept -I/-X arguments as overrides for the "lfs.fetch*" configuration options.)
2022-04-18 07:24:53 +00:00
MSYS_NO_PATHCONV=1 git config "lfs.fetchexclude" "/foo"
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
t: test fetch/prune diff parsing with ANSI escapes 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.
2021-08-18 01:31:41 +00:00
# force color codes in git diff meta-information
git config color.diff always
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
git branch -D branch_unpushed_tagged_only
commands: drop use of *Spinner in `git-lfs-prune(1)`
2017-11-28 03:31:32 +00:00
git lfs prune
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
t/t-prune.sh: edit comments and drop unused prune We revise some of the comments in the "prune keep unpushed" test to clarify their meaning before we add additional checks to this test. We also drop an unused "git lfs prune --dry-run" invocation since we are not testing its output and therefore it serves no purpose in the test.
2022-04-24 23:03:39 +00:00
# Now push main and show that only older versions on main will be removed.
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git push origin main
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
git lfs prune --verbose 2>&1 | tee prune.log
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
grep "prune: 12 local objects, 10 retained" prune.log
tasklog/log.go: print "done" messages with a trailing period 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.
2019-08-23 21:01:19 +00:00
grep "prune: Deleting objects: 100% (2/2), done." prune.log
Test for retaining unpushed data
2015-10-12 15:59:38 +00:00
grep "$oid_keepunpushedhead1" prune.log
grep "$oid_keepunpushedhead2" prune.log
refute_local_object "$oid_keepunpushedhead1"
refute_local_object "$oid_keepunpushedhead2"
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
# Merge the unpushed branch and tag, delete them, and then push main.
t/t-prune.sh: edit comments and drop unused prune We revise some of the comments in the "prune keep unpushed" test to clarify their meaning before we add additional checks to this test. We also drop an unused "git lfs prune --dry-run" invocation since we are not testing its output and therefore it serves no purpose in the test.
2022-04-24 23:03:39 +00:00
# Resolve conflicts by taking other branch.
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
git merge -Xtheirs branch_unpushed
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
git merge tag_unpushed
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
git branch -D branch_unpushed
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
git tag -d tag_unpushed
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git push origin main
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
t/t-prune.sh: edit comments and drop unused prune We revise some of the comments in the "prune keep unpushed" test to clarify their meaning before we add additional checks to this test. We also drop an unused "git lfs prune --dry-run" invocation since we are not testing its output and therefore it serves no purpose in the test.
2022-04-24 23:03:39 +00:00
# Now make sure we purged all the intermediate commits but also make sure
# they are on the remote.
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
git lfs prune --verbose 2>&1 | tee prune.log
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
grep "prune: 10 local objects, 2 retained" prune.log
grep "prune: Deleting objects: 100% (8/8), done." prune.log
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
grep "$oid_keepunpushedbranch1" prune.log
grep "$oid_keepunpushedbranch2" prune.log
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
grep "$oid_keepunpushedandexcludedbranch1" prune.log
grep "$oid_keepunpushedandexcludedbranch2" prune.log
# This is in the new HEAD and would be retained except that it is also
# excluded by the filter and has been pushed, so it should have been purged.
grep "$oid_keepunpushedandexcludedbranch3" prune.log
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
grep "$oid_keepunpushedtag1" prune.log
grep "$oid_keepunpushedtag2" prune.log
Fix unpushed merge test
2015-10-14 11:51:30 +00:00
grep "$oid_keepunpushedhead3" prune.log
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
refute_local_object "$oid_keepunpushedbranch1"
refute_local_object "$oid_keepunpushedbranch2"
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
refute_local_object "$oid_keepunpushedandexcludedbranch1"
refute_local_object "$oid_keepunpushedandexcludedbranch2"
# This is in the new HEAD and would be retained except that it is also
# excluded by the filter and has been pushed, so it should have been purged.
refute_local_object "$oid_keepunpushedandexcludedbranch3"
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
refute_local_object "$oid_keepunpushedtag1"
refute_local_object "$oid_keepunpushedtag2"
t/t-prune.sh: edit comments and drop unused prune We revise some of the comments in the "prune keep unpushed" test to clarify their meaning before we add additional checks to this test. We also drop an unused "git lfs prune --dry-run" invocation since we are not testing its output and therefore it serves no purpose in the test.
2022-04-24 23:03:39 +00:00
# We used -Xtheirs when merging the branch so the old HEAD is now obsolete.
Add merge stage to unpushed test
2015-10-12 16:30:21 +00:00
refute_local_object "$oid_keepunpushedhead3"
assert_server_object "remote_$reponame" "$oid_keepunpushedbranch1"
assert_server_object "remote_$reponame" "$oid_keepunpushedbranch2"
t/t-prune.sh: check excluded but unpushed files The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR #2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
2022-04-24 23:31:17 +00:00
assert_server_object "remote_$reponame" "$oid_keepunpushedandexcludedbranch1"
assert_server_object "remote_$reponame" "$oid_keepunpushedandexcludedbranch2"
assert_server_object "remote_$reponame" "$oid_keepunpushedandexcludedbranch3"
t/t-prune.sh: add tag check to unpushed test In PR #742 the "git lfs prune" command was introduced along with accompanying tests, one of which is the "prune keep unpushed" test that checks whether Git LFS objects referenced by not-yet- pushed commits are always retained by "git lfs prune". In commit 978899e3b538bdd7df0873c2b50d229d5748605d of that PR the initial version of the "prune" tests included some fixture data with commits that were referenced via a tag only, not via a branch ref. However, the test never confirmed that the Git LFS objects in these commits were retained by the "prune" command. This initial test was then refactored into several tests in commits 03b85e08acf727428c4e9c0d805f5a8a3da501e7 and 58dfa23c9e87bd638eb2bd7b4c8e208eab8031e7, including the "prune keep unpushed" one, and in the process two lines were left which referred to the fixture data ("oid_keepunpushedtagged1" and "oid_keepunpushedtagged2") but this data was otherwise dropped from the test, and no tag check was implemented. We therefore re-introduce some fixture data for this test which simulates a tag that points to a commit from a deleted branch, so that the tag is the only reference to this commit and its ancestors. We then ensure that "git lfs prune" retains all the Git LFS objects from these commits, even if they are not recent, when they have not been pushed. Once they are pushed, we then confirm that only the object in the tagged commit is retained (because it is a referenced by a recent ref). We also update a comment in the "prune unreferenced and old" test which refers to a filename in its fixture data that corresponds to how it was originally defined in commit 978899e3b538bdd7df0873c2b50d229d5748605d, but which was subsequently changed (at the same time the comment was added) in commit 03b85e08acf727428c4e9c0d805f5a8a3da501e7.
2022-04-24 23:14:58 +00:00
assert_server_object "remote_$reponame" "$oid_keepunpushedtag1"
assert_server_object "remote_$reponame" "$oid_keepunpushedtag2"
Fix unpushed merge test
2015-10-14 11:51:30 +00:00
assert_server_object "remote_$reponame" "$oid_keepunpushedhead3"
WIP prune tests
2015-10-09 15:55:19 +00:00
)
end_test
Test for prune with recent options
2015-10-14 14:54:09 +00:00
begin_test "prune keep recent"
(
set -e
reponame="prune_recent"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
grep "Tracking \"\*.dat\"" track.log
Test for prune with recent options
2015-10-14 14:54:09 +00:00
content_keephead="Keep: HEAD"
content_keeprecentbranch1tip="Keep: Recent branch 1 tip"
content_keeprecentbranch2tip="Keep: Recent branch 2 tip"
content_keeprecentcommithead="Keep: Recent commit on HEAD"
content_keeprecentcommitbranch1="Keep: Recent commit on recent branch 1"
content_keeprecentcommitbranch2="Keep: Recent commit on recent branch 2"
content_prunecommitoldbranch1="Prune: old commit on old branch"
content_prunecommitoldbranch2="Prune: old branch tip"
content_prunecommitbranch1="Prune: old commit on recent branch 1"
content_prunecommitbranch2="Prune: old commit on recent branch 2"
content_prunecommithead="Prune: old commit on HEAD"
oid_keephead=$(calc_oid "$content_keephead")
oid_keeprecentbranch1tip=$(calc_oid "$content_keeprecentbranch1tip")
oid_keeprecentbranch2tip=$(calc_oid "$content_keeprecentbranch2tip")
oid_keeprecentcommithead=$(calc_oid "$content_keeprecentcommithead")
oid_keeprecentcommitbranch1=$(calc_oid "$content_keeprecentcommitbranch1")
oid_keeprecentcommitbranch2=$(calc_oid "$content_keeprecentcommitbranch2")
oid_prunecommitoldbranch=$(calc_oid "$content_prunecommitoldbranch1")
oid_prunecommitoldbranch2=$(calc_oid "$content_prunecommitoldbranch2")
oid_prunecommitbranch1=$(calc_oid "$content_prunecommitbranch1")
oid_prunecommitbranch2=$(calc_oid "$content_prunecommitbranch2")
oid_prunecommithead=$(calc_oid "$content_prunecommithead")
Fix typos
2022-01-05 06:49:08 +00:00
# use a single file so each commit supersedes the last, if different files
Test for prune with recent options
2015-10-14 14:54:09 +00:00
# then history becomes harder to track
# Also note that when considering 'recent' when editing a single file, it means
# that the snapshot state overlapped; so the latest commit *before* the day
# that you're looking at, not just the commits on/after.
echo "[
{
\"CommitDate\":\"$(get_date -50d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_prunecommithead}, \"Data\":\"$content_prunecommithead\"}]
},
{
\"CommitDate\":\"$(get_date -30d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keeprecentcommithead}, \"Data\":\"$content_keeprecentcommithead\"}]
},
{
\"CommitDate\":\"$(get_date -8d)\",
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
\"NewBranch\":\"branch_old\",
Test for prune with recent options
2015-10-14 14:54:09 +00:00
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_prunecommitoldbranch1}, \"Data\":\"$content_prunecommitoldbranch1\"}]
},
{
\"CommitDate\":\"$(get_date -7d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_prunecommitoldbranch2}, \"Data\":\"$content_prunecommitoldbranch2\"}]
},
{
\"CommitDate\":\"$(get_date -9d)\",
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
\"ParentBranches\":[\"main\"],
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
\"NewBranch\":\"branch1\",
Test for prune with recent options
2015-10-14 14:54:09 +00:00
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_prunecommitbranch1}, \"Data\":\"$content_prunecommitbranch1\"}]
},
{
\"CommitDate\":\"$(get_date -8d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keeprecentcommitbranch1}, \"Data\":\"$content_keeprecentcommitbranch1\"}]
},
{
\"CommitDate\":\"$(get_date -5d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keeprecentbranch1tip}, \"Data\":\"$content_keeprecentbranch1tip\"}]
},
{
\"CommitDate\":\"$(get_date -17d)\",
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
\"ParentBranches\":[\"main\"],
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
\"NewBranch\":\"branch2\",
Test for prune with recent options
2015-10-14 14:54:09 +00:00
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_prunecommitbranch2}, \"Data\":\"$content_prunecommitbranch2\"}]
},
{
\"CommitDate\":\"$(get_date -10d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keeprecentcommitbranch2}, \"Data\":\"$content_keeprecentcommitbranch2\"}]
},
{
\"CommitDate\":\"$(get_date -2d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keeprecentbranch2tip}, \"Data\":\"$content_keeprecentbranch2tip\"}]
},
{
\"CommitDate\":\"$(get_date -1d)\",
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
\"ParentBranches\":[\"main\"],
Test for prune with recent options
2015-10-14 14:54:09 +00:00
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keephead}, \"Data\":\"$content_keephead\"}]
}
]" | lfstest-testutils addcommits
# keep refs for 6 days & any prev commit that overlaps 2 days before tip (recent + offset)
git config lfs.fetchrecentrefsdays 5
git config lfs.fetchrecentremoterefs true
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
git config lfs.fetchrecentcommitsdays 1
Test for prune with recent options
2015-10-14 14:54:09 +00:00
git config lfs.pruneoffsetdays 1
t: test fetch/prune diff parsing with ANSI escapes 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.
2021-08-18 01:31:41 +00:00
# force color codes in git diff meta-information
git config color.diff always
Test for prune with recent options
2015-10-14 14:54:09 +00:00
# push everything so that's not a reason to retain
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git push origin main:main branch_old:branch_old branch1:branch1 branch2:branch2
Test for prune with recent options
2015-10-14 14:54:09 +00:00
git lfs prune --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 11 local objects, 6 retained, done." prune.log
tasklog/log.go: print "done" messages with a trailing period 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.
2019-08-23 21:01:19 +00:00
grep "prune: Deleting objects: 100% (5/5), done." prune.log
Test for prune with recent options
2015-10-14 14:54:09 +00:00
grep "$oid_prunecommitoldbranch" prune.log
grep "$oid_prunecommitoldbranch2" prune.log
grep "$oid_prunecommitbranch1" prune.log
grep "$oid_prunecommitbranch2" prune.log
grep "$oid_prunecommithead" prune.log
refute_local_object "$oid_prunecommitoldbranch"
refute_local_object "$oid_prunecommitoldbranch2"
refute_local_object "$oid_prunecommitbranch1"
refute_local_object "$oid_prunecommitbranch2"
refute_local_object "$oid_prunecommithead"
assert_local_object "$oid_keephead" "${#content_keephead}"
assert_local_object "$oid_keeprecentbranch1tip" "${#content_keeprecentbranch1tip}"
assert_local_object "$oid_keeprecentbranch2tip" "${#content_keeprecentbranch2tip}"
assert_local_object "$oid_keeprecentcommithead" "${#content_keeprecentcommithead}"
assert_local_object "$oid_keeprecentcommitbranch1" "${#content_keeprecentcommitbranch1}"
assert_local_object "$oid_keeprecentcommitbranch2" "${#content_keeprecentcommitbranch2}"
Test turning off the recent options & make sure more data pruned
2015-10-14 14:58:12 +00:00
# now don't include any recent commits in fetch & hence don't retain
# still retain tips of branches
git config lfs.fetchrecentcommitsdays 0
git lfs prune --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 6 local objects, 3 retained, done." prune.log
tasklog/log.go: print "done" messages with a trailing period 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.
2019-08-23 21:01:19 +00:00
grep "prune: Deleting objects: 100% (3/3), done." prune.log
Test turning off the recent options & make sure more data pruned
2015-10-14 14:58:12 +00:00
assert_local_object "$oid_keephead" "${#content_keephead}"
assert_local_object "$oid_keeprecentbranch1tip" "${#content_keeprecentbranch1tip}"
assert_local_object "$oid_keeprecentbranch2tip" "${#content_keeprecentbranch2tip}"
refute_local_object "$oid_keeprecentcommithead"
refute_local_object "$oid_keeprecentcommitbranch1"
refute_local_object "$oid_keeprecentcommitbranch2"
# now don't include any recent refs at all, only keep HEAD
git config lfs.fetchrecentrefsdays 0
git lfs prune --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 3 local objects, 1 retained, done." prune.log
tasklog/log.go: print "done" messages with a trailing period 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.
2019-08-23 21:01:19 +00:00
grep "prune: Deleting objects: 100% (2/2), done." prune.log
Test turning off the recent options & make sure more data pruned
2015-10-14 14:58:12 +00:00
assert_local_object "$oid_keephead" "${#content_keephead}"
refute_local_object "$oid_keeprecentbranch1tip"
refute_local_object "$oid_keeprecentbranch2tip"
Test for prune with recent options
2015-10-14 14:54:09 +00:00
)
end_test
Tidy up tests for remotes
2015-10-15 13:33:46 +00:00
begin_test "prune remote tests"
WIP prune tests
2015-10-09 15:55:19 +00:00
(
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
set -e
reponame="prune_no_or_nonorigin_remote"
git init "$reponame"
cd "$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
grep "Tracking \"\*.dat\"" track.log
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
echo "[
{
\"CommitDate\":\"$(get_date -50d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":30}]
},
{
\"CommitDate\":\"$(get_date -40d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":28}]
},
{
\"CommitDate\":\"$(get_date -35d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":37}]
},
{
\"CommitDate\":\"$(get_date -25d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":42}]
}
]" | lfstest-testutils addcommits
# set no recents so max ability to prune normally
git config lfs.fetchrecentrefsdays 0
git config lfs.fetchrecentremoterefs true
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
git config lfs.fetchrecentcommitsdays 0
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
git config lfs.pruneoffsetdays 1
Tidy up tests for remotes
2015-10-15 13:33:46 +00:00
# can never prune with no remote
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
git lfs prune --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 4 retained, done." prune.log
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
# also make sure nothing is pruned when remote is not origin
# create 2 remotes, neither of which is called origin & push to both
setup_remote_repo "remote1_$reponame"
setup_remote_repo "remote2_$reponame"
cd "$TRASHDIR/$reponame"
git remote add not_origin "$GITSERVER/remote1_$reponame"
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git push not_origin main
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
git lfs prune --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 4 retained, done." prune.log
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
# now set the prune remote to be not_origin, should now prune
Tidy up tests for remotes
2015-10-15 13:33:46 +00:00
# do a dry run so we can also verify
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
git config lfs.pruneremotetocheck not_origin
Tidy up tests for remotes
2015-10-15 13:33:46 +00:00
git lfs prune --verbose --dry-run 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 1 retained, done." prune.log
grep "prune: 3 files would be pruned" prune.log
WIP prune tests
2015-10-09 15:55:19 +00:00
)
end_test
Prune tests for unpushed with variable remote conditions
2015-10-15 09:58:34 +00:00
begin_test "prune verify"
WIP prune tests
2015-10-09 15:55:19 +00:00
(
Tests for the --verify-remote option
2015-10-15 13:43:11 +00:00
set -e
reponame="prune_verify"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
grep "Tracking \"\*.dat\"" track.log
Tests for the --verify-remote option
2015-10-15 13:43:11 +00:00
content_head="HEAD content"
content_commit3="Content for commit 3 (prune)"
content_commit2_failverify="Content for commit 2 (prune - fail verify)"
content_commit1="Content for commit 1 (prune)"
oid_head=$(calc_oid "$content_head")
oid_commit3=$(calc_oid "$content_commit3")
oid_commit2_failverify=$(calc_oid "$content_commit2_failverify")
oid_commit1=$(calc_oid "$content_commit1")
echo "[
{
\"CommitDate\":\"$(get_date -50d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_commit1}, \"Data\":\"$content_commit1\"}]
},
{
\"CommitDate\":\"$(get_date -40d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_commit2_failverify}, \"Data\":\"$content_commit2_failverify\"}]
},
{
\"CommitDate\":\"$(get_date -35d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_commit3}, \"Data\":\"$content_commit3\"}]
},
{
\"CommitDate\":\"$(get_date -25d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_head}, \"Data\":\"$content_head\"}]
}
]" | lfstest-testutils addcommits
# push all so no unpushed reason to not prune
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git push origin main
Tests for the --verify-remote option
2015-10-15 13:43:11 +00:00
# set no recents so max ability to prune normally
git config lfs.fetchrecentrefsdays 0
git config lfs.fetchrecentremoterefs true
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
git config lfs.fetchrecentcommitsdays 0
Tests for the --verify-remote option
2015-10-15 13:43:11 +00:00
git config lfs.pruneoffsetdays 1
# confirm that it would prune with verify when no issues
git lfs prune --dry-run --verify-remote --verbose 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 1 retained, 3 verified with remote, done." prune.log
grep "prune: 3 files would be pruned" prune.log
Tests for the --verify-remote option
2015-10-15 13:43:11 +00:00
grep "$oid_commit3" prune.log
grep "$oid_commit2_failverify" prune.log
grep "$oid_commit1" prune.log
# delete one file on the server to make the verify fail
delete_server_object "remote_$reponame" "$oid_commit2_failverify"
# this should now fail
git lfs prune --verify-remote 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 1 retained, 2 verified with remote, done." prune.log
Tests for the --verify-remote option
2015-10-15 13:43:11 +00:00
grep "missing on remote:" prune.log
grep "$oid_commit2_failverify" prune.log
# Nothing should have been deleted
assert_local_object "$oid_commit1" "${#content_commit1}"
assert_local_object "$oid_commit2_failverify" "${#content_commit2_failverify}"
assert_local_object "$oid_commit3" "${#content_commit3}"
Test verify remote via config, and overriding it on cmdline
2015-10-15 13:49:19 +00:00
# Now test with the global option
git config lfs.pruneverifyremotealways true
# no verify arg but should be pulled from global
git lfs prune 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 1 retained, 2 verified with remote, done." prune.log
Test verify remote via config, and overriding it on cmdline
2015-10-15 13:49:19 +00:00
grep "missing on remote:" prune.log
grep "$oid_commit2_failverify" prune.log
# Nothing should have been deleted
assert_local_object "$oid_commit1" "${#content_commit1}"
assert_local_object "$oid_commit2_failverify" "${#content_commit2_failverify}"
assert_local_object "$oid_commit3" "${#content_commit3}"
# now try overriding the global option
git lfs prune --no-verify-remote 2>&1 | tee prune.log
commands/prune: make strings translatable
2021-12-13 19:27:02 +00:00
grep "prune: 4 local objects, 1 retained, done." prune.log
tasklog/log.go: print "done" messages with a trailing period 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.
2019-08-23 21:01:19 +00:00
grep "prune: Deleting objects: 100% (3/3), done." prune.log
Test verify remote via config, and overriding it on cmdline
2015-10-15 13:49:19 +00:00
# should now have been deleted
refute_local_object "$oid_commit1"
refute_local_object "$oid_commit2_failverify"
refute_local_object "$oid_commit3"
Adding integration test for #1860
2017-01-17 04:38:31 +00:00
)
end_test
begin_test "prune verify large numbers of refs"
(
set -e
reponame="prune_verify_large"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
grep "Tracking \"\*.dat\"" track.log
Adding integration test for #1860
2017-01-17 04:38:31 +00:00
content_head="HEAD content"
content_commit1="Recent commit"
content_oldcommit="Old content"
oid_head=$(calc_oid "$content_head")
# Add two recent commits that should not be pruned
echo "[
{
\"CommitDate\":\"$(get_date -50d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_oldcommit}, \"Data\":\"$(uuidgen)\"}]
},
{
\"CommitDate\":\"$(get_date -45d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_oldcommit}, \"Data\":\"$(uuidgen)\"}]
},
{
\"CommitDate\":\"$(get_date -2d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_commit1}, \"Data\":\"$content_commit1\"}]
},
{
\"CommitDate\":\"$(get_date -1d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_head}, \"Data\":\"$content_head\"}]
}
]" | lfstest-testutils addcommits
# Generate a large number of refs to old commits make sure prune has a lot of data to read
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git checkout $(git log --pretty=oneline main | tail -2 | awk '{print $1}' | head -1)
Adding integration test for #1860
2017-01-17 04:38:31 +00:00
for i in $(seq 0 1000); do
git tag v$i
done
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
git checkout main
Adding integration test for #1860
2017-01-17 04:38:31 +00:00
# push all so no unpushed reason to not prune
Rename default branch in tests to "main" 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'
2020-06-29 16:18:57 +00:00
# git push origin main
Adding integration test for #1860
2017-01-17 04:38:31 +00:00
# set no recents so max ability to prune normally
git config lfs.fetchrecentrefsdays 3
git config lfs.fetchrecentremoterefs true
git config lfs.fetchrecentcommitsdays 3
git config lfs.pruneoffsetdays 3
# confirm that prune does not hang
git lfs prune --dry-run --verify-remote --verbose 2>&1 | tee prune.log
WIP prune tests
2015-10-09 15:55:19 +00:00
)
commands/track: quote pattern in output of track command
2017-03-24 16:59:03 +00:00
end_test
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
begin_test "prune keep stashed changes"
(
set -e
reponame="prune_keep_stashed"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
# generate content we'll use
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_oldandpushed="To delete: pushed and too old"
oid_oldandpushed=$(calc_oid "$content_oldandpushed")
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
content_unreferenced="To delete: unreferenced"
oid_unreferenced=$(calc_oid "$content_unreferenced")
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_retain1="Retained content 1"
oid_retain1=$(calc_oid "$content_retain1")
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
content_inrepo="This is the original committed data"
oid_inrepo=$(calc_oid "$content_inrepo")
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_stashedandexcluded="This data will be stashed and should not be deleted despite being excluded"
oid_stashedandexcluded=$(calc_oid "$content_stashedandexcluded")
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
content_stashedbranch="This data will be stashed on a branch and should not be deleted"
oid_stashedbranch=$(calc_oid "$content_stashedbranch")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_stashedandexcludedbranch="This data will be stashed on a branch and should not be deleted despite being excluded"
oid_stashedandexcludedbranch=$(calc_oid "$content_stashedandexcludedbranch")
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# We need to test with older commits to ensure they get pruned as expected
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
echo "[
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
{
\"CommitDate\":\"$(get_date -20d)\",
\"Files\":[
{\"Filename\":\"old.dat\",\"Size\":${#content_oldandpushed}, \"Data\":\"$content_oldandpushed\"}]
},
{
\"CommitDate\":\"$(get_date -7d)\",
\"Files\":[
{\"Filename\":\"old.dat\",\"Size\":${#content_retain1}, \"Data\":\"$content_retain1\"}]
},
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
{
\"CommitDate\":\"$(get_date -4d)\",
\"NewBranch\":\"branch_to_delete\",
\"Files\":[
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"},
{\"Filename\":\"foo/unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
},
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
{
\"CommitDate\":\"$(get_date -1d)\",
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
\"ParentBranches\":[\"main\"],
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
\"Files\":[
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
{\"Filename\":\"stashedfile.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"},
{\"Filename\":\"foo/stashedfile.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"}]
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
}
]" | lfstest-testutils addcommits
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
git push origin main
assert_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
assert_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# now modify the files, and stash them
t/t-prune.go: prefer printf to echo 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.
2020-09-03 23:29:22 +00:00
printf '%s' "$content_stashed" > stashedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_stashedandexcluded" > foo/stashedfile.dat
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git stash
Hopefully final whitespace fix up
2020-08-10 08:48:39 +00:00
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# Switch to a branch, modify files, stash them, and delete the branch.
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git checkout branch_to_delete
printf '%s' "$content_stashedbranch" > unreferenced.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_stashedandexcludedbranch" > foo/unreferenced.dat
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
git stash
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git checkout main
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
git branch -D branch_to_delete
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
# Prove that the stashed data was stored in LFS (should call clean filter)
assert_local_object "$oid_stashed" "${#content_stashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcluded" "${#content_stashedandexcluded}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcludedbranch" "${#content_stashedandexcludedbranch}"
# We need to prevent MSYS from rewriting /foo into a Windows path.
commands,t: gitignore matching for fetch filters The "lfs.fetchinclude" and "lfs.fetchexclude" Git configuration options, if set, are used to control the action of a number of Git LFS commands. Since PR #4556, the "git lfs clone", "git lfs fetch", and "git lfs pull" commands have strictly applied gitignore(5)-style matching rules to these configuration options. However, other commands including "git lfs filter-process" and "git lfs smudge" now apply gitattributes(5)-style matching rules to these same configuration options, leading to confusion. We therefore revise all remaining uses of these configuration options to also use gitignore-style matching rules. We also add new tests for the "git lfs filter-process" and "git lfs fsck" commands and adjust or expand existing tests for the "git lfs prune" and "git lfs smudge" commands in order to confirm that gitignore-style matching is used for all of them. These new and updated tests fail if gitattributes-style matching is used instead. (Note that the "git lfs migrate" command does not require any changes because it does not read the "lfs.fetch*" configuration options. Instead, it supplies a "false" value for the "useFetchOptions" flag to the determineIncludeExcludePaths() function, so any "lfs.fetch*" configuration values are ignored. This is significant because "git lfs migrate" deliberately uses gitattributes-style matching for any path patterns supplied via its -I/-X command-line arguments, unlike all other commands that accept -I/-X arguments as overrides for the "lfs.fetch*" configuration options.)
2022-04-18 07:24:53 +00:00
MSYS_NO_PATHCONV=1 git config "lfs.fetchexclude" "/foo"
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
t: test fetch/prune diff parsing with ANSI escapes 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.
2021-08-18 01:31:41 +00:00
# force color codes in git diff meta-information
git config color.diff always
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
# Prune data, should NOT delete stashed files
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
git lfs prune
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
refute_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
refute_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcluded" "${#content_stashedandexcluded}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcludedbranch" "${#content_stashedandexcludedbranch}"
prune: fix deleting objects referred to by stashes 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
2020-08-07 15:48:59 +00:00
)
Add trailing newline in test, was breaking cibuild
2020-08-08 10:12:09 +00:00
end_test
cibuild still failing on whitespace, needs another blank line?
2020-08-08 10:27:46 +00:00
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
begin_test "prune keep stashed changes in index"
(
set -e
reponame="prune_keep_stashed_index"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
# generate content we'll use
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_oldandpushed="To delete: pushed and too old"
oid_oldandpushed=$(calc_oid "$content_oldandpushed")
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
content_unreferenced="To delete: unreferenced"
oid_unreferenced=$(calc_oid "$content_unreferenced")
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_retain1="Retained content 1"
oid_retain1=$(calc_oid "$content_retain1")
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
content_inrepo="This is the original committed data"
oid_inrepo=$(calc_oid "$content_inrepo")
content_indexstashed="This data will be stashed from the index and should not be deleted"
oid_indexstashed=$(calc_oid "$content_indexstashed")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_indexstashedandexcluded="This data will be stashed from the index and should not be deleted despite being excluded"
oid_indexstashedandexcluded=$(calc_oid "$content_indexstashedandexcluded")
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_stashedandexcluded="This data will be stashed and should not be deleted despite being excluded"
oid_stashedandexcluded=$(calc_oid "$content_stashedandexcluded")
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
content_indexstashedbranch="This data will be stashed on a branch from the index and should not be deleted"
oid_indexstashedbranch=$(calc_oid "$content_indexstashedbranch")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_indexstashedandexcludedbranch="This data will be stashed on a branch from the index and should not be deleted despite being excluded"
oid_indexstashedandexcludedbranch=$(calc_oid "$content_indexstashedandexcludedbranch")
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
content_stashedbranch="This data will be stashed on a branch and should not be deleted"
oid_stashedbranch=$(calc_oid "$content_stashedbranch")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_stashedandexcludedbranch="This data will be stashed on a branch and should not be deleted despite being excluded"
oid_stashedandexcludedbranch=$(calc_oid "$content_stashedandexcludedbranch")
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# We need to test with older commits to ensure they get pruned as expected
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
echo "[
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
{
\"CommitDate\":\"$(get_date -20d)\",
\"Files\":[
{\"Filename\":\"old.dat\",\"Size\":${#content_oldandpushed}, \"Data\":\"$content_oldandpushed\"}]
},
{
\"CommitDate\":\"$(get_date -7d)\",
\"Files\":[
{\"Filename\":\"old.dat\",\"Size\":${#content_retain1}, \"Data\":\"$content_retain1\"}]
},
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
{
\"CommitDate\":\"$(get_date -4d)\",
\"NewBranch\":\"branch_to_delete\",
\"Files\":[
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"},
{\"Filename\":\"foo/unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
},
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
{
\"CommitDate\":\"$(get_date -1d)\",
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
\"ParentBranches\":[\"main\"],
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
\"Files\":[
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
{\"Filename\":\"stashedfile.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"},
{\"Filename\":\"foo/stashedfile.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"}]
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
}
]" | lfstest-testutils addcommits
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
git push origin main
assert_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
assert_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# now modify the files, and add them to the index
t/t-prune.go: prefer printf to echo 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.
2020-09-03 23:29:22 +00:00
printf '%s' "$content_indexstashed" > stashedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_indexstashedandexcluded" > foo/stashedfile.dat
git add stashedfile.dat foo/stashedfile.dat
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# now modify the files again, and stash them
t/t-prune.go: prefer printf to echo 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.
2020-09-03 23:29:22 +00:00
printf '%s' "$content_stashed" > stashedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_stashedandexcluded" > foo/stashedfile.dat
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git stash
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# Switch to a branch, modify files in the index and working tree, stash them,
# and delete the branch.
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git checkout branch_to_delete
printf '%s' "$content_indexstashedbranch" > unreferenced.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_indexstashedandexcludedbranch" > foo/unreferenced.dat
git add unreferenced.dat foo/unreferenced.dat
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
printf '%s' "$content_stashedbranch" > unreferenced.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_stashedandexcludedbranch" > foo/unreferenced.dat
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
git stash
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git checkout main
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
git branch -D branch_to_delete
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
# Prove that the stashed data was stored in LFS (should call clean filter)
assert_local_object "$oid_indexstashed" "${#content_indexstashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcluded" "${#content_indexstashedandexcluded}"
t: reorder prune stash checks to match actions 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.
2021-03-24 05:34:45 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcluded" "${#content_stashedandexcluded}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_indexstashedbranch" "${#content_indexstashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcludedbranch" "${#content_indexstashedandexcludedbranch}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcludedbranch" "${#content_stashedandexcludedbranch}"
# We need to prevent MSYS from rewriting /foo into a Windows path.
commands,t: gitignore matching for fetch filters The "lfs.fetchinclude" and "lfs.fetchexclude" Git configuration options, if set, are used to control the action of a number of Git LFS commands. Since PR #4556, the "git lfs clone", "git lfs fetch", and "git lfs pull" commands have strictly applied gitignore(5)-style matching rules to these configuration options. However, other commands including "git lfs filter-process" and "git lfs smudge" now apply gitattributes(5)-style matching rules to these same configuration options, leading to confusion. We therefore revise all remaining uses of these configuration options to also use gitignore-style matching rules. We also add new tests for the "git lfs filter-process" and "git lfs fsck" commands and adjust or expand existing tests for the "git lfs prune" and "git lfs smudge" commands in order to confirm that gitignore-style matching is used for all of them. These new and updated tests fail if gitattributes-style matching is used instead. (Note that the "git lfs migrate" command does not require any changes because it does not read the "lfs.fetch*" configuration options. Instead, it supplies a "false" value for the "useFetchOptions" flag to the determineIncludeExcludePaths() function, so any "lfs.fetch*" configuration values are ignored. This is significant because "git lfs migrate" deliberately uses gitattributes-style matching for any path patterns supplied via its -I/-X command-line arguments, unlike all other commands that accept -I/-X arguments as overrides for the "lfs.fetch*" configuration options.)
2022-04-18 07:24:53 +00:00
MSYS_NO_PATHCONV=1 git config "lfs.fetchexclude" "/foo"
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
t: test fetch/prune diff parsing with ANSI escapes 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.
2021-08-18 01:31:41 +00:00
# force color codes in git diff meta-information
git config color.diff always
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
# Prune data, should NOT delete stashed file or stashed changes to index
git lfs prune
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
refute_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
refute_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
assert_local_object "$oid_indexstashed" "${#content_indexstashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcluded" "${#content_indexstashedandexcluded}"
t: reorder prune stash checks to match actions 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.
2021-03-24 05:34:45 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcluded" "${#content_stashedandexcluded}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_indexstashedbranch" "${#content_indexstashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcludedbranch" "${#content_indexstashedandexcludedbranch}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcludedbranch" "${#content_stashedandexcludedbranch}"
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
)
end_test
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
begin_test "prune keep stashed untracked files"
(
set -e
reponame="prune_keep_stashed_untracked"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
# Commit .gitattributes first so it is not removed by "git stash -u" and then
# not restored when we checkout the branch and try to modify LFS objects.
git add .gitattributes
git commit -m attribs
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
# generate content we'll use
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_oldandpushed="To delete: pushed and too old"
oid_oldandpushed=$(calc_oid "$content_oldandpushed")
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
content_unreferenced="To delete: unreferenced"
oid_unreferenced=$(calc_oid "$content_unreferenced")
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_retain1="Retained content 1"
oid_retain1=$(calc_oid "$content_retain1")
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
content_inrepo="This is the original committed data"
oid_inrepo=$(calc_oid "$content_inrepo")
content_indexstashed="This data will be stashed from the index and should not be deleted"
oid_indexstashed=$(calc_oid "$content_indexstashed")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_indexstashedandexcluded="This data will be stashed from the index and should not be deleted despite being excluded"
oid_indexstashedandexcluded=$(calc_oid "$content_indexstashedandexcluded")
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_stashedandexcluded="This data will be stashed and should not be deleted despite being excluded"
oid_stashedandexcluded=$(calc_oid "$content_stashedandexcluded")
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
content_untrackedstashed="This UNTRACKED FILE data will be stashed and should not be deleted"
oid_untrackedstashed=$(calc_oid "$content_untrackedstashed")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_untrackedstashedandexcluded="This UNTRACKED FILE data will be stashed and should not be deleted despite being excluded"
oid_untrackedstashedandexcluded=$(calc_oid "$content_untrackedstashedandexcluded")
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
content_indexstashedbranch="This data will be stashed on a branch from the index and should not be deleted"
oid_indexstashedbranch=$(calc_oid "$content_indexstashedbranch")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_indexstashedandexcludedbranch="This data will be stashed on a branch from the index and should not be deleted despite being excluded"
oid_indexstashedandexcludedbranch=$(calc_oid "$content_indexstashedandexcludedbranch")
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
content_stashedbranch="This data will be stashed on a branch and should not be deleted"
oid_stashedbranch=$(calc_oid "$content_stashedbranch")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_stashedandexcludedbranch="This data will be stashed on a branch and should not be deleted despite being excluded"
oid_stashedandexcludedbranch=$(calc_oid "$content_stashedandexcludedbranch")
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
content_untrackedstashedbranch="This UNTRACKED FILE data will be stashed on a branch and should not be deleted"
oid_untrackedstashedbranch=$(calc_oid "$content_untrackedstashedbranch")
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
content_untrackedstashedandexcludedbranch="This UNTRACKED FILE data will be stashed on a branch and should not be deleted despite being excluded"
oid_untrackedstashedandexcludedbranch=$(calc_oid "$content_untrackedstashedandexcludedbranch")
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# We need to test with older commits to ensure they get pruned as expected
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
echo "[
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
{
\"CommitDate\":\"$(get_date -20d)\",
\"Files\":[
{\"Filename\":\"old.dat\",\"Size\":${#content_oldandpushed}, \"Data\":\"$content_oldandpushed\"}]
},
{
\"CommitDate\":\"$(get_date -7d)\",
\"Files\":[
{\"Filename\":\"old.dat\",\"Size\":${#content_retain1}, \"Data\":\"$content_retain1\"}]
},
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
{
\"CommitDate\":\"$(get_date -4d)\",
\"NewBranch\":\"branch_to_delete\",
\"Files\":[
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"},
{\"Filename\":\"foo/unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
},
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
{
\"CommitDate\":\"$(get_date -1d)\",
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
\"ParentBranches\":[\"main\"],
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
\"Files\":[
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
{\"Filename\":\"stashedfile.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"},
{\"Filename\":\"foo/stashedfile.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"}]
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
}
]" | lfstest-testutils addcommits
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
git push origin main
assert_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
assert_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# now modify the files, and add them to the index
t/t-prune.go: prefer printf to echo 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.
2020-09-03 23:29:22 +00:00
printf '%s' "$content_indexstashed" > stashedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_indexstashedandexcluded" > foo/stashedfile.dat
git add stashedfile.dat foo/stashedfile.dat
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# now modify the files again, and stash them
t/t-prune.go: prefer printf to echo 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.
2020-09-03 23:29:22 +00:00
printf '%s' "$content_stashed" > stashedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_stashedandexcluded" > foo/stashedfile.dat
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# Also create untracked files
t/t-prune.go: prefer printf to echo 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.
2020-09-03 23:29:22 +00:00
printf '%s' "$content_untrackedstashed" > untrackedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_untrackedstashedandexcluded" > foo/untrackedfile.dat
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
# stash, including untracked
git stash -u
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
# Switch to a branch, modify files in the index and working tree and create
# untracked files, stash them, and delete the branch.
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git checkout branch_to_delete
printf '%s' "$content_indexstashedbranch" > unreferenced.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_indexstashedandexcludedbranch" > foo/unreferenced.dat
git add unreferenced.dat foo/unreferenced.dat
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
printf '%s' "$content_stashedbranch" > unreferenced.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_stashedandexcludedbranch" > foo/unreferenced.dat
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
printf '%s' "$content_untrackedstashedbranch" > untrackedfile.dat
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
printf '%s' "$content_untrackedstashedandexcludedbranch" > foo/untrackedfile.dat
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
git stash -u
git checkout main
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
git branch -D branch_to_delete
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
# Prove that ALL stashed data was stored in LFS (should call clean filter)
assert_local_object "$oid_indexstashed" "${#content_indexstashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcluded" "${#content_indexstashedandexcluded}"
t: reorder prune stash checks to match actions 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.
2021-03-24 05:34:45 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcluded" "${#content_stashedandexcluded}"
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
assert_local_object "$oid_untrackedstashed" "${#content_untrackedstashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_untrackedstashedandexcluded" "${#content_untrackedstashedandexcluded}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_indexstashedbranch" "${#content_indexstashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcludedbranch" "${#content_indexstashedandexcludedbranch}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcludedbranch" "${#content_stashedandexcludedbranch}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_untrackedstashedbranch" "${#content_untrackedstashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_untrackedstashedandexcludedbranch" "${#content_untrackedstashedandexcludedbranch}"
# We need to prevent MSYS from rewriting /foo into a Windows path.
commands,t: gitignore matching for fetch filters The "lfs.fetchinclude" and "lfs.fetchexclude" Git configuration options, if set, are used to control the action of a number of Git LFS commands. Since PR #4556, the "git lfs clone", "git lfs fetch", and "git lfs pull" commands have strictly applied gitignore(5)-style matching rules to these configuration options. However, other commands including "git lfs filter-process" and "git lfs smudge" now apply gitattributes(5)-style matching rules to these same configuration options, leading to confusion. We therefore revise all remaining uses of these configuration options to also use gitignore-style matching rules. We also add new tests for the "git lfs filter-process" and "git lfs fsck" commands and adjust or expand existing tests for the "git lfs prune" and "git lfs smudge" commands in order to confirm that gitignore-style matching is used for all of them. These new and updated tests fail if gitattributes-style matching is used instead. (Note that the "git lfs migrate" command does not require any changes because it does not read the "lfs.fetch*" configuration options. Instead, it supplies a "false" value for the "useFetchOptions" flag to the determineIncludeExcludePaths() function, so any "lfs.fetch*" configuration values are ignored. This is significant because "git lfs migrate" deliberately uses gitattributes-style matching for any path patterns supplied via its -I/-X command-line arguments, unlike all other commands that accept -I/-X arguments as overrides for the "lfs.fetch*" configuration options.)
2022-04-18 07:24:53 +00:00
MSYS_NO_PATHCONV=1 git config "lfs.fetchexclude" "/foo"
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
t: test fetch/prune diff parsing with ANSI escapes 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.
2021-08-18 01:31:41 +00:00
# force color codes in git diff meta-information
git config color.diff always
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
# Prune data, should NOT delete stashed file or stashed changes to index
git lfs prune
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
refute_local_object "$oid_oldandpushed" "${#content_oldandpushed}"
t: add unreferenced objects to prune stash tests 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.
2021-03-24 06:22:08 +00:00
refute_local_object "$oid_unreferenced" "${#content_unreferenced}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_retain1" "${#content_retain1}"
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
assert_local_object "$oid_indexstashed" "${#content_indexstashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcluded" "${#content_indexstashedandexcluded}"
t: reorder prune stash checks to match actions 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.
2021-03-24 05:34:45 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcluded" "${#content_stashedandexcluded}"
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
assert_local_object "$oid_untrackedstashed" "${#content_untrackedstashed}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_untrackedstashedandexcluded" "${#content_untrackedstashedandexcluded}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_indexstashedbranch" "${#content_indexstashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_indexstashedandexcludedbranch" "${#content_indexstashedandexcludedbranch}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_stashedandexcludedbranch" "${#content_stashedandexcludedbranch}"
t: test additional stashed objects with prune 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.
2021-03-24 06:27:38 +00:00
assert_local_object "$oid_untrackedstashedbranch" "${#content_untrackedstashedbranch}"
t/t-prune.sh: check excluded but stashed files The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR #4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
2022-04-25 03:04:59 +00:00
assert_local_object "$oid_untrackedstashedandexcludedbranch" "${#content_untrackedstashedandexcludedbranch}"
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
)
end_test
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
begin_test "prune recent changes with --recent"
(
set -e
reponame="prune_recent_arg"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat"
# generate content we'll use
content_inrepo="this is the original committed data"
oid_inrepo=$(calc_oid "$content_inrepo")
content_new="this data will be recent"
oid_new=$(calc_oid "$content_new")
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
echo "[
{
\"CommitDate\":\"$(get_date -1d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"}]
}
]" | lfstest-testutils addcommits
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# now modify the file, and commit it
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
printf '%s' "$content_new" > file.dat
git add .
git commit -m 'Update file.dat'
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# now modify the file, and stash it
printf '%s' "$content_stashed" > file.dat
git stash
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
git config lfs.fetchrecentrefsdays 5
git config lfs.fetchrecentremoterefs true
git config lfs.fetchrecentcommitsdays 3
assert_local_object "$oid_new" "${#content_new}"
assert_local_object "$oid_inrepo" "${#content_inrepo}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
# prune data, should not delete.
git lfs prune --recent
assert_local_object "$oid_new" "${#content_new}"
assert_local_object "$oid_inrepo" "${#content_inrepo}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
git push origin HEAD
# prune data.
git lfs prune --recent
assert_local_object "$oid_new" "${#content_new}"
refute_local_object "$oid_inrepo" "${#content_inrepo}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
)
end_test
begin_test "prune --force"
(
set -e
reponame="prune_force"
setup_remote_repo "remote_$reponame"
clone_repo "remote_$reponame" "clone_$reponame"
git lfs track "*.dat"
# generate content we'll use
content_inrepo="this is the original committed data"
oid_inrepo=$(calc_oid "$content_inrepo")
content_new="this data will be recent"
oid_new=$(calc_oid "$content_new")
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
echo "[
{
\"CommitDate\":\"$(get_date -1d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_inrepo}, \"Data\":\"$content_inrepo\"}]
}
]" | lfstest-testutils addcommits
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# now modify the file, and commit it
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
printf '%s' "$content_new" > file.dat
git add .
git commit -m 'Update file.dat'
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
# now modify the file, and stash it
printf '%s' "$content_stashed" > file.dat
git stash
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
git config lfs.fetchrecentrefsdays 5
git config lfs.fetchrecentremoterefs true
git config lfs.fetchrecentcommitsdays 3
assert_local_object "$oid_new" "${#content_new}"
assert_local_object "$oid_inrepo" "${#content_inrepo}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
# prune data, should not delete.
git lfs prune --force
assert_local_object "$oid_new" "${#content_new}"
assert_local_object "$oid_inrepo" "${#content_inrepo}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
git push origin HEAD
# prune data.
git lfs prune --force
refute_local_object "$oid_new" "${#content_new}"
refute_local_object "$oid_inrepo" "${#content_inrepo}"
lfs,t: parse only stash log entries for prune 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.
2021-03-23 08:10:30 +00:00
assert_local_object "$oid_stashed" "${#content_stashed}"
prune: add options to be more aggressive about pruning 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.
2021-01-12 21:24:44 +00:00
)
end_test
lfs: don't invoke diff drivers when pruning repositories 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.
2021-02-19 17:36:27 +00:00
fs: specify a file as existing if it's empty 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.
2021-09-27 12:33:22 +00:00
begin_test "prune does not fail on empty files"
(
set -e
reponame="prune-empty-file"
setup_remote_repo "remote-$reponame"
clone_repo "remote-$reponame" "clone-$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
touch empty.dat
git add .gitattributes empty.dat
git commit -m 'Add empty'
git push origin main
git lfs prune --force
)
end_test
lfs: don't invoke diff drivers when pruning repositories 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.
2021-02-19 17:36:27 +00:00
begin_test "prune does not invoke external diff programs"
(
set -e
reponame="prune-external-diff"
setup_remote_repo "remote-$reponame"
clone_repo "remote-$reponame" "clone-$reponame"
git config diff.word.textconv 'false'
echo "*.dot diff=word" >.git/info/attributes
for n in $(seq 1000); do (echo "$n" > "$n.dot") done
git add .
git commit -am "initial"
git lfs prune
)
end_test
t/t-prune.sh: add test showing hang in prune 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.
2021-07-23 14:54:58 +00:00
begin_test "prune doesn't hang on long lines in diff"
(
set -e
reponame="prune_longlines"
git init "$reponame"
cd "$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
echo "test data" >test.dat
git add .gitattributes test.dat
git commit -m tracked
git lfs untrack "*.dat" 2>&1 | tee untrack.log
grep "Untracking \"\*.dat\"" untrack.log
lfs/gitscanner_log.go: fix hang in scanner when long lines are present I don't think there's a reasonable way to do this with bufio.Scanner, so I switched it to bufio.Reader.
2021-07-23 15:03:21 +00:00
# Exceed the default buffer size that would be used by bufio.Scanner
t/t-prune.sh: add test showing hang in prune 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.
2021-07-23 14:54:58 +00:00
dd if=/dev/zero bs=1024 count=128 | tr '\0' 'A' >test.dat
git add .gitattributes test.dat
git commit -m untracked
git lfs prune
)
end_test
begin_test "prune doesn't hang on long lines in stash diff"
(
set -e
reponame="prune_longlines"
git init "$reponame"
cd "$reponame"
git lfs track "*.dat" 2>&1 | tee track.log
grep "Tracking \"\*.dat\"" track.log
echo "test data" >test.dat
git add .gitattributes test.dat
git commit -m tracked
git lfs untrack "*.dat" 2>&1 | tee untrack.log
grep "Untracking \"\*.dat\"" untrack.log
lfs/gitscanner_log.go: fix hang in scanner when long lines are present I don't think there's a reasonable way to do this with bufio.Scanner, so I switched it to bufio.Reader.
2021-07-23 15:03:21 +00:00
# Exceed the default buffer size that would be used by bufio.Scanner
t/t-prune.sh: add test showing hang in prune 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.
2021-07-23 14:54:58 +00:00
dd if=/dev/zero bs=1024 count=128 | tr '\0' 'A' >test.dat
git stash
git lfs prune
)
end_test
Reference in New Issue Copy Permalink