Can we not override previous update-flake-lock action commits when a PR is already open? #174
Description
When there is an automated PR already open and the action gets triggered again, it force overrides any previous update-flake-lock action commits in this existing PR.
Instead, is there a way to have the next runs of the action perform a merge of the base branch and then on top push a new commit that updates flake.lock so that it doesn't force override the previous update commits made by the update-flake-lock action?
My use case: I use update-flake-lock action to automatically update my flake.lock and create a PR which then performs a build of this newly updated nix configuration in the CI. If the config builds without errors then I merge the update-flake-lock action PR in. However, there are times when I want to see how the config build of the previous invocations of update-flake-lock action targeting the already created PR were like.
In such cases, it seems difficult to go back into the commit history and see the CI build checks, since the latest invocation of update-flake-lock action has overridden any previous update-flock-lock action commits. I'd like to be able to quickly go through a PR and see what the last successful build commit was so I am able to (manually) merge the update PR into the base branch only up till this last good commit.
Such as this automated PR previously stayed open for a month because of upstream updates to a few packages breaking the config build:
ritiek/dotfiles#16
But I can't go back and visualize what packages were breaking the config build presumably due to the previous commits getting overridden in this PR. I guess this can be fixed with some git magic in my action.yml, but unless I overlooked something, was curious whatcha y'all think about having such a feature to not override previous commits, in update-flock-lock action itself.