Closed sentriz closed 1 year ago
so the problem with this is it massively complicates the cli of git-absorb. the cli of git-rebase is sizable and complex - there are tons of options, some that are legal with each other and some that aren't, etc. we would basically have to add every single one of these options to git-absorb and i really do not want to go down that slippery slope. to me there are a few principled ways to approach this:
--and-rebase
does the most basic thing and you have to break out to a separate command for anything else. you could imagine adding a git-absorb --show-base
to print the inferred base commit and then eg git rebase $(git absorb --show-base) --update-refs ...
but ultimately composing any nontrivial rebase command is the user's responsibility.--
to pass arbitrary flags to git-rebase, again with the understanding that validating them is entirely the user's responsibility. eg git absorb --and-rebase -- --update-refs ...
. this only works because --
tells us not to parse the flags intended for git-rebase. if you intermingle the git-rebase flags with the git-absorb flags, you're giving your cli parser crate a very unpleasant problem to solve.--and-rebase
command, but obviously this doesn't let you change the flags conveniently between invocations.i would probably consider prs for any of these, but i'm not adding options from git-rebase directly into the clap args.
thanks for the response :+1: that all makes sense to me. i think i like the sound of option 1, but you're right in that this sort of stuff shouldn't be git-absorbs responsibility. i was also just wondering did you have a nice solution to this in mind. so thanks!
would it makes sense to allow custom rebase options for use with --and-rebase?
for example using the new
rebase --update-refs
feature of gitotherwise i need to do it manually, like
but maybe it could be nice to do it in 2 steps like