You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[](https://gitter.im/sbt/sbt-git?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
4
+
5
+
The `sbt-git` plugin offers git command line features directly inside sbt as
6
+
well as allowing other plugins to make use of git.
7
+
8
+
## Maintenance status
9
+
10
+
This plugin is community maintained. See https://github.com/sbt/sbt-git/issues/182 if you'd like to help.
11
+
12
+
## Installation ##
13
+
As of `1.0.0` this plugin requires at least **Java 8**.
14
+
The latest version supporting Java 7 was `0.9.3`, while the latest version supporting Java 6 was `0.8.5`.
15
+
16
+
Latest:
17
+
18
+
Add the following to your `project/plugins.sbt` or `~/.sbt/0.13/plugins/plugins.sbt` file:
additionally, use one of the older README.md files: (https://github.com/sbt/sbt-git/blob/v0.7.1/README.md)
29
+
30
+
### Using JGit ###
31
+
32
+
If you do not have git installed and available on your path (e.g. you use windows),
33
+
make sure your `git.sbt` or `~/.sbt/0.13/git.sbt` file looks like this:
34
+
35
+
useJGit
36
+
37
+
Or you can type this into the prompt:
38
+
39
+
> set useJGit
40
+
[info] Reapplying settings...
41
+
[info] Set current project to scala-arm (in build file:...)
42
+
> session save
43
+
[info] Reapplying settings...
44
+
[info] Set current project to scala-arm (in build file:...)
45
+
46
+
This will enable a java-only GIT solution that, while not supporting all the same
47
+
commands that can be run in the standard git command line, is good enough for most
48
+
git activities.
49
+
50
+
51
+
## Versioning with Git ##
52
+
53
+
You can begin to use git to control your project versions.
54
+
55
+
enablePlugins(GitVersioning)
56
+
57
+
The git plugin will now autogenerate your version using the following rules, in order:
58
+
59
+
1. Looks at version-property setting (default to `project.version`), and checks the `sys.props` to see if this has a value. If so, use it.
60
+
2. Otherwise, looks at the project tags. The first to match the `gitTagToVersionNumberSetting` is used to assign the version. The default is to look for tags that begin with `v` and a number, and use the number as the version. If there are multiple version tags, it will pick the highest.
61
+
3. If no tags are found either, look at the head commit. We attach this to the `git.baseVersion` setting: "<base-version>.<git commit sha>"
62
+
4. If no head commit is present either (which means this is a brand-new repository with no commits yet), we append the current timestamp to the base version: "<base-version>.<timestamp>".
63
+
64
+
The `git.baseVersion` setting represents the in-development (upcoming) version you're working on.
65
+
66
+
You can alter the tag-detection algorithm using the `git.gitTagToVersionNumber` setting. For example, if we wanted to alter the default version tag detection so it does not require a "v" at the start of tags, we could add the following setting:
67
+
68
+
git.gitTagToVersionNumber := { tag: String =>
69
+
if(tag matches "[0-9]+\\..*") Some(tag)
70
+
else None
71
+
}
72
+
73
+
You can turn on version detection using `git describe` command by adding:
74
+
75
+
git.useGitDescribe := true
76
+
77
+
This way the version is derived by passing the result of `git describe` to the `gitTagToVersionNumber` function. The `describe` version is built from the last tag + number of commits since tag + short hash. We recommend adopting the git describe approach.
78
+
79
+
You can enhance the git describe approach with `glob` pattern matching, to match only relevant tags (as per `git describe --match` functionality). This may be useful if, for example, your repository contains multiple types of tag.
80
+
81
+
git.gitDescribePatterns := Seq("module-name-*")
82
+
83
+
Additionally, you can also customize the version number generated by overriding one of the following keys:
84
+
85
+
*`git.formattedShaVersion` - Should look up `git.gitHeadCommit` key and generate a version based on it.
86
+
*`git.formattedDateVersion` - The version we'll use if git is unavailable on this repository, for some reason.
87
+
88
+
As an example, you can alter the default sha-based versions using the following code
You can use the git plugin to add the project name + the current branch to your prompt. Simply add this setting to every project:
96
+
97
+
enablePlugins(GitBranchPrompt)
98
+
99
+
## Usage ##
100
+
101
+
In an sbt prompt, simply enter any git command. e.g.
102
+
103
+
> git status
104
+
# On branch master
105
+
# Changes not staged for commit:
106
+
# (use "git add <file>..." to update what will be committed)
107
+
# (use "git checkout -- <file>..." to discard changes in working directory)
108
+
#
109
+
# modified: build.sbt
110
+
# modified: project/plugins/project/Build.scala
111
+
#
112
+
# Untracked files:
113
+
# (use "git add <file>..." to include in what will be committed)
114
+
#
115
+
# src/site/
116
+
no changes added to commit (use "git add" and/or "git commit -a")
117
+
118
+
119
+
## Known issues
120
+
When running sbt, you will see the following warnings in console:
121
+
```
122
+
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
123
+
SLF4J: Defaulting to no-operation (NOP) logger implementation
124
+
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
125
+
```
126
+
127
+
To get rid of them, you can force the SLF4J no-op binder by adding `libraryDependencies += "org.slf4j" % "slf4j-nop" % "1.7.21"` to `~/.sbt/0.13/plugins/plugins.sbt`
128
+
129
+
## Running the tests
130
+
131
+
Tests for this plugin are written using `sbt-scripted`. Test can be executed with
0 commit comments