- 27 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 06 Oct, 2020 1 commit
-
-
Update `refs/remotes/origin/HEAD` as a symbolic link to the remote's default branch.
Edward Thomson committed
-
- 03 Aug, 2020 2 commits
-
-
We derive the branch name, even in our code, we shouldn't assume that the branch will be "master".
Edward Thomson committed -
When cloning an empty repository, we need to guess what the branch structure should be; instead of hardcoding `master`, use the `init.defaultBranch` setting it if it provided.
Edward Thomson committed
-
- 09 Jun, 2020 1 commit
-
-
When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h" header to be empty. As a result, no function declarations are made available to callers, but the implementations are still available to link against. This has the problem that function declarations also aren't visible to the implementations, meaning that the symbol's visibility will not be set up correctly. As a result, the resulting library may not expose those deprecated symbols at all on some platforms and thus cause linking errors. Fix the issue by conditionally compiling deprecated functions, only. While it becomes impossible to link against such a library in case one uses deprecated functions, distributors of libgit2 aren't expected to pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real" hard deprecation still makes sense in the context of CI to test we don't use deprecated symbols ourselves and in case a dependant uses libgit2 in a vendored way and knows it won't ever use any of the deprecated symbols anyway.
Patrick Steinhardt committed
-
- 06 Nov, 2019 1 commit
-
-
Etienne Samson committed
-
- 17 Oct, 2019 1 commit
-
-
Etienne Samson committed
-
- 20 Jul, 2019 1 commit
-
-
Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
Patrick Steinhardt committed
-
- 14 Jun, 2019 1 commit
-
-
In libgit2 nomenclature, when we need to verb a direct object, we name a function `git_directobject_verb`. Thus, if we need to init an options structure named `git_foo_options`, then the name of the function that does that should be `git_foo_options_init`. The previous names of `git_foo_init_options` is close - it _sounds_ as if it's initializing the options of a `foo`, but in fact `git_foo_options` is its own noun that should be respected. Deprecate the old names; they'll now call directly to the new ones.
Edward Thomson committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 03 Jul, 2017 1 commit
-
-
Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
Patrick Steinhardt committed
-
- 13 Feb, 2017 1 commit
-
-
The recent introduction of the commondir variable of a repository requires callers to distinguish whether their files are part of the dot-git directory or the common directory shared between multpile worktrees. In order to take the burden from callers and unify knowledge on which files reside where, the `git_repository_item_path` function has been introduced which encapsulate this knowledge. Modify most existing callers of `git_repository_path` to use `git_repository_item_path` instead, thus making them implicitly aware of the common directory.
Patrick Steinhardt committed
-
- 21 Jun, 2016 1 commit
-
-
Patrick Steinhardt committed
-
- 03 Aug, 2015 1 commit
-
-
When an error state is an OOM, make sure that we treat is specially and do not try to free it.
Edward Thomson committed
-
- 01 Jun, 2015 1 commit
-
-
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.
Carlos Martín Nieto committed
-
- 13 May, 2015 4 commits
-
-
It has now become a no-op, so remove the function and all references to it.
Carlos Martín Nieto committed -
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.
Carlos Martín Nieto committed -
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.
Carlos Martín Nieto committed -
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.
Carlos Martín Nieto committed
-
- 03 Mar, 2015 3 commits
-
-
We want to use the "checkout: moving from ..." message in order to let git know when a change of branch has happened. Make the convenience functions for this goal write this message.
Carlos Martín Nieto committed -
This namespace is about behaving like git's branch command, so let's do exactly that instead of taking a reflog message. This override is still available via the reference namespace.
Carlos Martín Nieto committed -
The signature for the reflog is not something which changes dynamically. Almost all uses will be NULL, since we want for the repository's default identity to be used, making it noise. In order to allow for changing the identity, we instead provide git_repository_set_ident() and git_repository_ident() which allow a user to override the choice of signature.
Carlos Martín Nieto committed
-
- 30 Sep, 2014 1 commit
-
-
With opportunistic ref updates, git has introduced the concept of having base refspecs *and* refspecs that are active for a particular fetch. Let's start by letting the user override the refspecs for download.
Carlos Martín Nieto committed
-
- 02 Sep, 2014 2 commits
-
-
When the fetch refspec does not include the remote's default branch, it indicates an error in user expectations or programmer error. Error out in that case. This lets us get rid of the dummy refspec which can never work as its zeroed out. In the cases where we did not find a default branch, we set HEAD detached immediately, which lets us refactor the "normal" path, removing `found_branch`.
Carlos Martín Nieto committed -
If the remote does not advertise HEAD, then it is unborn and we cannot checkout that branch. Handle it the same way as an empty repo.
Carlos Martín Nieto committed
-
- 29 Aug, 2014 1 commit
-
-
A repository can have any number of references which we're not interested in such as notes or tags. For the default branch calculation we only care about branches. Make the decision about the number of branches rather than the number of refs in general.
Carlos Martín Nieto committed
-
- 05 Aug, 2014 1 commit
-
-
Jacques Germishuys committed
-
- 16 Jul, 2014 1 commit
-
-
Vicent Marti committed
-
- 11 Jul, 2014 1 commit
-
-
file:///
Windows can't handle a path like `/c:/foo`; when turning file:/// URIs into local paths, we must strip the leading slash.
Edward Thomson committed
-
- 02 Jul, 2014 2 commits
-
-
As git_clone now has callbacks to configure the details of the repository and remote, remove the lower-level functions from the public API, as they lack some of the logic from git_clone proper.
Carlos Martín Nieto committed -
Analogously to the remote creation callback, provide a way for the user of git_clone() to create the repository with whichever options they desire via callback.
Carlos Martín Nieto committed
-
- 27 Jun, 2014 1 commit
-
-
git_remote_set_transport now takes a transport factory rather than a transport git_clone_options now allows the caller to specify a remote creation callback
Philip Kelley committed
-
- 03 Jun, 2014 1 commit
-
-
Whe already worked out the kinks with the function used in the local transport. Expose it and make use of it in the local clone method instead of trying to work it out again.
Carlos Martín Nieto committed
-
- 28 May, 2014 5 commits
-
-
If requested, git_clone_local_into() will try to link the object files instead of copying them. This only works on non-Windows (since it doesn't have this) when both are on the same filesystem (which are unix semantics).
Carlos Martín Nieto committed -
Carlos Martín Nieto committed
-
Carlos Martín Nieto committed
-
A call like git_clone("./foo", "./foo1") writes origin's url as './foo', which makes it unusable, as they're relative to different things. Go with git's behaviour and store the realpath as the url.
Carlos Martín Nieto committed -
When git is given such a path, it will perform a "local clone", bypassing the git-aware protocol and simply copying over all objects that exist in the source. Copy this behaviour when given a local path.
Carlos Martín Nieto committed
-
- 22 May, 2014 1 commit
-
-
We have too many places where we repeat free code, so when adding the new free to the generic code, it didn't take for the local transport. While there, fix a C99-ism that sneaked through.
Carlos Martín Nieto committed
-