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

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

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

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

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.

When creating a lock, the file to be locked should always be relative to
the root of the repository, and not contain any ".." components.
Previously, such a ".." component could occur on Windows when using a
junction because the repository root we received from Git was not
properly canonicalized.

Now that that issue has been fixed, it should no longer be possible to
create a lock with a ".." component. However, as a safety feature, let's
check for this anyway and report it as an error if it occurs.

On Windows, there is the concept of a junction point, which is a by-name
reference from the junction point to a directory using an absolute path.
Go's filepath.EvalSymlinks resolves this and provides a canonical path.
However, Git for Windows ignores them and provides a path containing
junctions, despite the fact that Unix versions of Git always provide an
absolute path.

When locking, we canonicalize paths on Windows before making them
relative to the root, meaning that if junctions are used, the lock path
contains a ".." component, which breaks unlocking. Canonicalize the
paths we get from Git so that we can be confident that lock paths will
be relative.

This case cannot, unfortunately, be easily tested in our testsuite,
since the Git Bash environment lacks support for invoking the system
mklink.exe utility, which is used to create junctions.

Currently, we have some duplicated path handling code that is used for
handling paths that we get from Git. Refactor this code out into a
function for ease of reuse in the future.

Allow specifying multiple insteadOf aliases

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.

Update packagecloud.rb

Switch from manually running go generate to using dh-golang to run it

Install worktree hooks in the proper directory