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

From: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Date: Jan 23, 2019, 07:04 UTC
Message-ID: <5C481202020000A10002F4AE@gwsmtp1.uni-regensburg.de>
In-Reply-To: <CABPp-BFGfWPAwKLMMMLdLu856UvrrSMYjYWXeVUxEqpspBxbsA@mail.gmail.com>

>>> Elijah Newren <newren@gmail.com> schrieb am 22.01.2019 um 22:29 in

Nachricht <CABPp-BFGfWPAwKLMMMLdLu856UvrrSMYjYWXeVUxEqpspBxbsA@mail.gmail.com>:

Show 8 quoted lines

> Hello,
> 
> On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl
> <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>
>> Hi!
>>
>> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that "--no-commit"

Show 25 quoted lines

> 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.
> 
>>  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.

Actually no: The changes were on a different local "remote" branch; otherwise I wouldn't need the merge, I guess

> 
>> Reading
>> https://stackoverflow.com/questions/8640887/git-merge-without-auto-commit

it

>> seems that without "--no-ff" this ioption is effectively ignored.

Note: If you see the number of upvotes to the answer there, it seems I'm not
the only one who got confused. ;-)

>> If so, I suggest to tell the user that --no-commit is useless in this case,

Show 11 quoted lines

> 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.

Is moving commits from one branch to to another done without any new commit? Just updating the refs, or what? I didn't know that.

> 
> 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.

So it seems a commit is something other than I'd expected: To me anything that changes what "git log" outputs is a commit ;-) Or anything that chenges the reflog...

Show 9 quoted lines

> 
> 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.

No, it seems I didn't realize that a fast-forward actually is without a commit.

Show 5 quoted lines

> 
> 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?

Maybe (I'm unsure where the concepts are described best to check the current version(s)) try to explain the concepts of "commit" and "fast forward" in some greater detail. Maybe I was just expecting the wrong things to happen behind the scenes. Maybe add a statement like "fast-forwards never create a new commit, so --no-commit doesn't make sense when fast-forwarding."

Thanks for the explanations.

Regards, Ulrich