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

1158 lines
40 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}"
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
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: 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: 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\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedbranch1}, \"Data\":\"$content_keepunpushedbranch1\"}]
},
{
\"CommitDate\":\"$(get_date -16d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedbranch2}, \"Data\":\"$content_keepunpushedbranch2\"}]
},
{
\"CommitDate\":\"$(get_date -2d)\",
\"Files\":[
{\"Filename\":\"file.dat\",\"Size\":${#content_keepunpushedbranch3}, \"Data\":\"$content_keepunpushedbranch3\"}]
},
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: 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: 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 "prune: 9 local objects, 7 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: 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 "prune: 7 local objects, 2 retained" prune.log
grep "prune: Deleting objects: 100% (5/5), 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: 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: 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: 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: 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")
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\":[
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
},
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\":[
{\"Filename\":\"stashedfile.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
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}"
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
# now modify the file, and stash it
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: 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: 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
# Switch to a branch, modify a file, stash it, and delete the branch
git checkout branch_to_delete
printf '%s' "$content_stashedbranch" > 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: 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}"
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: 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}"
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")
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
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")
content_stashedbranch="This data will be stashed on a branch and should not be deleted"
oid_stashedbranch=$(calc_oid "$content_stashedbranch")
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\":[
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
},
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\":[
{\"Filename\":\"stashedfile.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
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}"
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
# now modify the file, and add it 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
Add test for stashed index AND working copy change
2020-08-12 14:30:47 +00:00
git add stashedfile.dat
# now modify the file again, and stash it
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: 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: 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
# Switch to a branch, modify a file in the index and working tree, stash it,
# and delete the branch
git checkout branch_to_delete
printf '%s' "$content_indexstashedbranch" > unreferenced.dat
git add unreferenced.dat
printf '%s' "$content_stashedbranch" > 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: 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: 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}"
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
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: 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: 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}"
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
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")
content_stashed="This data will be stashed and should not be deleted"
oid_stashed=$(calc_oid "$content_stashed")
content_untrackedstashed="This UNTRACKED FILE data will be stashed and should not be deleted"
oid_untrackedstashed=$(calc_oid "$content_untrackedstashed")
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")
content_stashedbranch="This data will be stashed on a branch and should not be deleted"
oid_stashedbranch=$(calc_oid "$content_stashedbranch")
content_untrackedstashedbranch="This UNTRACKED FILE data will be stashed on a branch and should not be deleted"
oid_untrackedstashedbranch=$(calc_oid "$content_untrackedstashedbranch")
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\":[
{\"Filename\":\"unreferenced.dat\",\"Size\":${#content_unreferenced}, \"Data\":\"$content_unreferenced\"}]
},
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\":[
{\"Filename\":\"stashedfile.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
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}"
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
# now modify the file, and add it 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
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
git add stashedfile.dat
# now modify the file again, and stash it
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
Add test for untracked files in stash, fix parsing for full combo
2020-08-13 13:32:26 +00:00
# Also create an untracked file
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
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
# Switch to a branch, modify a file in the index and working tree,
# create an untracked file, stash them, and delete the branch
git checkout branch_to_delete
printf '%s' "$content_indexstashedbranch" > unreferenced.dat
git add unreferenced.dat
printf '%s' "$content_stashedbranch" > unreferenced.dat
printf '%s' "$content_untrackedstashedbranch" > untrackedfile.dat
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: 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}"
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: 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}"
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
assert_local_object "$oid_untrackedstashedbranch" "${#content_untrackedstashedbranch}"
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: 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}"
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: 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}"
assert_local_object "$oid_stashedbranch" "${#content_stashedbranch}"
assert_local_object "$oid_untrackedstashedbranch" "${#content_untrackedstashedbranch}"
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