Add option for merging with a merge-commit or keep the merge strategy sets in the repository settings

[smartin-vossloh]

Hi @nwalfield ,

Thanks a lot for this action.

In our repositories we'd like to use the semi-linear history as merge strategy.
From our point of view this strategy offer a couple of advantages we need.
This means we want to:

• only merge fast-forward branches (so, check it while the PRs are open, and right before the merge);
• always have a merge commit.

Using only github settings allows enforcing the second point, but not the 1st one.

I hoped that using this fast-forward action will cover these 2 points.
Unfortunately, while it does enforce the 1st point, the 2nd one is not met.

I see various ways for implementing this:

• either add another option to force creating a merge commit (i.e. calling the git merge command with the --no-ff option);
• or check the repository settings and use them to set the merge strategy. (IMHO, this option could be more tricky to implement than the previous one).

Do you think the is a legit feature request for this action?

Or maybe there is already a way of doing this - so I just misused the action. In such case could you shade some light on the way to set the action to run this way?

TIA,
Regards,

[nwalfield]

Thanks for raising this issue. If I understand correctly, what you are saying is: you want a github action to check that the branch is fast-forward able, but when you do the merge, you want a merge commit. That is, if the last commit on main is A, and someone opens an MR with commit B, the action should check that main can be fast forwarded to B, i.e., the PR's commit graph looks like:

A -> B

When merging, you want:

A -> B ->  C
   `----------^

where C is a merge commit.

Is that correct?

I'm curious why you prefer this workflow. Would you mind explain its advantages?

This wasn't something that I'd considered when I created this action. It shouldn't be too hard to add it. If you want to contribute it, what do you think about the following? Add the file .github/workflows/fast-forward-merge.yml, which is triggered by the command /fast-forward-merge (basically, copy fast-forward.yml). Then, let's add an argument --merge-strategy to fast-forward.sh, which takes either fast-forward (the default) or merge. If merge is set, then it creates a merge commit. What do you think?

[smartin-vossloh]

@nwalfield Yes, this is exectly my needs.
When merging, it will become:

A ------> C
   `-> B -^

We want to have a semi-linear history in order to:

• keep a "high level" view of the features merged (usually a branch/PR matches a feature), just by looking at the merge-commits;
• easily identify what feature brings a given change.

As a side-effect, this also keeps the history easily bisect-able.

---

Your proposal sounds good. 👍

[smartin-vossloh]

Still in development