git-lfs/git-lfs

Pass standard input to ssh

Various release updates

Some people have SSH prompt them for their passphrase when a key is
used. In such a situation, the user needs to be able to enter a password
on standard input so that they can use their key. When invoking ssh,
pass our standard input through to the ssh process so that it can prompt
the user if needed.

Now that Ubuntu 19.04 (disco) has been released, add it to the list of
release that we can upload for.

Every time we build a release, we build new CentOS packages of Ruby and
ronn, among others. These packages have the same names as the packages
built during previous releases. However, attempting to upload a package
with an identical name fails because PackageCloud doesn't allow us to
overwrite packages in that way.

To prevent the maintainer from having to delete these packages by hand,
and to allow the maintainer to retry package uploads if they fail
partway through, look for the error message we get if a package already
exists and simply ignore it, continuing on as if no error occurred.

Improve error handling in git lfs install

On Windows, we don't have a good way to detect administrator-equivalent
permissions. The os.Geteuid call we use on Unix returns -1, so we always
print a warning to the user that they lack root permissions (which,
since it's Windows, which lacks the root user, technically they do).
Nevertheless, this warning is irksome and unwelcome since it's prone to
false positives and doesn't tell the user anything about whether their
operation is actually likely to succeed or fail. Simply skip printing it
on Windows or in any other case where we're unable to fetch the actual
user ID.

When git lfs install fails, exit unsuccessfully, so that the users
writing scripts can easily detect this error. Disable the test on
Windows, which does not have the proper chmod behavior to make the test
work.

SLES 12.4 is not a valid distribution according to PackageCloud, so we
can't upload RPMs for it. Remove it from the list since it's not usable.

Since we now start these array literals with "[" instead of "%w(", close
them with "]" instead of ")".

The Git LFS signing cert has changed, so update the default signing cert
SHA-1 hash in the Makefile.

Issue 3252: git-lfs locks should optionally denote own locks

Properly handle config options for URLs with upper case letters

tq/adapterbase: fix typo enableHrefRerite to enableHrefRewrite

tq/adapterbase: support rewriting href

For backward compatibility and some incompatible situations such as
using SSH protocol, href-rewriting is only enabled if
lfs.transfer.enablehrefrewrite is set to true explicitly.

Git configuration options have a complicated situation with regard to
case. For the most part, they are case-insensitive: you may write any
case into the file, but Git interprets it as lower case. However, there
are exceptions.

Because the middle component of a three-component option can be a URL,
branch name, or remote name, this component (and only this component) is
treated as case sensitive. Since this component can be a URL, which may
(and, due to the ".git" portion, usually does) contain a dot, the first
component of the config option is read up until the first dot, and the
last component is read from the end to the last dot.

When git config writes a value into the file, it preserves the case the
user has provided, and when it prints the config values, it
canonicalizes the keys by folding the case-insensitive portions to
lowercase. Git LFS then reads this canonicalized form in as our source
of config options, relieving us from having to parse the files ourselves.

However, when we read this data in, we forced the key to lowercase, and
when we looked up a key, we also forced the key we were looking up to
lowercase. While this behavior was wrong (since URLs, at least, are
case-sensitive), it did happen to mostly work if the configuration
didn't contain settings for two URLs differing in case.

In the 2.7.0 cycle, we changed the way we did URL config lookups to
match the way Git does them. Previously, we performed configuration
lookups on several possible keys (forcing them to lower case, URL
portion included) and took the first that matched. Now, we directly
compare the URL we're connecting to (which may be in mixed case) to the
values we got in the configuration (which we've forced to lowercase).
Consequently, we will fail to find configuration options for a
mixed-case URL, resulting in things like "http.extraHeader" not being
used.

Fix this issue by letting Git do the canonicalization of configuration
keys for us instead of lowercasing them ourselves and then
canonicalizing the key when looking it up in the table. Add tests for
this behavior with "http.extraHeader" in the integration suite and
several canonicalization assertions in the unit tests. Update several
tests to use the canonical version of the data in their test data
stores, and add a check to avoid noncanonical test data.

Co-authored-by: Taylor Blau <me@ttaylorr.com>

Use git-lfs version of go-ntlm

Use insteadOf/pushInsteadOf aliases to rewrite href to upload/download
LFS objects. This is useful in situations such like you need to access
the LFS server via a reverse proxy.

The upstream of go-ntlm has archived its repository and is no longer
doing releases. Because this dependency is required for Git LFS, we've
created our own fork to ensure that the upstream repo doesn't disappear
on us. Use our own copy of go-ntlm within Git LFS.

Detect Cygwin-style pipe TTYs as TTYs

Some Unix emulation layers for Windows, such as Cygwin and MSYS, use
pipes to create their Unix-style TTYs. These TTYs are not detected as
such by Windows, which sees them as pipes. However, our isatty module
has a way to detect them, and they will function just like a TTY for our
purposes, so check for them as well and handle them as TTYs if present.

We already have a helper method to determine if a file is a TTY. In a
future commit, we'll modify the definition of what constitutes a TTY, so
refactor the code to always use the helper method so that we need only
update one place.

Set push remote for pre-push

"locks --verify" can be combined with "--cached" option now in the same
way as for "plain" remote queries.

Cached data is stored in a separate file "path/to/ref/verifiable", next
to the "plain" remote query cache file.

This resolves issue #3252.

"locks --verify" verifies the server-side lock owner and denotes own
locks in the output by 'O'.

Internally, the /locks/verify API is used to have the server reporting
locks categorized by "ours" and "theirs". Note that this categorization
must be performed on the server because only the server knows the
mapping between login and lock owner name.

This basically resolves issue #3252 but does not yet address the
combination of "--verify" and "--cached".

In the pre-push hook, we set the remote to the remote value that has
been passed to us from Git. In most cases, this works fine. However,
because we're pushing and have set a remote but not specifically a push
remote, if the user has a remote.pushDefault setting, we'll use that
instead of honoring the remote passed into the hook. As a result, we can
end up pushing LFS objects to the wrong place.

Instead, since we're pushing, set the push remote instead of the regular
remote. This has no effects other than to make us not read the
pushDefault setting.

Log test server standard error to log file

When there's a problem with the test server, it's helpful to see the log
output to help troubleshoot the issue. However, when the Stderr member
of a command struct is not set, the standard error gets redirected to
/dev/null, which isn't really what we want.

Since we already have a log set up for logging standard output, send
standard error there as well.

Handle Windows junctions properly

Refactor SearchLocksVerifiable to use Client.RemoteRef instead of having
a separate ref parameter. This makes ref-processing more consistent with
other locks-functions.

Refactor locks API to allow /locks/verify requests without a ref being
specified

SearchLocks and SearchLocksVerifiable are quite similar; also
API is using struct names like "lockVerifiableRequest".

When a user has gotten their locks into a bad state, it should be
possible to unlock them by using the ID and --force, even if Git LFS
thinks that the file does not exist or that the repository is for some
reason not in a sane state. Consequently, skip the check for existence
in --force mode and just attempt the operation.

This allows users to recover from an issue where we could produce
relative paths with ".." in them when using junctions on Windows, which
prevented the locks from being unlocked.