Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Change to an invalid address

This makes it more clear that we are not hoping to find a real

repository at the URL in question.

Part of gradle/gradle-native#213

Add a test for non-repo error message

Fixes #213

  1. … 1 more file in changeset.
Revert "Remove jgit as a dependency for now"

This reverts commit 44153103683c94bd30d0ace6f7aa9584b40e5149.

    • -0
    • +164
    ./git/internal/GitVersionControlSystemSpec.groovy
  1. … 6 more files in changeset.
Remove jgit as a dependency for now

    • -164
    • +0
    ./git/internal/GitVersionControlSystemSpec.groovy
  1. … 6 more files in changeset.
Include simple test with locking

This is not sufficient to prove that pulling multiple

`VersionControlSpec`s in parallel to the same directory will be

safe. We still need to add some more sophisticated testing fixtures to

prove that.

This change also switches who has the responsibility for making the

"uniqueId()" for the `VersionControlSpec` globally unique. The

previous implementation wouldn't work given that the

`VersionControlSystem` would always be a

`ThreadSafeVersionControlSystem` no matter what the delegate

`VersionControlSystem` would be.

Part of gradle/gradle-native#146

    • -3
    • +3
    ./git/internal/DefaultGitVersionControlSpecSpec.groovy
  1. … 9 more files in changeset.
Refactor populate to return working directory

In an attempt to implement locking of the git clone directory in

gradle/gradle-native#146, we realized that the directory locking

mechanism writes a lock file into the directory being locked. That

lock file prevents jGit from cloning into the directory because it

expects directories to be empty when they are the target of a clone

operation.

This change moves the responsibility for calculating the path to the

working directory into the VersionControlSystem and provides the

populate method with a parent directory which can be the target of

locking.

Part of gradle/gradle-native#146

    • -44
    • +49
    ./git/internal/GitVersionControlSystemSpec.groovy
  1. … 6 more files in changeset.
GitVersionControlSystem.uniqueId return a string representing the git URL instead of a hash

    • -3
    • +3
    ./git/internal/DefaultGitVersionControlSpecSpec.groovy
  1. … 1 more file in changeset.
Switch getUniquePath() to getUniqueId()

We cannot use the `Path` type as it is considered an `internal`

type.

Part of gradle/gradle-native#87

    • -4
    • +3
    ./git/internal/DefaultGitVersionControlSpecSpec.groovy
  1. … 3 more files in changeset.
Address review feedback

    • -3
    • +4
    ./git/internal/DefaultGitVersionControlSpecSpec.groovy
    • -22
    • +18
    ./git/internal/GitVersionControlSystemSpec.groovy
  1. … 10 more files in changeset.
Add a GitVersionRef and implement getAvailableVersions

This should provide everything needed to make progress on

gradle/gradle-native#87

Part of gradle/gradle-native#88

  1. … 3 more files in changeset.
Add tests and fix DefaultGitVersionControlSpec

There were a few cases which weren't being handled correctly:

* We had too many slashes in our `repositoryId`s

* We were not extracting the repo name if the repo eneded in `.git`

Part of gradle/gradle-native#88

    • -0
    • +56
    ./git/internal/DefaultGitVersionControlSpecSpec.groovy
  1. … 1 more file in changeset.
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

Specifically:

* 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)

    • -8
    • +14
    ./git/GitVersionControlSystemSpec.groovy
  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.

    • -14
    • +6
    ./git/GitVersionControlSystemSpec.groovy
  1. … 1 more file in changeset.
Simplify VersionControlSpec interface

Specifically:

* 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
    • +2
    ./git/GitVersionControlSystemSpec.groovy
  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 https://github.com/gradle/gradle-native/issues/107

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

Incorporate upstream changes

    • -58
    • +0
    ./git/GitVersionControlSystemSpec.groovy
    • -0
    • +59
    ./git/internal/GitVersionControlSystemSpec.groovy
  1. … 37 more files in changeset.