I've been running a test suite we use to verify Git behaviors across
versions, and the 2.2.0 RCs (0 and 1 both) have a couple of small
behavioral differences. I'm sending them in separate e-mails just to
make the contents easier to grok.
Important: It's entirely possible neither of these is a _bug_; they
may both be intentional changes in behavior.
First change: git update-ref -d /refs/heads/nonexistent
<some-valid-sha1> now produces an error about ref locking that it
didn't produce before
Git 2.1.x and prior produced this output:
error: unable to resolve reference refs/heads/nonexistent: No such
file or directory
Now, in the 2.2.0 RCs, it says:
error: unable to resolve reference refs/heads/nonexistent: No such
file or directory
error: Cannot lock the ref 'refs/heads/nonexistent'.
This one feels more like a bug, but again may not be. I say it feels
like a bug because of the order of the messages: If git has decided
the ref doesn't exist, why is it still trying to lock it?
This change bisects to:
bturner@felurian:~/Development/git/git$ git bisect bad
7521cc4611a783f4a8174bd0fcec5f4a47357ac1 is the first bad commit
commit 7521cc4611a783f4a8174bd0fcec5f4a47357ac1
Author: Ronnie Sahlberg <sahlberg@xxxxxxxxxx>
Date: Wed Apr 30 09:22:45 2014 -0700
refs.c: make delete_ref use a transaction
Best regards,
Bryan Turner
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html