threads / discuss / 48496

could `git merge --no-ff origin/master` be made more useful?

Subject: could `git merge --no-ff origin/master` be made more useful?

## tl;dr

3 messages between May 14, 2018 and May 15, 2018.

replies: 2people: 2as markdown or json

demerphq· May 14, 2018, 22:08 UTC · lore
The first time I tried to use --no-ff I tried to do something like this:
  git checkout master
  git commit -a -m'whatever'
  git commit -a -m'whatever2'
  git merge --no-ff origin/master

and was disappointed when "it didn't work" and git told me there was nothing to do as the branch was up to date. (Which I found a bit confusing.)

I realize now my expectations were incorrect, and that the argument to merge needs to resolve to a commit that is ahead of the current commit, and in the above sequence it is the other way around. So to do what I want I can do:

  git checkout master
  git checkout -b topic
  git commit -a -m'whatever'
  git commit -a -m'whatever2'
  git checkout master
  git merge --no-ff topic
and iiuir this works because 'master' would be behind 'topic' in this case.

But I have a few questions, 1) is there is an argument to feed to git merge to make the first recipe work like the second? And 2) is this asymmetry necessary with --no-ff?

More specifically would something horrible break if --no-ff origin/trunk detected that the current branch was ahead of the named branch and "swapped" the implicit order of the two so that the first recipe could behave like the second?

Anyway, even if the above makes no sense, would it be hard to make the message provided by git merge in the first recipe a bit more suggestive of what is going on? For instance if it had said "Cannot --no-ff merge, origin/master is behind master" it would have been much more clear what was going on.

Yves
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
Ævar Arnfjörð Bjarmason· May 14, 2018, 22:58 UTC · re: demerphq · lore

Re: could `git merge --no-ff origin/master` be made more useful?

On Mon, May 14 2018, demerphq wrote:
Show 28 quoted lines
> The first time I tried to use --no-ff I tried to do something like this:
>
>   git checkout master
>   git commit -a -m'whatever'
>   git commit -a -m'whatever2'
>   git merge --no-ff origin/master
>
> and was disappointed when "it didn't work" and git told me there was
> nothing to do as the branch was up to date. (Which I found a bit
> confusing.)
>
> I realize now my expectations were incorrect, and that the argument to
> merge needs to resolve to a commit that is ahead of the current
> commit, and in the above sequence it is the other way around. So to do
> what I want I can do:
>
>   git checkout master
>   git checkout -b topic
>   git commit -a -m'whatever'
>   git commit -a -m'whatever2'
>   git checkout master
>   git merge --no-ff topic
>
> and iiuir this works because 'master' would be behind 'topic' in this case.
>
> But I have a few questions, 1) is there is an argument to feed to git
> merge to make the first recipe work like the second? And 2) is this
> asymmetry necessary with --no-ff?

I've been bitten my this myself, but found that it's documented as the very first thing in git-merge:

    Incorporates changes from the named commits (since the time their
    histories diverged from the current branch) into the current
    branch[...].

Since origin/master hasn't diverged from your current branch (unlike the other way around), the merge with --no-ff is a noop.

> More specifically would something horrible break if --no-ff
> origin/trunk detected that the current branch was ahead of the named
> branch and "swapped"  the implicit order of the two so that the first
> recipe could behave like the second

If it worked like that then the user who sets merge.ff=false in his config and issues a "git pull" after making a commit on his local master would create a merge commit.

This old E-Mail of Junio's discusses that edge case & others in detail: https://public-inbox.org/git/7vty1zfwmd.fsf@alter.siamese.dyndns.org/

Show 5 quoted lines
> Anyway, even if the above makes no sense, would it be hard to make the
> message provided by git merge in the first recipe a bit more
> suggestive of what is going on? For instance if it had said "Cannot
> --no-ff merge, origin/master is behind master" it would have been much
> more clear what was going on.

I can't spot any reason for why we couldn't have something like this POC (would be properly done through advice.c):

    diff --git a/builtin/merge.c b/builtin/merge.c
    index 9db5a2cf16..920f67d9f8 100644
    --- a/builtin/merge.c
    +++ b/builtin/merge.c
    @@ -1407,6 +1407,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
                     * but first the most common case of merging one remote.
                     */
                    finish_up_to_date(_("Already up to date."));
    +               if (fast_forward == FF_NO)
    +                       fprintf(stderr, "did you mean this the other way around?\n");
                    goto done;
            } else if (fast_forward != FF_NO && !remoteheads->next &&
                            !common->next &&

But that should probably be reworked to be smart about whether --no-ff or merge.ff=false was specified, i.e. do we want to yell this at the user who's just set that at his config default, or the user who's specified --no-ff explicitly, or both? I don't know.

demerphq· May 15, 2018, 08:27 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: could `git merge --no-ff origin/master` be made more useful?

On 15 May 2018 at 00:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 41 quoted lines
>
> On Mon, May 14 2018, demerphq wrote:
>
>> The first time I tried to use --no-ff I tried to do something like this:
>>
>>   git checkout master
>>   git commit -a -m'whatever'
>>   git commit -a -m'whatever2'
>>   git merge --no-ff origin/master
>>
>> and was disappointed when "it didn't work" and git told me there was
>> nothing to do as the branch was up to date. (Which I found a bit
>> confusing.)
>>
>> I realize now my expectations were incorrect, and that the argument to
>> merge needs to resolve to a commit that is ahead of the current
>> commit, and in the above sequence it is the other way around. So to do
>> what I want I can do:
>>
>>   git checkout master
>>   git checkout -b topic
>>   git commit -a -m'whatever'
>>   git commit -a -m'whatever2'
>>   git checkout master
>>   git merge --no-ff topic
>>
>> and iiuir this works because 'master' would be behind 'topic' in this case.
>>
>> But I have a few questions, 1) is there is an argument to feed to git
>> merge to make the first recipe work like the second? And 2) is this
>> asymmetry necessary with --no-ff?
>
> I've been bitten my this myself, but found that it's documented as the
> very first thing in git-merge:
>
>     Incorporates changes from the named commits (since the time their
>     histories diverged from the current branch) into the current
>     branch[...].
>
> Since origin/master hasn't diverged from your current branch (unlike the
> other way around), the merge with --no-ff is a noop.
Yeah, I got it, but only after rereading a lot of times.
Show 12 quoted lines
>
>> More specifically would something horrible break if --no-ff
>> origin/trunk detected that the current branch was ahead of the named
>> branch and "swapped"  the implicit order of the two so that the first
>> recipe could behave like the second
>
> If it worked like that then the user who sets merge.ff=false in his
> config and issues a "git pull" after making a commit on his local master
> would create a merge commit.
>
> This old E-Mail of Junio's discusses that edge case & others in detail:
> https://public-inbox.org/git/7vty1zfwmd.fsf@alter.siamese.dyndns.org/
Thanks I skimmed, but it is long so I will review later.
I see the point about the config option for no-ff.

But what about an option like --reverse? Assuming we are on a local branch master then

  git merge --no-ff --reverse origin/master

would treat origin/master as the "current" branch, and "master" as the merged in branch, and create the appropriate merge commit. Which as far as I can tell is tree-wise identical to creating a topic branch instead of hacking on the local master.

Show 27 quoted lines
>> Anyway, even if the above makes no sense, would it be hard to make the
>> message provided by git merge in the first recipe a bit more
>> suggestive of what is going on? For instance if it had said "Cannot
>> --no-ff merge, origin/master is behind master" it would have been much
>> more clear what was going on.
>
> I can't spot any reason for why we couldn't have something like this POC
> (would be properly done through advice.c):
>
>     diff --git a/builtin/merge.c b/builtin/merge.c
>     index 9db5a2cf16..920f67d9f8 100644
>     --- a/builtin/merge.c
>     +++ b/builtin/merge.c
>     @@ -1407,6 +1407,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>                      * but first the most common case of merging one remote.
>                      */
>                     finish_up_to_date(_("Already up to date."));
>     +               if (fast_forward == FF_NO)
>     +                       fprintf(stderr, "did you mean this the other way around?\n");
>                     goto done;
>             } else if (fast_forward != FF_NO && !remoteheads->next &&
>                             !common->next &&
>
> But that should probably be reworked to be smart about whether --no-ff
> or merge.ff=false was specified, i.e. do we want to yell this at the
> user who's just set that at his config default, or the user who's
> specified --no-ff explicitly, or both? I don't know.
Yes, all those points make sense.
Yves
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

← back to recent threads