development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-11-05 18:59:29 +00:00
Code Issues Projects Releases Packages Wiki Activity
git/t/t1404-update-ref-df-conflicts.sh

108 lines
2.5 KiB
Bash
Raw Normal View History

t1404: new tests of ref D/F conflicts within transactions Add some tests of reference D/F conflicts (by which I mean the fact that references like "refs/foo" and "refs/foo/bar" are not allowed to coexist) in the context of reference transactions. The test of creating two conflicting references in the same transaction fails, leaving the transaction half-completed. This will be fixed later in this patch series. Please note that the error messages emitted in the case of conflicts are not very user-friendly. In particular, when the conflicts involve loose references, then the errors are reported as error: there are still refs under 'refs/foo' fatal: Cannot lock the ref 'refs/foo'. or error: unable to resolve reference refs/foo/bar: Not a directory fatal: Cannot lock the ref 'refs/foo/bar'. This is because lock_ref_sha1_basic() fails while trying to lock the new reference, before it even gets to the is_refname_available() check. This situation will also be improved later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:03 +00:00
#!/bin/sh
test_description='Test git update-ref with D/F conflicts'
. ./test-lib.sh
test_update_rejected () {
prefix="$1" &&
before="$2" &&
pack="$3" &&
create="$4" &&
error="$5" &&
printf "create $prefix/%s $C\n" $before |
git update-ref --stdin &&
git for-each-ref $prefix >unchanged &&
if $pack
then
git pack-refs --all
fi &&
printf "create $prefix/%s $C\n" $create >input &&
test_must_fail git update-ref --stdin <input 2>output.err &&
grep -F "$error" output.err &&
git for-each-ref $prefix >actual &&
test_cmp unchanged actual
}
Q="'"
test_expect_success 'setup' '
git commit --allow-empty -m Initial &&
C=$(git rev-parse HEAD)
'
test_expect_success 'existing loose ref is a simple prefix of new' '
prefix=refs/1l &&
test_update_rejected $prefix "a c e" false "b c/x d" \
lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts If there is a failure to lock a reference that is likely caused by a D/F conflict (e.g., trying to lock "refs/foo/bar" when reference "refs/foo" already exists), invoke verify_refname_available() to try to generate a more helpful error message. That function might not detect an error. For example, some non-reference file might be blocking the deletion of an otherwise-empty directory tree, or there might be a race with another process that just deleted the offending reference. In such cases, generate the strerror-based error message like before. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:16 +00:00
"$Q$prefix/c$Q exists; cannot create $Q$prefix/c/x$Q"
t1404: new tests of ref D/F conflicts within transactions Add some tests of reference D/F conflicts (by which I mean the fact that references like "refs/foo" and "refs/foo/bar" are not allowed to coexist) in the context of reference transactions. The test of creating two conflicting references in the same transaction fails, leaving the transaction half-completed. This will be fixed later in this patch series. Please note that the error messages emitted in the case of conflicts are not very user-friendly. In particular, when the conflicts involve loose references, then the errors are reported as error: there are still refs under 'refs/foo' fatal: Cannot lock the ref 'refs/foo'. or error: unable to resolve reference refs/foo/bar: Not a directory fatal: Cannot lock the ref 'refs/foo/bar'. This is because lock_ref_sha1_basic() fails while trying to lock the new reference, before it even gets to the is_refname_available() check. This situation will also be improved later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:03 +00:00
'
test_expect_success 'existing packed ref is a simple prefix of new' '
prefix=refs/1p &&
test_update_rejected $prefix "a c e" true "b c/x d" \
"$Q$prefix/c$Q exists; cannot create $Q$prefix/c/x$Q"
'
test_expect_success 'existing loose ref is a deeper prefix of new' '
prefix=refs/2l &&
test_update_rejected $prefix "a c e" false "b c/x/y d" \
lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts If there is a failure to lock a reference that is likely caused by a D/F conflict (e.g., trying to lock "refs/foo/bar" when reference "refs/foo" already exists), invoke verify_refname_available() to try to generate a more helpful error message. That function might not detect an error. For example, some non-reference file might be blocking the deletion of an otherwise-empty directory tree, or there might be a race with another process that just deleted the offending reference. In such cases, generate the strerror-based error message like before. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:16 +00:00
"$Q$prefix/c$Q exists; cannot create $Q$prefix/c/x/y$Q"
t1404: new tests of ref D/F conflicts within transactions Add some tests of reference D/F conflicts (by which I mean the fact that references like "refs/foo" and "refs/foo/bar" are not allowed to coexist) in the context of reference transactions. The test of creating two conflicting references in the same transaction fails, leaving the transaction half-completed. This will be fixed later in this patch series. Please note that the error messages emitted in the case of conflicts are not very user-friendly. In particular, when the conflicts involve loose references, then the errors are reported as error: there are still refs under 'refs/foo' fatal: Cannot lock the ref 'refs/foo'. or error: unable to resolve reference refs/foo/bar: Not a directory fatal: Cannot lock the ref 'refs/foo/bar'. This is because lock_ref_sha1_basic() fails while trying to lock the new reference, before it even gets to the is_refname_available() check. This situation will also be improved later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:03 +00:00
'
test_expect_success 'existing packed ref is a deeper prefix of new' '
prefix=refs/2p &&
test_update_rejected $prefix "a c e" true "b c/x/y d" \
"$Q$prefix/c$Q exists; cannot create $Q$prefix/c/x/y$Q"
'
test_expect_success 'new ref is a simple prefix of existing loose' '
prefix=refs/3l &&
test_update_rejected $prefix "a c/x e" false "b c d" \
lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts If there is a failure to lock a reference that is likely caused by a D/F conflict (e.g., trying to lock "refs/foo/bar" when reference "refs/foo" already exists), invoke verify_refname_available() to try to generate a more helpful error message. That function might not detect an error. For example, some non-reference file might be blocking the deletion of an otherwise-empty directory tree, or there might be a race with another process that just deleted the offending reference. In such cases, generate the strerror-based error message like before. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:16 +00:00
"$Q$prefix/c/x$Q exists; cannot create $Q$prefix/c$Q"
t1404: new tests of ref D/F conflicts within transactions Add some tests of reference D/F conflicts (by which I mean the fact that references like "refs/foo" and "refs/foo/bar" are not allowed to coexist) in the context of reference transactions. The test of creating two conflicting references in the same transaction fails, leaving the transaction half-completed. This will be fixed later in this patch series. Please note that the error messages emitted in the case of conflicts are not very user-friendly. In particular, when the conflicts involve loose references, then the errors are reported as error: there are still refs under 'refs/foo' fatal: Cannot lock the ref 'refs/foo'. or error: unable to resolve reference refs/foo/bar: Not a directory fatal: Cannot lock the ref 'refs/foo/bar'. This is because lock_ref_sha1_basic() fails while trying to lock the new reference, before it even gets to the is_refname_available() check. This situation will also be improved later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:03 +00:00
'
test_expect_success 'new ref is a simple prefix of existing packed' '
prefix=refs/3p &&
test_update_rejected $prefix "a c/x e" true "b c d" \
"$Q$prefix/c/x$Q exists; cannot create $Q$prefix/c$Q"
'
test_expect_success 'new ref is a deeper prefix of existing loose' '
prefix=refs/4l &&
test_update_rejected $prefix "a c/x/y e" false "b c d" \
lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts If there is a failure to lock a reference that is likely caused by a D/F conflict (e.g., trying to lock "refs/foo/bar" when reference "refs/foo" already exists), invoke verify_refname_available() to try to generate a more helpful error message. That function might not detect an error. For example, some non-reference file might be blocking the deletion of an otherwise-empty directory tree, or there might be a race with another process that just deleted the offending reference. In such cases, generate the strerror-based error message like before. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:16 +00:00
"$Q$prefix/c/x/y$Q exists; cannot create $Q$prefix/c$Q"
t1404: new tests of ref D/F conflicts within transactions Add some tests of reference D/F conflicts (by which I mean the fact that references like "refs/foo" and "refs/foo/bar" are not allowed to coexist) in the context of reference transactions. The test of creating two conflicting references in the same transaction fails, leaving the transaction half-completed. This will be fixed later in this patch series. Please note that the error messages emitted in the case of conflicts are not very user-friendly. In particular, when the conflicts involve loose references, then the errors are reported as error: there are still refs under 'refs/foo' fatal: Cannot lock the ref 'refs/foo'. or error: unable to resolve reference refs/foo/bar: Not a directory fatal: Cannot lock the ref 'refs/foo/bar'. This is because lock_ref_sha1_basic() fails while trying to lock the new reference, before it even gets to the is_refname_available() check. This situation will also be improved later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:03 +00:00
'
test_expect_success 'new ref is a deeper prefix of existing packed' '
prefix=refs/4p &&
test_update_rejected $prefix "a c/x/y e" true "b c d" \
"$Q$prefix/c/x/y$Q exists; cannot create $Q$prefix/c$Q"
'
refs: check for D/F conflicts among refs created in a transaction If two references that D/F conflict (e.g., "refs/foo" and "refs/foo/bar") are created in a single transaction, the old code discovered the problem only after the "commit" phase of ref_transaction_commit() had already begun. This could leave some references updated and others not, which violates the promise of atomicity. Instead, check for such conflicts during the "locking" phase: * Teach is_refname_available() to take an "extras" parameter that can contain extra reference names with which the specified refname must not conflict. * Change lock_ref_sha1_basic() to take an "extras" parameter, which it passes through to is_refname_available(). * Change ref_transaction_commit() to pass "affected_refnames" to lock_ref_sha1_basic() as its "extras" argument. This change fixes a test case in t1404. This code is a bit stricter than it needs to be. We could conceivably allow reference "refs/foo/bar" to be created in the same transaction as "refs/foo" is deleted (or vice versa). But that would be complicated to implement, because it is not possible to lock "refs/foo/bar" while "refs/foo" exists as a loose reference, but on the other hand we don't want to delete some references before adding others (because that could leave a gap during which required objects are unreachable). There is also a complication that reflog files' paths can conflict. Any less-strict implementation would probably require tricks like the packing of all references before the start of the real transaction, or the use of temporary intermediate reference names. So for now let's accept too-strict checks. Some reference update transactions will be rejected unnecessarily, but they will be rejected in their entirety rather than leaving the repository in an intermediate state, as would happen now. Please note that there is still one kind of D/F conflict that is *not* handled correctly. If two processes are running at the same time, and one tries to create "refs/foo" at the same time that the other tries to create "refs/foo/bar", then they can race with each other. Both processes can obtain their respective locks ("refs/foo.lock" and "refs/foo/bar.lock"), proceed to the "commit" phase of ref_transaction_commit(), and then the slower process will discover that it cannot rename its lockfile into place (after possibly having committed changes to other references). There appears to be no way to fix this race without changing the locking policy, which in turn would require a change to *all* Git clients. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:12 +00:00
test_expect_success 'one new ref is a simple prefix of another' '
t1404: new tests of ref D/F conflicts within transactions Add some tests of reference D/F conflicts (by which I mean the fact that references like "refs/foo" and "refs/foo/bar" are not allowed to coexist) in the context of reference transactions. The test of creating two conflicting references in the same transaction fails, leaving the transaction half-completed. This will be fixed later in this patch series. Please note that the error messages emitted in the case of conflicts are not very user-friendly. In particular, when the conflicts involve loose references, then the errors are reported as error: there are still refs under 'refs/foo' fatal: Cannot lock the ref 'refs/foo'. or error: unable to resolve reference refs/foo/bar: Not a directory fatal: Cannot lock the ref 'refs/foo/bar'. This is because lock_ref_sha1_basic() fails while trying to lock the new reference, before it even gets to the is_refname_available() check. This situation will also be improved later in this patch series. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2015-05-11 15:25:03 +00:00
prefix=refs/5 &&
test_update_rejected $prefix "a e" false "b c c/x d" \
"cannot process $Q$prefix/c$Q and $Q$prefix/c/x$Q at the same time"
'
test_done
Reference in a new issue Copy permalink