Why does `git stash -p` sometimes fail? -
i ♥ git stash -p
. sometimes, after satisfying session of y
, n
, , s
, this:
saved working directory , index state wip on foo: 9794c1a lorum ipsum error: patch failed: spec/models/thing_spec.rb:65 error: spec/models/thing_spec.rb: patch not apply cannot remove worktree changes
why?
this happens me time try split hunk smaller hunks close (less 3 lines between changes). short explanation patch has context lines in conflict local changes. more complete explanation below.
suppose have git repo these uncommitted changes:
--- a/pangram +++ b/pangram @@ -1,8 +1,8 @@ -quick +relatively quick brown fox -jumps +walks on lazy
if stash first change, get:
--- a/pangram +++ b/pangram @@ -1,5 +1,5 @@ -quick +relatively quick brown fox jumps
the git stash
command succeed in saving patch (check git stash list
), git uses patch in reverse remove stashed changes working dir. context after hunk has "jumps", doesn't match "walks" still in working dir. git bails out with
error: patch failed: pangram:1 error: pangram: patch not apply cannot remove worktree changes
and leaves changes in working dir, , stash becomes pretty worthless.
i call bug in git's hunk splitting support. if knows it's splitting changes close, shave off few lines of context patch, or jimmy patch have modified context lines instead of pristine ones. alternatively, if splitting hunks close officially unsupported, should refuse split hunks close.
Comments
Post a Comment