summaryrefslogtreecommitdiff
path: root/src/clone.c
Commit message (Collapse)AuthorAgeFilesLines
* path: separate git-specific path functions from utilEdward Thomson2021-11-091-8/+8
| | | | | | Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-171-58/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
* Fix coding style for pointerpunkymaniac2021-09-091-1/+1
| | | | Make some syntax change to follow coding style.
* Check if default branch matches refspecAlexander Ovchinnikov2021-08-261-0/+3
|
* clone: set refs/remotes/origin/HEAD to default branch when branch is ↵Alexander Ovchinnikov2021-08-261-7/+14
| | | | specified, attempt 2
* Revert "Merge pull request #5775 from libgit2/ethomson/clone_branch"Alexander Ovchinnikov2021-08-261-42/+21
| | | | | This reverts commit 487f2a8287c4d1d41d39e05ac53d0e50c679d7e9, reversing changes made to c6cf7f0e6927f1b264a7dda2467d70b9f744a01f.
* clone: set refs/remotes/origin/HEAD when branch is specifiedethomson/clone_branchEdward Thomson2021-01-071-21/+42
| | | | | | When a branch is specified to check out in clone, update the remote tracking `HEAD` to point to it. This mimics git's behavior, when `git clone -b <name>` is used.
* clone: use GIT_ASSERTEdward Thomson2020-11-271-5/+10
|
* clone: update origin's HEADEdward Thomson2020-10-061-16/+50
| | | | | Update `refs/remotes/origin/HEAD` as a symbolic link to the remote's default branch.
* clone: don't assume the default branch nameEdward Thomson2020-08-031-4/+4
| | | | | We derive the branch name, even in our code, we shouldn't assume that the branch will be "master".
* clone: respect init.defaultBranch when emptyEdward Thomson2020-08-031-2/+26
| | | | | | 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.
* tree-wide: do not compile deprecated functions with hard deprecationPatrick Steinhardt2020-06-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* global: DRY includes of assert.hEtienne Samson2019-11-061-2/+0
|
* submodule: provide a wrapper for simple submodule clone stepsEtienne Samson2019-10-171-3/+22
|
* fileops: rename to "futils.h" to match function signaturesPatrick Steinhardt2019-07-201-1/+1
| | | | | | | | | 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.
* Rename opt init functions to `options_init`Edward Thomson2019-06-141-1/+6
| | | | | | | | | | | | | 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.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-7/+7
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-13/+13
|
* Make sure to always include "common.h" firstPatrick Steinhardt2017-07-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* repository: use `git_repository_item_path`Patrick Steinhardt2017-02-131-3/+2
| | | | | | | | | | | | | | 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.
* Remove unused static functionsPatrick Steinhardt2016-06-211-8/+0
|
* errors: tighten up git_error_state OOMs a bit moreEdward Thomson2015-08-031-2/+2
| | | | | When an error state is an OOM, make sure that we treat is specially and do not try to free it.
* clone: fall back to copying when linking does not workcmn/link-fallbackCarlos Martín Nieto2015-06-011-2/+15
| | | | | | | | | | | 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.
* remote: remove git_remote_save()Carlos Martín Nieto2015-05-131-3/+0
| | | | | It has now become a no-op, so remove the function and all references to it.
* remote: remove live changing of refspecsCarlos Martín Nieto2015-05-131-3/+1
| | | | | | | | | | | | 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.
* remote: move the update_fetchhead setting to the optionsCarlos Martín Nieto2015-05-131-2/+4
| | | | | | 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.
* Remove the callbacks struct from the remoteCarlos Martín Nieto2015-05-131-20/+10
| | | | | | | | | | | | | | 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.
* repository: remove log message override for switching the active branchCarlos Martín Nieto2015-03-031-3/+2
| | | | | | 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.
* branch: don't accept a reflog message overrideCarlos Martín Nieto2015-03-031-1/+5
| | | | | | | 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.
* Remove the signature from ref-modifying functionsCarlos Martín Nieto2015-03-031-24/+19
| | | | | | | | | | 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.
* remote: allow overriding the refspecs for download and fetchCarlos Martín Nieto2014-09-301-2/+2
| | | | | | | 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.
* clone: handle overly restrictive refspecscmn/remote-default-restrictCarlos Martín Nieto2014-09-021-23/+22
| | | | | | | | | | | 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`.
* clone: correct handling of an unborn HEADCarlos Martín Nieto2014-09-021-19/+2
| | | | | 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.
* clone: support remotes with references but no branchesCarlos Martín Nieto2014-08-291-2/+19
| | | | | | | 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.
* Merge pull request #2471 from jacquesg/compatibility-cleanupVicent Marti2014-08-071-0/+3
|\ | | | | Compatibility/Portability cleanup
| * Silence unused variables warningsJacques Germishuys2014-08-051-0/+3
| |
* | clone: should_clone? Of course we should clone. That's not the questionVicent Marti2014-07-161-4/+4
| |
* | Handle local file:/// paths on WindowsEdward Thomson2014-07-111-18/+24
|/ | | | | Windows can't handle a path like `/c:/foo`; when turning file:/// URIs into local paths, we must strip the leading slash.
* clone: remote git_clone_into{,_local} from the public APIcmn/clone-custom-repoCarlos Martín Nieto2014-07-021-4/+6
| | | | | | 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.
* clone: add a callback for repository creationCarlos Martín Nieto2014-07-021-1/+14
| | | | | | 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.
* Improvements to git_transport extensibilityPhilip Kelley2014-06-261-8/+23
| | | | | 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
* clone: re-use the local transport's path resolutioncmn/path-to-pathCarlos Martín Nieto2014-06-031-15/+3
| | | | | | 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.
* clone: allow for linking in local cloneCarlos Martín Nieto2014-05-281-5/+31
| | | | | | | | 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).
* clone: add flag not to linkCarlos Martín Nieto2014-05-281-1/+1
|
* clone: add flags to override whether to perform a local cloneCarlos Martín Nieto2014-05-281-1/+24
|
* clone: store the realpath when given a relative oneCarlos Martín Nieto2014-05-281-1/+10
| | | | | | | 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.
* clone: perform a "local clone" when given a local pathCarlos Martín Nieto2014-05-281-11/+103
| | | | | | | | 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.
* Plug leaks and fix a C99-ismCarlos Martín Nieto2014-05-221-1/+2
| | | | | | | 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.
* clone: get rid of head_infocmn/remote-symrefCarlos Martín Nieto2014-05-211-23/+12
| | | | | Since we no longer need to push data to callbacks, there's no need for this truct.
* clone: make use of the remote's default branch guessingCarlos Martín Nieto2014-05-211-67/+17
| | | | | Let's use the remote's default branch guessing instead of reinventing one ourselves with callbacks.
View Lorry Controller Status