possibility to specify custom rebase options?

[sentriz]

would it makes sense to allow custom rebase options for use with --and-rebase?

for example using the new rebase --update-refs feature of git

otherwise i need to do it manually, like

git add <files>
git absorb --base origin/master
git rebase -i --autosquash --update-refs origin/master

but maybe it could be nice to do it in 2 steps like

git add <files>
git absorb --update-refs --base origin/master # or whatever

[tummychow]

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:

• the current behavior remains the only thing we support - --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.
• use -- 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.
• add config options to set the --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.

[sentriz]

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!