Re: [PATCH v2] pull: introduce --merge option

Linus Torvalds [off-list ref] writes:

On Wed, Jul 21, 2021 at 6:47 AM Felipe Contreras
[off-list ref] wrote:

quoted

Users need to specify if they want to either --merge or --rebase, but
unfortunately the former is missing.

Ack. I think it's just historical, because long long ago it used to be
that 'git pull' always merged unless told otherwise with --rebase.

The "--no-rebase" option, which is documented as a synonym for
"--rebase=false", has been there, but the implementation is buggy in
some corner cases, which has been worked on recently in a separate
thread.  I do not think it is too bad to add "--merge" as yet
another synonym for "--rebase=false".

On Wed, Jul 21, 2021 at 11:11 AM Junio C Hamano [off-list ref] wrote:

The "--no-rebase" option, which is documented as a synonym for
"--rebase=false", has been there, but the implementation is buggy in
some corner cases, which has been worked on recently in a separate
thread.  I do not think it is too bad to add "--merge" as yet
another synonym for "--rebase=false".

It's convenient to have the one-letter option `git pull -r` to
override the configuration and do a rebase. I'd really like to have a
similar one-letter option `git pull -m` to override the configuration
and do a merge. That would also alleviate a lot of the desire for a
separate `git update` (i.e. "fetch and rebase") command.

Junio, would you be willing to accept adding -m without adding --merge also?

-Alex

Alex Henrie wrote:

On Wed, Jul 21, 2021 at 11:11 AM Junio C Hamano [off-list ref] wrote:

quoted

The "--no-rebase" option, which is documented as a synonym for
"--rebase=false", has been there, but the implementation is buggy in
some corner cases, which has been worked on recently in a separate
thread.  I do not think it is too bad to add "--merge" as yet
another synonym for "--rebase=false".

It's convenient to have the one-letter option `git pull -r` to
override the configuration and do a rebase. I'd really like to have a
similar one-letter option `git pull -m` to override the configuration
and do a merge. That would also alleviate a lot of the desire for a
separate `git update` (i.e. "fetch and rebase") command.

My proposed `git update` is not "fetch and rebase", but fetch and
fast-forward.

Morevoer, `git pull -m` would still merge with the wrong order of the
parents. On the other hand `git update --merge` would merge them with
the correct order.

I'm not sure what -m would alleviate.

-- 
Felipe Contreras

Junio C Hamano wrote:

Linus Torvalds [off-list ref] writes:

quoted

On Wed, Jul 21, 2021 at 6:47 AM Felipe Contreras
[off-list ref] wrote:

quoted

Users need to specify if they want to either --merge or --rebase, but
unfortunately the former is missing.

Ack. I think it's just historical, because long long ago it used to be
that 'git pull' always merged unless told otherwise with --rebase.

The "--no-rebase" option, which is documented as a synonym for
"--rebase=false", has been there, but the implementation is buggy in
some corner cases, which has been worked on recently in a separate
thread.  I do not think it is too bad to add "--merge" as yet
another synonym for "--rebase=false".

Any particular reason why this is not a topic? [1]

[1] https://lore.kernel.org/git/xmqq35s0fj9o.fsf@gitster.g/

-- 
Felipe Contreras

Alex Henrie [off-list ref] writes:

Junio, would you be willing to accept adding -m without adding --merge also?

My gut feeling is that "-m" without "--merge" in the context of
"pull" is extremely unlikely to fly well.

As "git pull" is a "git fetch" followed by a "git merge" (or "git
rebase"), it takes the union of common command line options from
both phases, and "git merge" takes "-m 'message'" which is an option
fairly familiar to users (since it comes from "git commit").  Even
if we are never going to pass "-m message" from "git pull" down to
underlying "git merge", squatting on short and common "-m" would be
a bad idea.

On Tue, Jul 27, 2021 at 2:45 AM Junio C Hamano [off-list ref] wrote:

Alex Henrie [off-list ref] writes:

quoted

Junio, would you be willing to accept adding -m without adding --merge also?

My gut feeling is that "-m" without "--merge" in the context of
"pull" is extremely unlikely to fly well.

As "git pull" is a "git fetch" followed by a "git merge" (or "git
rebase"), it takes the union of common command line options from
both phases, and "git merge" takes "-m 'message'" which is an option
fairly familiar to users (since it comes from "git commit").  Even
if we are never going to pass "-m message" from "git pull" down to
underlying "git merge", squatting on short and common "-m" would be
a bad idea.

Thanks for the explanation. I forgot that "-m" usually means
"message". That does seem like a good reason to not use "-m" for
"merge".

-Alex

Alex Henrie wrote:

On Tue, Jul 27, 2021 at 2:45 AM Junio C Hamano [off-list ref] wrote:

quoted

Alex Henrie [off-list ref] writes:

quoted

Junio, would you be willing to accept adding -m without adding --merge also?

My gut feeling is that "-m" without "--merge" in the context of
"pull" is extremely unlikely to fly well.

As "git pull" is a "git fetch" followed by a "git merge" (or "git
rebase"), it takes the union of common command line options from
both phases, and "git merge" takes "-m 'message'" which is an option
fairly familiar to users (since it comes from "git commit").  Even
if we are never going to pass "-m message" from "git pull" down to
underlying "git merge", squatting on short and common "-m" would be
a bad idea.

Thanks for the explanation. I forgot that "-m" usually means
"message". That does seem like a good reason to not use "-m" for
"merge".

It means --merge plenty of times:

 * git restore -m
 * git checkout -m
 * git rebase -m
 * git diff -m
 * git read-tree -m
 * git diff-tree -m

-- 
Felipe Contreras

On 7/27/21 6:48 PM, Felipe Contreras wrote:

Alex Henrie wrote:

quoted

On Tue, Jul 27, 2021 at 2:45 AM Junio C Hamano [off-list ref] wrote:

quoted

Alex Henrie [off-list ref] writes:

quoted

Junio, would you be willing to accept adding -m without adding --merge also?

My gut feeling is that "-m" without "--merge" in the context of
"pull" is extremely unlikely to fly well.

As "git pull" is a "git fetch" followed by a "git merge" (or "git
rebase"), it takes the union of common command line options from
both phases, and "git merge" takes "-m 'message'" which is an option
fairly familiar to users (since it comes from "git commit").  Even
if we are never going to pass "-m message" from "git pull" down to
underlying "git merge", squatting on short and common "-m" would be
a bad idea.

Thanks for the explanation. I forgot that "-m" usually means
"message". That does seem like a good reason to not use "-m" for
"merge".

It means --merge plenty of times:

  * git restore -m
  * git checkout -m
  * git rebase -m
  * git diff -m
  * git read-tree -m
  * git diff-tree -m

Add to Felipes list:

  * git switch -m

and maybe git cherry-pick -m where -m does not mean "merge" itself but 
is used to determine the parent of the merge (when picking merge 
commits) to base on.

Other examples of where -m has different meaning than merge:

  * git am -m (message-id)
  * git branch -m (move branch)

I would rephrase the question as to what would I expect `git pull -m` to 
do, if I had never heard of it before. In the case of fast-forwarding 
and rebasing trying to add a merge commit message with -m would not even 
make sense. Only in the case of trying to create a merge commit by 
issuing git pull this would make sense. So if we could agree on that 
being not the most used scenario, I think -m would be a great short 
option for --merge.

-- 
aixigo AG
Karl-Friedrich-Str. 68, 52072 Aachen, Germany
phone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99
email: matthias.baumgarten@aixigo.com
web: https://www.aixigo.com
District Court Aachen – HRB 8057
Board: Christian Friedrich, Tobias Haustein
Chairman of the Supervisory Board: Dr. Roland Schlager