Merge pull request #76 from kotct/release/v0.1.0

Release v0.1.0

.emacs.d/init.el

@@ -125,3 +125,4 @@ Despite this, your config appears to have loaded successfully.")
 ;; We set this to something we don't track because it can be unique
 ;; for each system.
 (setf custom-file "~/.emacs.d/custom.el")
+(load custom-file 'noerror)

.emacs.d/lisp/code/code-hub.el

@@ -1,6 +1,7 @@
 (kotct/hub "code"
            (editorconfig-c
             magit-c
+            smartparens-c
             indentation
             code-navigation))
 

.emacs.d/lisp/code/magit-c.el

@@ -1,5 +1,11 @@
-(setf magit-push-always-verify nil)
-(setf magit-last-seen-setup-instructions "1.4.0")
+(with-eval-after-load 'magit
+  (let ((popups-to-add-sign '(magit-merge-popup
+                              magit-rebase-popup)))
+    (mapcar (lambda (popup)
+              (magit-define-popup-option
+                popup
+                ?S "Sign using gpg" "--gpg-sign=" #'magit-read-gpg-secret-key))
+            popups-to-add-sign)))
 
 (global-set-key (kbd "C-x m") #'magit-status)
 

.emacs.d/lisp/code/smartparens-c.el

@@ -0,0 +1,5 @@
+(require 'smartparens-config)
+
+(smartparens-global-mode t)
+
+(provide 'smartparens-c)

.emacs.d/lisp/file/file-content.el

@@ -0,0 +1,6 @@
+;; make sure files always have a LF at EOF when saving
+;; if you don't want this for a particular file, do
+;; M-x set-variable RET require-final-newline RET nil RET
+(setf require-final-newline t)
+
+(provide 'file-content)

.emacs.d/lisp/file/file-hub.el

@@ -1,7 +1,8 @@
 (kotct/hub "file"
            (backup
             recentf-c
-            tramp-c)
+            tramp-c
+            file-content)
            (recursive-make))
 
 (provide 'file-hub)

.emacs.d/lisp/package/dependencies.el

@@ -20,6 +20,7 @@
     elixir-mode ;; for editing Elixir code
     rust-mode ;; for editing Rust code
     buttercup ;; for tests
+    smartparens ;; for dealing with paired control flow symbols
 
     ;; THEMES
     solarized-theme)

.emacs.d/test/lisp/code/magit-c-test.el

@@ -0,0 +1,16 @@
+(kotct/load-corresponding)
+
+(describe "magit config"
+  (describe "popups"
+    :var (magit-sign-option)
+    (before-all
+      (require 'magit)
+      (setf magit-sign-option '(?S "Sign using gpg" "--gpg-sign=" magit-read-gpg-secret-key nil)))
+    (describe "merge popup"
+      (it "includes sign option"
+        (expect (member magit-sign-option (plist-get magit-merge-popup :options)) :to-be-truthy)))
+    (describe "rebase popup"
+      (it "includes sign option"
+        (expect (member magit-sign-option (plist-get magit-rebase-popup :options)) :to-be-truthy))))
+
+  (kotct/it-binds magit-status "C-x m"))

.emacs.d/test/lisp/code/smartparens-c-test.el

@@ -0,0 +1,5 @@
+(kotct/load-corresponding)
+
+(describe "smartparens config"
+  (it "turns the `smartparens-global-mode' minor mode on"
+    (expect smartparens-global-mode :to-be-truthy)))

.emacs.d/test/lisp/dot-tests.el

@@ -11,6 +11,7 @@ If THROW-ERROR is non-nil, re-throw the caught error."
        (if throw-error
            (error (cdr err))))))
 
+;; test helper functions
 (defun kotct/load-corresponding ()
   "Load the file corresponding to the current test.
 Only works when called in script mode."
@@ -23,6 +24,15 @@ Only works when called in script mode."
        (regexp-quote "/test/") "/"
        load-file-name)))))
 
+(defmacro kotct/it-binds (fun binding)
+  "Generate a spec in the current test that makes sure FUN
+is bound to BINDING.
+
+For example, if `magit-status' is bound to \\[magit-status], then to use,
+write in the test: (kotct/it-binds magit-status \"\\[magit-status]\")"
+  `(it ,(format "binds %s to %s" fun binding)
+     (expect (global-key-binding (kbd ,binding)) :to-be #',fun)))
+
 (defun kotct/run-tests ()
   "Run all emacs lisp tests for the kotct/dot emacs configuration."
   (interactive)

.emacs.d/test/lisp/file/file-content-test.el

@@ -0,0 +1,5 @@
+(kotct/load-corresponding)
+
+(describe "file content config"
+  (it "should require newlines at EOF"
+    (expect require-final-newline :to-equal t)))

.travis.yml

@@ -22,3 +22,4 @@ script:
 notifications:
   slack:
     secure: Pu2AagcBjx2iBPwsIJ3oNdB5koGfqSP12Mat9KYajxtIwbyzgGsToiyma3+s+Yl02+IRZdGonZaKH/c2RGNF05PK4PAoNfkhYafiog4hKD5ZusIi1xVr0zWOREZVsqpAeu0cxs/b+p7Va66+CRukGYxTGs0LjfEXoJ3KRJYwziSVDYVEoujGHFTPKlyNZNU0fSW+pioVneiVy+hpVvfdzqby9WJG9nK/607xceJ+HVdntXABnUBDk6/1KVqbH36U2Xlw2hlRebGWIowqg/S6yOqn+NxvrM5FNb7LHWxx/mLM3o5Ml1pm9mcDS0M+sPOquLlW/0NPfiV3cz485W6aoSo37z9eassQ4DKQsEjiL4AfGXH4Wgu3BASnWTMkSXfGwW09rKSu1PCyozp76htkiMWp2tJQo/GUAey7PYTSEHhFWBhBL2UaJ3WY4H/1SdaVqHwnBNXU6YEMIJn0S7F31MmQUmSIcVMbqP9XojWl9DHDKP9o4S5CCshYlKR3XzdSeOzyQKb2PKr5NAtU2lYVMfL4XYEsz+sWO1yOCUB+U0yVXdk9kInGHY5AAwIJ6v/ODSDGW67SlXMAJcrkW2nlX8I9JZ+aR4vKo47j+MCPsPMBaPoHyGquVe9++iq67Kdxl18azrQ6fVbjNda3LRTZVH9ekWRf9eMsVBbSeyORUx8=
+    on_success: change

CONTRIBUTING.md

@@ -36,29 +36,40 @@ In general, here's a suggested workflow:
 
 ***Note: This guide is intended mainly for core contributors.***
 
-Dot uses [SemVer v2](http://semver.org/spec/v2.0.0.html) as a model to standardize our versioning system.
-A "breaking change" in our context is something that might cause a user to have to change their personal config; any change to the "API" (which is the set of functions exposed to the user) is considered as such.
+Dot uses a development flow very similar to [GitLab Flow](https://about.gitlab.com/2014/09/29/gitlab-flow/) as a model for development.
+For versioning, Dot complies with [SemVer v2](http://semver.org/spec/v2.0.0.html).
+In our context, a "breaking change" is something that causes users who used previous functions and such to have to change their personal configuration in order to continue working.
 
-In general, our branching workflow consists of two persistent branches:
+Our branching workflow consists of two persistent branches:
 
-- `master`, which contains all of the latest changes and should be in a stable state.
+- `master`, which contains all of the latest changes and should be in a usable state for testing.
   This is used as the base for all of the `release/*` branches (see below.)
 - `stable`, which is a tracking branch that gets releases merged into it.
-  This is the branch to be used by users who only want stable features to be added to their configuration.
+  This is the branch to be used by users who want only releases that have been deemed stable.
 
-In addition, we use the following scheme for additional branches:
+We use the following scheme for additional branches:
 
-- `release/vX.Y` and `release/vX.Y.Z` branches are branches used to control versioning.
-  - To release a new version from `master`,
-    1. After merging all PR's into `master`,
-    2. Create your `release/vX.Y(.Z)` branch.
-    3. Bump the version on the `release/vX.Y(.Z)` branch in a commit.
-       If you have any release notes to add, do so here.
-    4. Merge the branch into `stable` via a PR.
-    5. Create a release targeting the PR merge commit into `stable`.
-    6. Make a PR to merge back into `master`.
 - `feature/` can be used as a prefix for feature branches, but this is not recommended.
   (Just use `kebab-case` for your branch names, we assume that anything without a special prefix is a normal feature PR.)
 - `hotfix/` should be used as a prefix for hotfix branches.
-  In the discussion of a problem, the maintainers will decide what version to release the hotfixes as and will create a `release/vX.Y.Z` branch for you to use as your base.
-  If a hotfix targets a release, (which is the typical case) the nascent `release/vX.Y.Z` branch should thus be used; submit a PR for the `hotfix/` branch into the `release/vX.Y.Z` branch.
+  Hotfixes should _always_ target and be based off of `master`;
+  they will be cherry-picked into a `release` branch (see below) if a new patch version is necessary.
+- `release/vX.Y.Z` branches are used to control versioning.
+  The contents of the `VERSION` file on `master` will _always_ be something like `X.Y.0-pre`, as we do not do releasing on `master`.
+  There are two major situations in which `release/` branches get used, and here are the corresponding guidelines for the release process:
+  - When releasing a new minor version from `master`,
+    1. Create a `release/vX.Y.0` branch off of the latest version of `master`.
+    2. Change the `VERSION` file to contain `X.Y.0`.
+    3. If necessary, add any release notes here.
+    4. Merge the branch into `stable` via PR.
+    5. Create a release targeting the PR merge commit into `stable`.
+    6. Delete your `release/vX.Y.0` branch.
+  - When releasing a patch version of an existing minor version.
+    1. Create a `release/vX.Y.Z` branch off the previous `vX.Y.Z` tag.
+    2. Use `git cherry-pick` to cherry-pick the hotfix commits necessary to satisfy your patch requirements into the `release/vX.Y.Z` branch.
+       If the `hotfix` commits depend on any features (which is a nasty situation to get into) make sure to cherry-pick those features in order with the commits.
+    3. Change the `VERSION` file to contain `X.Y.Z`,
+    4. If necessary, add any release notes here.
+    5. Merge the branch into `stable` via PR.
+    6. Create a release targeting the PR merge commit into `stable`.
+    7. Delete your `release/vX.Y.Z` branch.

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2017 Christopher Cooper, Samuel Mercier, and Kristofer Rye
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -206,3 +206,9 @@ Up for debate:
   global definitions) have docstrings that are properly formatted.
 - Comment when it's not immediately clear what the code is doing.
 - Write modular, clean, and fast code.
+
+## License
+
+`dot` is released and distributed under the terms of the MIT license.
+See [`LICENSE`](https://github.com/kotct/dot/blob/master/LICENSE) for
+more information.

VERSION

@@ -1 +1 @@
-0.0.0
+0.1.0