Support for git restore (#51)

* Support for git restore, and a test for it.

* Updated bindata, and other autogenerated files.

* Revert changes to go.sum and go.mod (code review feedback)

* The file must be committed to be unstaged.

* Update bindata to be built with the latest version of go-bindata.

* ci: set travis to run on bionic distro

Should contain a more recent version of git.

* test: tag test @recent-git-only, remove travis restriction

There was a previous test that only worked on recent versions of git,
so replicate that tag, but since we've now upgraded travis we can remove
the restrictions on runs there.

* build: upgrade go version to go1.14

go-bindata wants to use the %w formatting directive for Errorf in its
generated files, which requires >= go1.13.

* ci: avoid vendor directory collision

Go modules assumes the vendor directory is for go modules if it exists,
so lets use something else to install bundler gems as a quick workaround

* test: disable flakey test for git change detection

This behavior appears to have changed again in more recent versions of
git, as the test case does not trigger the expected condition during
`git status --short` before even testing scmpuff. Disabling this test
for now until it can be reproduced reliably in modern git.

Co-authored-by: Matthew Rothenberg <mrothenberg@gmail.com>

.travis.yml

@@ -1,7 +1,7 @@
-sudo: false
+dist: bionic
 language: go
 go:
-  - 1.12
+  - 1.14
 
 env:
   - GO111MODULE=on
@@ -16,18 +16,18 @@ addons:
       - zsh
 
 install:
-  - bundle install --jobs 4 --retry 3 --path vendor/bundle
+  - bundle install --jobs 4 --retry 3 --path rbvendor/bundle
   - go mod download
 
 script:
   - go test ./...
   - script/build
-  - bundle exec cucumber -s --tags=~@wip --tags=~@recent-git-only
+  - bundle exec cucumber -s --tags=~@wip
 
 before_cache:
   - bundle clean
 
 cache:
   directories:
-    - vendor/bundle
+    - rbvendor/bundle
     - $GOPATH/pkg/mod

commands/inits/data/git_wrapper.sh

@@ -12,7 +12,7 @@ function git() {
   case $1 in
     commit|blame|log|rebase|merge)
       eval "$(scmpuff expand -- "$SCMPUFF_GIT_CMD" "$@")";;
-    checkout|diff|rm|reset)
+    checkout|diff|rm|reset|restore)
       eval "$(scmpuff expand --relative -- "$SCMPUFF_GIT_CMD" "$@")";;
     add)
       eval "$(scmpuff expand -- "$SCMPUFF_GIT_CMD" "$@")"

features/command_status.feature

@@ -162,44 +162,49 @@ Feature: status command
       """
 
 
-  @recent-git-only
-  Scenario: Handle change detection properly
-    Change detection is currently fairly rare in `git status`, mostly it only
-    happens after in index via diff or show.  But it can occur, so make sure we
-    support it when it happens, as it may be baked in better in the future.
-    Change detection naturally involves two filepaths, like rename.
-
-    In theory this is redundant with the "multiple filenames" scenario above,
-    but since change detection seems somewhat in flux we want to test for it
-    seperately in case its behavior changes in future versions of git.
-
-    Thanks to @peff on git mailing list for conditions to reproduce this.
-
-    Given I am in a git repository
-    And a 1000 byte file named "file"
-    And I successfully run the following commands:
-      | git add file       |
-      | git commit -m base |
-      | mv file other      |
-    Then I append to "file" with "foo"
-    And I successfully run `git add .`
-    # verify git behavior has not changed since this is hard to reproduce
-    When I successfully run `git status --short`
-    Then the stdout from "git status --short" should contain:
-      """
-      M  file
-      C  file -> other
-      """
-    # actual behavior test
-    When I successfully run `scmpuff status`
-    Then the stdout from "scmpuff status" should contain:
-      """
-      modified:  [1] file
-      """
-    And the stdout from "scmpuff status" should contain:
-      """
-      copied:  [2] file -> other
-      """
+  # CURRENT STATUS UNKNOWN! This behavior appears to have changed again in more
+  # recent versions of git, as the test case does not trigger the expected
+  # condition during `git status --short`. Disabling this test for now until it
+  # can be reproduced reliably in modern git.
+
+  # @recent-git-only
+  # Scenario: Handle change detection properly
+  #   Change detection is currently fairly rare in `git status`, mostly it only
+  #   happens after in index via diff or show.  But it can occur, so make sure we
+  #   support it when it happens, as it may be baked in better in the future.
+  #   Change detection naturally involves two filepaths, like rename.
+
+  #   In theory this is redundant with the "multiple filenames" scenario above,
+  #   but since change detection seems somewhat in flux we want to test for it
+  #   seperately in case its behavior changes in future versions of git.
+
+  #   Thanks to @peff on git mailing list for conditions to reproduce this.
+
+  #   Given I am in a git repository
+  #   And a 1000 byte file named "file"
+  #   And I successfully run the following commands:
+  #     | git add file       |
+  #     | git commit -m base |
+  #     | mv file other      |
+  #   Then I append to "file" with "foo"
+  #   And I successfully run `git add .`
+  #   # verify git behavior has not changed since this is hard to reproduce
+  #   When I successfully run `git status --short`
+  #   Then the stdout from "git status --short" should contain:
+  #     """
+  #     M  file
+  #     C  file -> other
+  #     """
+  #   # actual behavior test
+  #   When I successfully run `scmpuff status`
+  #   Then the stdout from "scmpuff status" should contain:
+  #     """
+  #     modified:  [1] file
+  #     """
+  #   And the stdout from "scmpuff status" should contain:
+  #     """
+  #     copied:  [2] file -> other
+  #     """
 
 
   Scenario: Status for a complex merge conflict

features/shell_wrappers.feature

@@ -72,3 +72,30 @@ Feature: optional wrapping of normal git cmds in the shell
       | shell |
       | bash  |
       | zsh   |
+
+
+  @recent-git-only
+  Scenario Outline: Wrapped `git restore` works
+    Given I am in a git repository
+      And a 2 byte file named "foo.bar"
+      And I successfully run `git add foo.bar`
+      And I successfully run `git commit -m "initial commit"`
+      And a 4 byte file named "foo.bar"
+      And I successfully run `git add foo.bar`
+    When I run `<shell>` interactively
+      And I type `eval "$(scmpuff init -ws)"`
+      And I type "scmpuff_status"
+      And I type "git restore --staged 1"
+      And I type "exit"
+    Then the exit status should be 0
+    When I run `scmpuff status`
+    Then the stdout from "scmpuff status" should contain:
+      """
+      ➤ Changes not staged for commit
+      #
+      #       modified:  [1] foo.bar
+      """
+    Examples:
+      | shell |
+      | bash  |
+      | zsh   |

go.mod

@@ -1,5 +1,5 @@
 module github.com/mroth/scmpuff
 
-go 1.12
+go 1.14
 
 require github.com/spf13/cobra v0.0.5