| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When we look for which remote corresponds to a remote-tracking branch,
we look in the refspecs to see which ones matches. If none do, we should
abort. We currently ignore the error message from this operation, so
let's not do that anymore.
As part of the test we're writing, let's test for the expected behaviour
if we cannot find a refspec which tells us what the remote-tracking
branch for a remote would look like.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| |_|/
|/| | |
Tackle remote API issues from bindings
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we moved from acting on the instance to acting on the
configuration, we dropped the validation of the passed refspec, which
can lead to writing an invalid refspec to the configuration. Bring that
validation back.
|
| | |
| | |
| | |
| | |
| | |
| | | |
An anonymous remote is not configured and cannot therefore have
configured refspecs. Remove the parameter which adds this from the
constructor.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The code used to rely on the clone code calling the remote's save, which
does not happen anymore, meaning that the configuration settings the
remote expected were not being written to disk.
The run-time configuration was still being affected, so the right branch
was being cloned. The tests continued to pass as we did not check for
the configuration entires. Fix this by creating the remote with the
single-branch refspec we want and checking for its existence in the
configuration.
|
| |/
|/|
| |
| |
| | |
Git inserts a space after the SHA1 (as of 2.1.4 at least), so do the
same.
|
|\ \
| | |
| | | |
index_add_all: include untracked files in new subdirs
|
| | | |
|
|/ /
| |
| |
| |
| |
| | |
When we discover that we want to keep a negative rule, make sure to
clear the error variable, as it we otherwise return whatever was left by
the previous loop iteration.
|
|\ \
| |/
|/| |
Use a diff for iteration in index_update_all and index_add_all
|
| |
| |
| |
| | |
Without this option, we would not be able to catch exec bit changes.
|
|/
|
|
|
| |
The functionality was meged without including tests, so let's add them
now.
|
|\
| |
| | |
Attributes: don't match files for folders
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
When a .gitignore specifies some folder "foo/", ensure that a file
with the same name "foo" is not ignored.
|
| |
| |
| |
| |
| |
| | |
Ensure that when examining a .gitignore in a subdirectory, we do not
erroneously apply the paths contained therein to the root of the
repository. (Fixed in c02a0e4).
|
|\ \
| | |
| | | |
Use the packbuilder in local push
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A couple of tests use the wrong remote to push to. We did not notice up
to now because the local push would copy individual objects, and those
already existed, so it became a no-op.
Once we made local push create the packfile, it became noticeable that
there was a new packfile where it didn't belong.
|
| | |
| | |
| | |
| | |
| | | |
The interesting one is the notification macro, which was returning
directly on a soft-abort instead of going through the cleanup.
|
|\ \ \
| |/ /
|/| | |
submodule: add test initialising and cloning a repo
|
| |/
| |
| |
| |
| |
| |
| |
| | |
We have a few tests checking each step, but we do not yet have a test
which tests the documented workflow for creating a submodule, namely
`setup_add` followed by cloning into it, followed by `add_finalize`.
Add such a test to protect against regressions in this workflow.
|
| |
| |
| |
| |
| | |
It has now become a no-op, so remove the function and all references to
it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The base refspecs changing can be a cause of confusion as to what is the
current base refspec set and complicate saving the remote's
configuration.
Change `git_remote_add_{fetch,push}()` to update the configuration
instead of an instance.
This finally makes `git_remote_save()` a no-op, it will be removed in a
later commit.
|
| |
| |
| |
| |
| | |
This is another option which we should not be keeping in the remote, but
is specific to each particular operation.
|
| |
| |
| |
| |
| |
| | |
While this will rarely be different from the default, having it in the
remote adds yet another setting it has to keep around and can affect its
behaviour. Move it to the options.
|
| |
| |
| |
| |
| |
| |
| | |
Instead of having it set in a different place from every other callback,
put it the main structure. This removes some state from the remote and
makes it behave more like clone, where the constructors are passed via
the options.
|
| |
| |
| |
| |
| |
| | |
As a first step in removing the repository-saving logic, don't allow
chaning the url or push url from a remote object, but change the
configuration on the configuration immediately.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having the setting be different from calling its actions was not a great
idea and made for the sake of the wrong convenience.
Instead of that, accept either fetch options, push options or the
callbacks when dealing with the remote. The fetch options are currently
only the callbacks, but more options will be moved from setters and
getters on the remote to the options.
This does mean passing the same struct along the different functions but
the typical use-case will only call git_remote_fetch() or
git_remote_push() and so won't notice much difference.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Configuration changes for handling multiple of the same sections
|
| |
| |
| |
| |
| |
| | |
If a multivar exists within two sections (of the same name)
then they should both be updated in a `set_multivar`. Ensure
that this is the case.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a test that exposes a bug in config_write.
It is valid to have multiple separate headers for the same config section, but
config_write will exit after finding the first matching section in certain
situations.
This test proves that config_write will duplicate a variable that already
exists instead of overwriting it if the variable is defined under a duplicate
section header.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we would try to be clever when writing the configuration
file and try to stop parsing (and simply copy the rest of the old
file) when we either found the value we were trying to write,
or when we left the section that value was in, the assumption being
that there was no more work to do.
Regrettably, you can have another section with the same name later
in the file, and we must cope with that gracefully, thus we read the
whole file in order to write a new file.
Now, writing a file looks even more than reading. Pull the config
parsing out into its own function that can be used by both reading
and writing the configuration.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
On Mac OS, `realpath` is deficient in determining the actual filename
on-disk as it will simply provide the string you gave it if that file
exists, instead of returning the filename as it exists. Instead we
must read the directory entries for the parent directory to get the
canonical filename.
|
| | |
|
| | |
|