Matthias Baumgarten [off-list ref] writes:
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.
I am afraid that you are misinterpreting what I said, comparing
apples and oranges, and drawing a wrong conclusion.
When I said "-m" would not fly well as a short-hand for "--merge" in
the context of "pull", I didn't mean "nobody would think 'm' stands
for 'merge'", and I didn't mean "more people would think 'm' stands
for 'message' more than 'merge'". The reason why I find it
problematic is because it can be ambiguous.
When we step back and think about your "switch -m" and its synonym
"checkout -m", we realize that these commands fundamentally never
take "--message", as there is no place to record such a message
(they do not create a commit after all), after they switch to a
different branch while carrying the local modification forward by
performing a (possibly conflicting) content-level merge. That is
why we can give their "merge" operation a short-and-sweet "m"
without confusing our users. So contrasting "switch" having "-m"
that means "merge" with "pull" that can conceivably take both
"merge" and "message" is not a comparison you can draw useful
conclusion from.
On 7/28/21 7:18 PM, Junio C Hamano wrote:
I am afraid that you are misinterpreting what I said, comparing
apples and oranges, and drawing a wrong conclusion >
When I said "-m" would not fly well as a short-hand for "--merge" in
the context of "pull", I didn't mean "nobody would think 'm' stands
for 'merge'", and I didn't mean "more people would think 'm' stands
for 'message' more than 'merge'". The reason why I find it
problematic is because it can be ambiguous >
When we step back and think about your "switch -m" and its synonym
"checkout -m", we realize that these commands fundamentally never
take "--message", as there is no place to record such a message
(they do not create a commit after all), after they switch to a
different branch while carrying the local modification forward by
performing a (possibly conflicting) content-level merge. That is
why we can give their "merge" operation a short-and-sweet "m"
without confusing our users. So contrasting "switch" having "-m"
that means "merge" with "pull" that can conceivably take both
"merge" and "message" is not a comparison you can draw useful
conclusion from.
I must confess that this comparison is indeed not a valid one. Maybe -m
isn't as great as I thought it was.
--
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
Junio C Hamano wrote:
Matthias Baumgarten [off-list ref] writes:
quoted
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.
I am afraid that you are misinterpreting what I said, comparing
apples and oranges, and drawing a wrong conclusion.
When I said "-m" would not fly well as a short-hand for "--merge" in
the context of "pull", I didn't mean "nobody would think 'm' stands
for 'merge'", and I didn't mean "more people would think 'm' stands
for 'message' more than 'merge'". The reason why I find it
problematic is because it can be ambiguous.
The question shouldn't be "can it be ambiguous?", the question should be
"is it ambiguous?".
The *main* purpose of `git pull` is to integrate remote changes, and the
first question asked is "how?".
git pull --merge|-m
git pull --rebase|-r
So I don't see why it is ambiguous.
The fact that a tiny minority of users might find a command (any command)
ambiguous is not valid reason for its inexistence. By that rationale
`git pull` shouldn't exist at all, because many find it ambiguous that
it's not the symmetric command opposed to `git push`.
The vast majority of users shouldn't suffer because of the confusion of
a tiny few. The tiny few can simply look at the documentation.
--
Felipe Contreras