This is a hack-day contribution and is not done in an elegant way, but I believe it's functional
In order to implement --no-commit cleanly, I think we would need to refactor computeChanges() in cherry_pick_utils.js. It currently only supports computing changes between two commits. But if it were able to compute changes between the index and a target commit, then we could keep applying changes to the index without needing to commit them.
The way things stand in the code right now, in order to do subsequent cherry-picks, I would need each intermediate state to be fully committed and with a clean working directory. Thus, the fastest way I saw to work around this was to let cherry-pick perform all the necessary commits, but then soft reset them.
In essence, this PR's git meta cherry-pick --no-commit is equivalent to:
git meta cherry-pick sha1 sha2 ... shaN
git meta reset --soft HEAD~N
This PR is related to #703
This is a hack-day contribution and is not done in an elegant way, but I believe it's functional
In order to implement
--no-commitcleanly, I think we would need to refactorcomputeChanges()incherry_pick_utils.js. It currently only supports computing changes between two commits. But if it were able to compute changes between the index and a target commit, then we could keep applying changes to the index without needing to commit them.The way things stand in the code right now, in order to do subsequent cherry-picks, I would need each intermediate state to be fully committed and with a clean working directory. Thus, the fastest way I saw to work around this was to let cherry-pick perform all the necessary commits, but then soft reset them.
In essence, this PR's
git meta cherry-pick --no-commitis equivalent to: