The "get_sha1_hex()" function is designed to work with SHA1 hex strings
that may be followed by arbitrary crud. However, that's not acceptable for
"get_sha1()" which is used for command line arguments etc: we don't want
to silently allow random characters after the end of the SHA1.
So verify that the hex string is all we have.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
You can resolve a tag, and it does the right thing except that it might
end up writing the tag itself into the resulting HEAD, which will confuse
subsequent operations no end.
This makes sure that when we resolve two heads, we will have turned them
into proper commits before we start acting on them.
This also fixes the parsing of "treeish^0", which would incorrectly
resolve to "treeish" instead of causing an error.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-rev-parse HEAD^1 would fail, because of an off-by-one bug (but HEAD^
would yield the expected result). Also, when the parent does not exist, do
not silently return an incorrect SHA1. Of course, this no longer applies
to git-rev-parse alone, but every user of get_sha1().
While at it, add a test.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody envies rev-parse, who is the only one that can grok
the extended sha1 format. Move the get_extended_sha1() out of
rev-parse, rename it to get_sha1() and make it available to
everybody else.
The one I posted earlier to the list had one bug where it did
not handle a name that ends with a digit correctly (it
incorrectly tried the "Nth parent" path). This commit fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
