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
{{ message }}
Repository navigation
Do not run stash operations when not necessary #669
Issues #135 and #504 indicate that the stashing process, while convenient for a certain use case, introduces issues and risk of loss of files, under edge cases.
Editor flicker (VSCode on Mac, at least), the possibility that an abort (via ^C) leaves the working tree worse than before - these are issues that users need not be exposed to if they have a workflow where the hooks can and should be run on the entire working tree, because they have no unstaged changes while committing.
We discussed the desirability of this on #135 and I'm opening this issue to attach a PR to. Will need some help! But I think there will be a benefit to users who enjoy Overcommit, but who don't regularly make commits with only some of the changes staged..
I can add that my workflow, involves using stashes for the sake of applying console.log and other non-commit-worthy diffs, and manual reversion. I don't try to write the commit message and run hooks and commit until my tools very clearly show me what I'm committing and not. So I've never been in need of stashing. But perhaps by excluding use cases like mine from stashing, Overcommit can provide the best of both worlds.
So let me know how this sounds.. Because OC is good at restoring contents (and modification times) of files, the way to know whether stashing/restoring takes place could be the reflog.
Starting with this reflog (with most recent commit on top)
413aad983c HEAD@{0}: commit: test:: octest
16cd46c551 HEAD@{1}: reset: moving to HEAD
A commit that bypasses commit hooks and stashing goes directly on top:
e4745fb9c2 HEAD@{0}: commit: test:: octest, no stash
413aad983c HEAD@{1}: commit: test:: octest
16cd46c551 HEAD@{1}: reset: moving to HEAD
Whereas one that uses stashing adds more reflog entries:
027ec917d0 HEAD@{0}: commit: test:: octest, w/ stash
e4745fb9c2 HEAD@{1}: reset: moving to HEAD
e4745fb9c2 HEAD@{2}: reset: moving to HEAD
e4745fb9c2 HEAD@{3}: reset: moving to HEAD
e4745fb9c2 HEAD@{4}: commit: test:: octest, no stash
413aad983c HEAD@{5}: commit: test:: octest
So is that the best way to see whether stashing occurred, or was bypassed? I've started the tests, I'm looking for ways to fill them out. Many thanks in advance!
Hey @deanius, thanks for putting together a proposal.
If there isn't a clear way to determine whether a stash had occurred, then perhaps we should simply structure the code to check if a given method was called.
@changes_stashed=`git stash list -1`.include?(stash_message)
into a helper method stash_changes, and in our tests validate that the helper method was never called in the case we are trying to validate.
context'when all changes have been staged'doarounddo |example|
repodoecho('Hello World','tracked-file')echo('Hello Other World','other-tracked-file')`git add tracked-file other-tracked-file`example.runendendit'does not stash changes'doexpect(context).to_notreceive(:stash_changes)subjectend
...simliarly for cleanup_environment tests:
it'does not restore the stash'doexpect(context).to_notreceive(:restore_stash_changes)subjectendend
Activity
deanrad commentedon Sep 11, 2019
So let me know how this sounds.. Because OC is good at restoring contents (and modification times) of files, the way to know whether stashing/restoring takes place could be the reflog.
Starting with this reflog (with most recent commit on top)
A commit that bypasses commit hooks and stashing goes directly on top:
Whereas one that uses stashing adds more reflog entries:
So is that the best way to see whether stashing occurred, or was bypassed? I've started the tests, I'm looking for ways to fill them out. Many thanks in advance!
sds commentedon Sep 13, 2019
Hey @deanius, thanks for putting together a proposal.
If there isn't a clear way to determine whether a stash had occurred, then perhaps we should simply structure the code to check if a given method was called.
For example, extract:
overcommit/lib/overcommit/hook_context/pre_commit.rb
Lines 53 to 68 in 5a6ca89
stash_changes, and in our tests validate that the helper method was never called in the case we are trying to validate....simliarly for
cleanup_environmenttests:Does that seem reasonable?
deanrad commentedon Sep 27, 2019
I'm definitely in agreement, but not expert with Ruby mocking and event the first assertion here doesn't pass..
I hope this doesn't mean I'm at the end of my line trying to help, but I'm not sure I can.
Avoid stashing changes when all changes are staged
Avoid stashing changes when all changes are staged
Avoid stashing changes when all changes are staged
Support hook side effects without stashing repository changes (#939)