summaryrefslogtreecommitdiff
path: root/t/t2011-checkout-invalid-head.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-05-14t: switch $_z40 to $ZERO_OIDLibravatar brian m. carlson1-1/+1
Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13lock_ref_sha1_basic: handle REF_NODEREF with invalid refsLibravatar Jeff King1-0/+33
We sometimes call lock_ref_sha1_basic with REF_NODEREF to operate directly on a symbolic ref. This is used, for example, to move to a detached HEAD, or when updating the contents of HEAD via checkout or symbolic-ref. However, the first step of the function is to resolve the refname to get the "old" sha1, and we do so without telling resolve_ref_unsafe() that we are only interested in the symref. As a result, we may detect a problem there not with the symref itself, but with something it points to. The real-world example I found (and what is used in the test suite) is a HEAD pointing to a ref that cannot exist, because it would cause a directory/file conflict with other existing refs. This situation is somewhat broken, of course, as trying to _commit_ on that HEAD would fail. But it's not explicitly forbidden, and we should be able to move away from it. However, neither "git checkout" nor "git symbolic-ref" can do so. We try to take the lock on HEAD, which is pointing to a non-existent ref. We bail from resolve_ref_unsafe() with errno set to EISDIR, and the lock code thinks we are attempting to create a d/f conflict. Of course we're not. The problem is that the lock code has no idea what level we were at when we got EISDIR, so trying to diagnose or remove empty directories for HEAD is not useful. To make things even more complicated, we only get EISDIR in the loose-ref case. If the refs are packed, the resolution may "succeed", giving us the pointed-to ref in "refname", but a null oid. Later, we say "ah, the null oid means we are creating; let's make sure there is room for it", but mistakenly check against the _resolved_ refname, not the original. We can fix this by making two tweaks: 1. Call resolve_ref_unsafe() with RESOLVE_REF_NO_RECURSE when REF_NODEREF is set. This means any errors we get will be from the orig_refname, and we can act accordingly. We already do this in the REF_DELETING case, but we should do it for update, too. 2. If we do get a "refname" return from resolve_ref_unsafe(), even with RESOLVE_REF_NO_RECURSE it may be the name of the ref pointed-to by a symref. We already normalize this back to orig_refname before taking the lockfile, but we need to do so before the null_oid check. While we're rearranging the REF_NODEREF handling, we can also bump the initialization of lflags to the top of the function, where we are setting up other flags. This saves us from having yet another conditional block on REF_NODEREF just to set it later. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12checkout,clone: check return value of create_symrefLibravatar Jeff King1-0/+6
It's unlikely that we would fail to create or update a symbolic ref (especially HEAD), but if we do, we should notice and complain. Note that there's no need to give more details in our error message; create_symref will already have done so. While we're here, let's also fix a minor memory leak in clone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-23test: use $_z40 from test-libLibravatar Junio C Hamano1-1/+1
There is no need to duplicate the definition of $_z40 and $_x40 that test-lib.sh supplies the test scripts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-03git checkout: do not allow switching to a tree-ish that is not a commitLibravatar Junio C Hamano1-0/+4
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch rooted at the current HEAD, because in that case, the two structure fields used to see if the command was invoked without any argument (hence it needs to default to checking out the HEAD) were populated incorrectly. Upon seeing a command line argument that we took as a rev, we should store that string in new.name, even if that does not name a commit. This will correctly trigger the existing safety logic. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
2008-11-09checkout: Don't crash when switching away from an invalid branch.Libravatar Alexandre Julliard1-0/+18
When using alternates, it is possible for HEAD to end up pointing to an invalid commit. git checkout should be able to recover from that situation without crashing. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>