Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Split GitVersionControlSpec into interface and implementation

It is just healthy to keep these separate.

Part of gradle/gradle-native#88

  1. … 5 more files in changeset.
Add version ref to Vcs populate

  1. … 14 more files in changeset.
Handle repository workingDir with other remote

Before this change, it the URL from the GitVersionConrolSpec might not

have matched the remote of the workingDir repository, and a pull

command would have been executed. But, the caller's intent would not

have been followed.

  1. … 1 more file in changeset.
Test and cover some more cases


* Can clone into an empty working directory that already exists.

* Cannot populate a non-reposioty working directory with a file in it.

* Cannot populate a non-reposioty working directory, even with a

`.git` subdirectory.

Fixes gradle/gradle-native#107

  1. … 1 more file in changeset.
Add logic to pull if working directory is a repo

Part of gradle/gradle-native#107

  1. … 1 more file in changeset.
Remove dependency on JGit test fixture

- Use our own fixture that drives Git itself

- We can control where the temporary files live and use our

other fixtures (e.g., TestFile)

  1. … 3 more files in changeset.
Move more logic into the TemporaryGitRepository fixture

We don't have to expose the whole fine-grained API used in the JGit

unittests to meet our needs for testig Gradle code. This narrower

API allows us to reuse more logic.

  1. … 1 more file in changeset.
Simplify VersionControlSpec interface


* Remove the `url` getter and setter

* Extend `Describable`

This will allow us to make fewer assumptions what it means to be a

version contorl repository. Maybe some of them won't have location

associated with them.

  1. … 4 more files in changeset.
Spike a GitVersionControlSystem

This spike just shows as a proof of concept how we can generically

approach version control system integration. This spike demonstrates:

* The use of a `VersionControlSpec` to define the url of the

remote repository.

* The use of a `VersionControlSystem` as the high-level abstraction

for all version control systems.

* A *very* rudimentary implementation of the `populate` method

for a `GitVersionControlSystem`

* An initial fixture for testing our Git integration.

The spike does not yet cover:

* How to get an instance of the correct type of version control

system based on the type of the version control spec that was

provided. But, we'll probably use some version control

system registry.

* Sophisticated handling for many common scenarios when

populating a working directory from a repository.

* Working directory exists and has correct remote.

* Working directory exists but is not a git repository.

* Working directory exists but has other remote.

* Multiple working directories for the same remote.

* Poorly formed user-input.

Related to

    • -0
    • +59
  1. … 9 more files in changeset.
Add VCS mapping API

Incorporate upstream changes

    • -0
    • +59
  1. … 37 more files in changeset.