Skip to content

Improve revert target determination in `rebase` and `checkout` #82

theory opened this Issue Mar 25, 2013 · 0 comments

1 participant

theory commented Mar 25, 2013

I have often been annoyed when I've run sqitch rebase when no changes are deployed. It refuses to run! Instead, I think it should just go ahead and deploy.

Similarly, I suspect it would be best if, when using checkout if there is no common change between the two branches, to revert all changes from the current branch, rather than throw an exception.

@theory theory was assigned Mar 25, 2013
@theory theory added a commit that referenced this issue Mar 25, 2013
@theory Teach `rebase` not to die if nothing needs reverting.
Instead, make a note of it and then get on with the deploy. This simplifies
the case I've often run into where I rebase, everything reverts, then the
deploy fails. I fix the failure then try to rebase again, and it would fail
because everything was already reverted. So now we just go ahead and do the
deploy. Ref issue #82.
@theory theory added a commit that closed this issue Mar 25, 2013
@theory Teach `checkout` not to die on non-fatal revert errors.
These happen when there is nothing to revert to meet the specified target. So
just emit information about why nothing was reverted and move on to the
deploy. Resolves #82.
@theory theory closed this in dd973a0 Mar 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.