Re: Q: What happened to "--no-commit" merges?

From: Elijah Newren <newren@gmail.com>
Date: Jan 22, 2019, 21:29 UTC
Message-ID: <CABPp-BFGfWPAwKLMMMLdLu856UvrrSMYjYWXeVUxEqpspBxbsA@mail.gmail.com>
In-Reply-To: <5C47833C020000A10002F499@gwsmtp1.uni-regensburg.de>

Hello,

On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

Show 11 quoted lines

>
> Hi!
>
> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that "--no-commit" no
> longer does what it did before (AFAIR, but I mostly did --no-ff merges in
> SLES11):
> Like this (sorry German):
>
> > git merge --no-commit local/f-linux-firefox
> Aktualisiere 520aaae..c11e3da
> Fast-forward

Ah, a fast foward, so there was nothing to commit; it could simply update the branch to include commits that already existed.

Show 9 quoted lines

>  bin/fval.xsl | 133 +++++++++++++++++++++++++----------------------------------
>  1 file changed, 57 insertions(+), 76 deletions(-)
>
> > git status
> Auf Branch f-linux-firefox
> nichts zu committen, Arbeitsverzeichnis unverändert
>
> ### "nothing to commit"
> git log indicates the changes were committed already

Indeed; the changes were committed before you ran "git merge"; they were all part of the local/f-linux-firefox branch.

Show 6 quoted lines

> Reading
> https://stackoverflow.com/questions/8640887/git-merge-without-auto-commit it
> seems that without "--no-ff" this ioption is effectively ignored.
> If so, I suggest to tell the user that --no-commit is useless in this case, and
> let him confirm that he/she wants the changes (merge) to be committed (despite
> of --no-commit).

--no-commit, to me, means don't create any new commits. But you had a case where there was no need to create a any new commits: your branch (f-linux-firefox, I think?) had no commits that the other branch (local/f-linux-firefox) lacked, but the other branch had at least one you lacked. So, merging could be done by just moving your branch pointer to include all those existing commits.

If you want the branch to not get updated, then yes you'd need both --no-ff and --no-commit in some cases. But that's always been true. It's possible in the past that you just didn't run into those cases.

Now, if you're suggesting that --no-commit should imply --no-ff, that's interesting. However, you are fundamentally changing the operation at that point by making it so that a merge commit will be created when the user runs `git commit` at the end -- it's not clear to me that users will see a merge commit as wanted or needed and having --no-commit imply that option might break expectations. I'd be more inclined to tell users who want --no-ff behavor to use that flag and/or set the merge.ff config setting to false.

Alternatively, we could update the documentation to point out this special case under --no-commit to point out that when an ff-update occurs no commit creation is involved and thus --no-commit has no effect. Would that help?

Elijah