blob: don't recomment using git_buf_grow

We currently recommend using `git_buf_grow` in order to make a buffer
make an owned copy of the memory it points to. This is not behaviour we
should encourage, so remove this recommendation.

The function itself is not changed, as we need to remain compatible, but
it will be changed not to allow usage on borrowed buffers.

Another round of backports

These tests were not being taken into consideration for the failure of
the test. They've been failing for a while now, but we hadn't noticed as
Travis was reporting the builds successful.

When the callback returns an error, we should stop immediately. This
broke when trying to make sure we pass specific errors up the chain.

This broke cancelling out of the loose backend's foreach.

We've been using `p_ftruncate()` to extend the packfile in order to mmap
it and write the new data into it. This works well in the general case,
but as truncation does not allocate space in the filesystem, it must do
so when we write data to it.

The only way the OS has to indicate a failure to allocate space is via
SIGBUS which means we tried to write outside the file. This will cause
everyone to crash as they don't expect to handle this signal.

Switch to using `p_lseek()` and `p_write()` to extend the file in a way
which tells the filesystem to allocate the space for the missing
data. We can then be sure that we have space to write into.

We use heuristics to make a decent guess at when we can save time and
space by linking object files during a clone. Unfortunately checking the
device id isn't enough, as those would be the same during e.g. a bind-mount,
but the OS still does not allow us to link between mounts of the same
filesystem.

If we fail to perform the links, fall back to copying the contents into
a new file as a last attempt.

Git inserts a space after the SHA1 (as of 2.1.4 at least), so do the
same.

When thickening a pack, avoid loading already loaded bases and
trying to insert them all over again.

When creating an index, know that we do not have an index for
our own packfile, preventing some unnecessary file opens and
error reporting.

When we find out that we're dealing with a matching refspec, we set the
flag and return immediately. This leaves the strings as NULL, which
breaks the contract.

Assign these pointers to a string with the correct values.

Our doc parser really wants the types to be declared in the header it's
reading.

When we fail to read from stdout, it's typically because the URL was
wrong and the server process has sent some output over its stderr
output.

Read that output and set the error message to whatever we read from it.

We set an error if we get an error when reading, but we don't bother
setting an error message for write failing. This causes a cryptic error
to be shown to the user when the target filesystem is full.

Now that `git_path_direach` lets us specify an error message to report,
set an appropriate error message while linking.

This function deals with functions doing IO which means the amount of
errors that can happen is quit large. It does not help if it always
ovewrites the underlying error message with a less understandable
version of "something went wrong".

Instead, only use this generic message if there was no error set by the
callback.

Fix MinGW build against openssl on maint/v0.22

Maintenance updates for v0.22

This was forgotten when the feature was implemented.

This mainly concerns mingw build.

Merge of pull request #3119 from ethomson/ignore as a single commit.

Conflicts:
	src/attr.c
	tests/attr/ignore.c

(also removed an unused member "has_regex" from all_iter)

Closes #2966.

The regcomp function returns a non-zero value if compilation of
a regular expression fails. In most places we only check for
negative values, but positive values indicate an error, as well.
Fix this tree-wide, fixing a segmentation fault when calling
git_config_iterator_glob_new with an invalid regexp.

When a commit is first set as unintersting and then pushed, we must take
care that we do not put it into the commit list as that makes us return
at least that commit (but maybe more) as we've inserted it into the list
because we have the assumption that we want anything in the commit list.

When walking backwards and marking parents uninteresting, make sure we
detect when the list of commits we have left has run out of
uninteresting commits so we can stop marking commits as
uninteresting. Failing to do so can mean that we walk the whole history
marking everything uninteresting, which eats up time, CPU and IO for
with useless work.

While pre-marking does look for this, we still need to check during the
main traversal as there are setups for which pre-marking does not leave
enough information in the commits. This can happen if we push a commit
and hide its parent.

git_checkout_tree() has some fallback behaviors for file systems
which don't have full support of filemodes.  Generally works fine,
but if a given file had a change of type from a 0644 to 0755 (i.e.,
you add executable permissions), the fallback behavior incorrectly
triggers when writing hte updated index.

This would cause a git_checkout_tree() command, even with the
GIT_CHECKOUT_FORCE option set, to leave a dirty index on Windows.

Also added checks to an existing test to catch this case.

Conflicts:
	src/checkout.c

When diffs are generated, the value for the 'nfiles' field of 'git_diff_delta'
will be consistent with the value in the 'status' field. Merging diffs can
modify the 'status' field of some deltas and the 'nfiles' field needs to be
updated accordingly.

Backports for the maint branch

Additional backports