git merge --no-commit with edits

Question

If I use

git merge --no-commit <other-branch>

and then make changes, such as removing files from the merge, is this still a real merge?

I would like the branches to be related (with a merge), but I don't want all of the changes in the in the new branch.

As a more concrete example, other-branch is a release branch from an older version. The current branch is the develop branch of the current product. We've made some changes for the release branch that should be moved to the develop branch.

We've used cherry-picks in the past, but I feel like there may be an advantage to having git understand a relationship between the two branches.

Is an edited merge still a merge?

Answer 1

Yes, it is still a merge. It doesn't matter whether you run git merge <other-branch>, or git merge --no-commit <other-branch>, the result will be a merge commit, that has two parents. The --no-commit option simply stops and lets you investigate that the merge went well before you commit the merge.

Answer 2

The --no-commit option simply stops and lets you investigate that the merge went well before you commit the merge.

This is now documented in Git 2.22 (Q2 2019)

See commit 1ede45e (21 Feb 2019) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 082c15a, 07 Mar 2019)}

merge-options.txt: correct wording of --no-commit option

The former wording implied that --no-commit would always cause the merge operation to "pause" and allow the user to make further changes and/or provide a special commit message for the merge commit.

This is not the case for fast-forward merges, as there is no merge commit to create.

Without a merge commit, there is no place where it makes sense to "stop the merge and allow the user to tweak changes"; doing that would require a full rebase of some sort.

Since users may be unaware of whether their branches have diverged or not, modify the wording to correctly address fast-forward cases as well and suggest using --no-ff with --no-commit if the point is to ensure that the merge stops before completing.

The documentation is clearer:

With --no-commit perform the merge and stop just before creating a merge commit, to give the user a chance to inspect and further tweak the merge result before committing.

Note that fast-forward updates do not create a merge commit and therefore there is no way to stop those merges with --no-commit.
Thus, if you want to ensure your branch is not changed or updated by the merge command, use --no-ff with --no-commit.