A number of message strings contain embedded filenames, and while
in many cases these are already delimited with single quotes, in
other cases they are not.
We therefore rework the formatting of these messages to accord
with the general practice of using single quotes to delimit
specific filenames.
Note that some of these messages are not yet passed as translation
strings, but we will address that issue in a subsequent commit.
Per git-config's man page, include.* directives are not respected by
default when asked to evaluate a specific file (whether via --global,
--file /path/to/.gitconfig, or GIT_CONFIG=/path/to/.gitconfig).
This patch ensures that, if GIT_CONFIG is set in the environment when
e.g. git-lfs-push is invoked, config directives from included files are
evaluated.
This is important if, for example, an included file contains a
url.<foo>.insteadOf directive or lfs.<foo>.locksverify directive that's
shared between many repositories.
Currently we only read .lfsconfig from the working tree. This is better
than nothing, but it means that if there's an LFS file that starts with
a name earlier than .lfsconfig, we won't read the proper config file,
and we won't use any LFS remote URLs that are located in that file.
If the file is missing, let's additionally read from the index, if
there's a working tree, and then from HEAD. If the repository is bare,
let's just read from HEAD. This is very similar to what Git does for
.gitmodules.
It does, however, differ in one significant way: Git will read from the
index first if it's doing a checkout, since that might have newer
information. We don't do that here, since it's not totally clear that
we can articulate all the cases where that occurs in Git LFS, but we
explicitly allow for the possibility of changing the behavior in the
future and document the feature accordingly.
We no longer read the file .lfsconfig from a bare repository, but that
we did this in the first place was very questionable and pretty clearly
a bug, so it's intentional that we no longer do.
It's possible for a user to specify multiple insteadOf aliases and have
all of the specified URLs map to the same rewritten URL. Make sure we do
handle this correctly by iterating over the all values we read from the
config, not just the last one.
It's very common for a user to specify an SSH remote that refers to an
alias in their gitconfig file. For example, if a user must use
different SSH keys when pushing to different remotes, setting different
aliases that use those different keys is the simplest and easiest way to
accomplish that goal.
Unfortunately, our parsing logic was broken for SSH remotes that used
bare SSH URLs (that is, without “ssh://”) with a hostname or alias, but
without a username component. The URL parser we used saw the hostname
portion as the scheme of a URL, and we passed through any URLs with
unknown schemes. This led to a failure to push, since we misparsed the
URL as a non-SSH URL and gave up when it also didn't look like an
HTTP(S) URL.
If we get an unknown “scheme” when parsing a URL, check if the URL uses
a remote helper (that is, it contains a double colon), and pass it
through. Otherwise, do what Git does, and assume the URL is in fact an
SSH URL, and handle it accordingly.
We already handle the url.insteadof syntax properly, even if it looks
like a scheme. Add tests that we continue to do so, and for the new
code and all the various permutations mentioned above, and update the
existing integration test to reflect our new parsing strategy.
