Commit 47ccbff
t: test index is updated on checkout and pull
After our "git lfs checkout" and "git lfs pull" commands write the
contents of a Git LFS object into a file in the current working tree,
they pass the file's relative path to the "git update-index" command,
so the entries in Git's index for these files reflect their current
state.
If we did not run the "git update-index" command, Git commands like
"git diff-index" would report the files we updated as having been
modified in the working tree.
Notably, though, the "git status" command would normally not report the
files as modified, because it refreshes the Git index in the same way as
the "git update-index" command we run. We invoke the "git update-index"
command with the --refresh option, so it runs the refresh_index()
function, which is also executed by the "git status" command.
The refresh_index() function checks the state of all the cached entries
in Git's index, and so it will detect that the files in the working
tree have been modified, read their content and pass it to the
"git lfs filter-process" command, which returns the same Git LFS
pointer data as should already be in the Git index. The end result
is that the index entries remain unchanged, but the cached modification
timestamps are updated.
As a consequence, even if we never invoked the "git update-index"
command while running our "git lfs checkout" and "git lfs pull" commands,
a subsequent "git status" command would typically not show the working
tree files we update as modified.
However, in our tests of the "git lfs pull" command, we rely exclusively
on the "git status" command to try to verify that the "git update-index"
command has been executed by the "git lfs pull" command. Moreover, the
assert_clean_status() test helper function we invoke to run the
"git status" command has a bug which means it always succeeds, even
if the "git status" command were to report that the current working
tree was not clean.
We added the assert_clean_status() assertion function in commit
7158e3b of PR git-lfs#2641, along with
calls to that function in the initial "pull" test of what is now
our t/t-pull.sh test script. In the same commit we also revised the
"git lfs checkout" and "git lfs pull" commands so that they pass paths
relative to the current working directory to the "git update-index"
command, rather than paths relative to the root of the repository.
This latter change resolved the problem reported in git-lfs#2639, because
by passing file paths relative to the repository root instead of the
current working directory to the "git update-index" command, the
"git lfs checkout" and "git lfs pull" commands were leaving the Git
index and working tree in a confusing state.
At the time when git-lfs#2639 was reported, running "git lfs pull" in a
subdirectory might result in a subsequent "git status" command finding
modifications to both the Git index and the working tree. To check
that the problem was resolved, in PR git-lfs#2641 we introduced the
assert_clean_status() test helper function, and expanded the "pull"
test to call this function after performing several "git lfs pull"
commands in subdirectories of the working tree.
Unfortunately, the assert_clean_status() function does not behave as
an assertion, because it always returns a successful (i.e., zero) exit
code. The function tests whether the output from a "git status" command
includes the message "working tree clean", and if not, reports the
command's output along with that from a "git lfs status" command.
However, the function does not cause the current test's sub-shell to
stop execution and return a non-zero exit code to signal a test
failure condition.
We address this problem now by adding a call to the "exit" shell built-in
command with a non-zero exit code at the end of the brace-delimited
group command which executes if the assert_clean_status() function
does not find the "working tree clean" message in the output from the
"git status" command. This change ensures that if Git determines that
the working tree is not clean, our assert_clean_status() function will
cause the test which called it to fail.
As well, we update the assert_clean_status() function so that when
checking for the "working tree clean" message in the output of the
"git status" command, it will also accept the older "working directory
clean" message output by the "git status" command prior to Git v2.10.0.
This allows our assertion function to succeed and the "pull" test to pass
in our GitHub Actions CI jobs that run our test suite against Git v2.0.0,
the oldest Git version we currently support.
As a further problem, though, checking that a "git status" command
finds a clean working tree is no longer sufficient to guarantee that
the "git lfs pull" command has actually called the "git update-index"
command with the appropriate file paths. To be certain that the Git LFS
client has invoked the "git update-index" command and passed valid file
paths, we also need to check the output of the "git diff-index" command,
and do so before we run the "git status" command, which will cause Git
to reset the file modification timestamps it has cached.
We therefore define a new assert_clean_worktree() test helper function
which runs a "git diff-index HEAD" command and confirms no unexpected
changes are detected in the working tree, and we call this function at
the start of the assert_clean_status() function before the "git status"
command is executed. This ensures that we check the state of the working
tree before the "git status" command refreshes the file modification
timestamps Git has previously cached. As noted above, if we reversed
the order of these checks, the "git diff-index" command would always
return an empty list and so our check of the working tree's state would
be defeated.
We also define a new assert_clean_worktree_with_exceptions() test helper
function, which acts like the assert_clean_worktree() function but filters
the output of the "git diff-index HEAD" command with an extended regular
expression pattern provided to the function as its only argument. This
allows us to use the assert_clean_worktree_with_exceptions() function in
instances where we expect certain files in the working tree to be absent
or modified and so we want to ignore them when they appear in the
"git diff-index" command's output.
We then update the initial "pull" test in the t/t-pull.sh test script
so that it calls either the assert_clean_status() function or the
assert_clean_worktree_with_exceptions() function after each invocation
of the "git lfs pull" command, thereby making the checks in this test
as thorough and consistent with each other as possible.
Finally, we update the initial "checkout" test in the t/t-checkout.sh
test script so that it makes use of the assert_clean_status() and
assert_clean_worktree_with_exceptions() functions in the same manner
as the "pull" test in the t/t-pull.sh script now does. Both tests
perform similar operations, and like the "git lfs pull" command, the
"git lfs checkout" command also invokes the "git update-index" command.
However, the "checkout" test was not updated in PR git-lfs#2641 when the
assert_clean_status() was introduced and the "pull" test was updated
to call it.
Since we want our "checkout" test to verify that the "git lfs checkout"
command successfully runs the "git update-index" command, we update the
test so that it mirrors the "pull" test and consistently uses the
assert_clean_worktree() and assert_clean_worktree_with_exceptions()
functions to check the state of the working tree.
To ensure that the "checkout" test still passes, though, we also need to
adjust the test so that it removes any log files it creates because the
assert_clean_status() function now behaves as was originally intended and
will cause the calling test to fail if the working tree is not clean.1 parent 23ae097 commit 47ccbff
3 files changed
+34
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
10 | 10 | | |
11 | 11 | | |
12 | 12 | | |
| 13 | + | |
13 | 14 | | |
14 | 15 | | |
15 | 16 | | |
| 17 | + | |
16 | 18 | | |
17 | 19 | | |
18 | 20 | | |
| |||
50 | 52 | | |
51 | 53 | | |
52 | 54 | | |
| 55 | + | |
| 56 | + | |
53 | 57 | | |
54 | 58 | | |
55 | 59 | | |
56 | 60 | | |
57 | 61 | | |
58 | 62 | | |
| 63 | + | |
59 | 64 | | |
60 | 65 | | |
61 | 66 | | |
| |||
69 | 74 | | |
70 | 75 | | |
71 | 76 | | |
| 77 | + | |
72 | 78 | | |
73 | 79 | | |
74 | 80 | | |
75 | 81 | | |
76 | 82 | | |
77 | 83 | | |
78 | 84 | | |
| 85 | + | |
79 | 86 | | |
80 | 87 | | |
81 | 88 | | |
| |||
84 | 91 | | |
85 | 92 | | |
86 | 93 | | |
| 94 | + | |
87 | 95 | | |
88 | 96 | | |
89 | 97 | | |
90 | | - | |
| 98 | + | |
91 | 99 | | |
92 | 100 | | |
93 | 101 | | |
| 102 | + | |
94 | 103 | | |
95 | 104 | | |
96 | 105 | | |
97 | 106 | | |
98 | 107 | | |
| 108 | + | |
99 | 109 | | |
100 | 110 | | |
101 | 111 | | |
102 | 112 | | |
103 | 113 | | |
| 114 | + | |
104 | 115 | | |
105 | 116 | | |
106 | 117 | | |
107 | 118 | | |
108 | 119 | | |
109 | 120 | | |
| 121 | + | |
110 | 122 | | |
111 | 123 | | |
112 | 124 | | |
113 | 125 | | |
114 | 126 | | |
115 | 127 | | |
| 128 | + | |
116 | 129 | | |
117 | 130 | | |
118 | 131 | | |
119 | 132 | | |
120 | 133 | | |
| 134 | + | |
121 | 135 | | |
122 | 136 | | |
123 | 137 | | |
| |||
127 | 141 | | |
128 | 142 | | |
129 | 143 | | |
| 144 | + | |
130 | 145 | | |
131 | 146 | | |
132 | 147 | | |
| |||
138 | 153 | | |
139 | 154 | | |
140 | 155 | | |
| 156 | + | |
141 | 157 | | |
142 | 158 | | |
143 | 159 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
82 | 82 | | |
83 | 83 | | |
84 | 84 | | |
| 85 | + | |
85 | 86 | | |
86 | 87 | | |
87 | 88 | | |
| |||
154 | 155 | | |
155 | 156 | | |
156 | 157 | | |
| 158 | + | |
157 | 159 | | |
158 | 160 | | |
159 | 161 | | |
| |||
198 | 200 | | |
199 | 201 | | |
200 | 202 | | |
| 203 | + | |
201 | 204 | | |
202 | 205 | | |
203 | 206 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
376 | 376 | | |
377 | 377 | | |
378 | 378 | | |
| 379 | + | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
| 386 | + | |
| 387 | + | |
| 388 | + | |
379 | 389 | | |
| 390 | + | |
| 391 | + | |
380 | 392 | | |
381 | | - | |
| 393 | + | |
382 | 394 | | |
383 | 395 | | |
| 396 | + | |
384 | 397 | | |
385 | 398 | | |
386 | 399 | | |
| |||
0 commit comments