Closed janpio closed 1 month ago
From a quick look at the codebase, it seems we would need to add the options to the command here: https://github.com/peter-evans/rebase/blob/7cd171d8b1687c5c4ac2e6679371326df95eb607/src/rebase-helper.ts#L89 (which means adding a param to the function). That code is called via https://github.com/peter-evans/rebase/blob/7cd171d8b1687c5c4ac2e6679371326df95eb607/src/rebase-helper.ts#L13, which would then also need a second argument to be used at https://github.com/peter-evans/rebase/blob/7cd171d8b1687c5c4ac2e6679371326df95eb607/src/main.ts#L57. It might make sense to call the additional input gitRebaseOptionsString
and add it here then https://github.com/peter-evans/rebase/blob/7cd171d8b1687c5c4ac2e6679371326df95eb607/src/main.ts#L15-L23 - and then just use that string for the function parameters mentioned before.
Does that sound about right?
Hi @janpio
Sounds like it could be useful in some specific cases.
Does that sound about right?
Yes, pretty much.
Note that each option must be separate param when passing to git.exec([...])
, so you need to split the input by whitespace.
It might make sense to call the additional input
gitRebaseOptionsString
I would suggest something a bit simpler like rebase-options
for the action's input.
Feel free to have a go at adding this functionality if that's something you are interested in doing.
We have a use case where we know exactly that we want to accept "their" code on a conflict during a rebase. It would be great if we could configure the extension in a way that it accepts a string of
git rebase
options like-Xtheirs
.