Right now this code only produces false positives. When we have real
support for renames, we can implement it more carefully.
ClosesHomebrew/homebrew#31126.
Per the `git-rev-parse(1)` manpage:
--verify Verify that exactly one parameter is provided, and that it
can be turned into a raw 20-byte SHA-1 that can be used to access the
object database. If so, emit it to the standard output; otherwise,
error out.
If you want to make sure that the output actually names an object in
your object database and/or can be used as a specific type of object
For example, git rev-parse "$VAR^{commit}" will make sure $VAR names
an existing object that is a commit-ish (i.e. a commit, or an
annotated tag that points at a commit).
That actually means that:
git rev-parse --verify af8e768e2bd3b4398bca033998f83b0eb8874914
will _always_ return the SHA-1 hash — regardless of whether or not
that's actually a valid reference!
Thus, when `GitDownloadStragtegy#update_repo` tries to check
`has_ref?`, it mistakenly succeeds, and doesn't actually do a `git fetch
origin`.
The fix is to use:
git rev-parse --verify "af8e768e2bd3b4398bca033998f83b0eb8874914^{commit}"
FixesHomebrew/homebrew#31045.
ClosesHomebrew/homebrew#31054.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
- use a regexp literal and avoid escaping forward slashes
- escape the period in "github.com"
- match only hex characters in the commit part
- allow hyphen in usernames and repo names, matching what we allow for
tap names
- avoid unnecessary capture
When nested submodules appear in a git repository, the `git submodule foreach
git checkout-index ..` command would fail because it would checkout at the root
directory instead of in its parent(s)' folder.
Eg: root/submodule1/submodule2 would be checked out in root/submodule2
ClosesHomebrew/homebrew#30841.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
