git-rev-list(1) orders the printed revisions before printing. This is
quite complicated and I noticed that it behaves in unexpected ways
w.r.t. commits given individually: sometimes they are reordered,
sometimes not. This is problematic when interdependent commits are given
via the command line individually: If they aren't re-ordered by
git-rev-list(1), we'd be cherry picking them in reverse order.
To solve this, just call git-rev-list(1) on all arguments individually,
allowing ranges to be resolved, but always picking individual arguments
in the correct order.
Notably, this means that excluding commits via individual REV^ arguments
won't ever work, but I believe this wasn't possible previously
anyways (maybe due to --no-walk?).
Change-Id: If8e83e0b47a74baf37d77b6c4f68a55af944b366
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13149
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
This is occasionally necessary. --force-with-lease should also be
supported in the future, unfortunately getopts(1) doesn't have --long
option support.
Change-Id: Ib054009f48585b1a52ed041a51bcaf7e32dca1b3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12904
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Small git subcommand that enables you to push a subset of (independently
apply-able) commits from a local chain of commits to a remote ref, e.g.
for review. Useful for a workflow where you work on a chain of commits
and want to submit the ones that have been finished for review without
rebasing the chain.
Change-Id: I7717fe37867acdd826bc03a578104a0c3b2cbf71
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12900
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
