On 7/17/21 11:22 PM, Junio C Hamano wrote:
Matthias Baumgarten <matthias.baumgarten@xxxxxxxxxx> writes:
pull.ff pull.rebase commandline action
...
* * --ff-only fast-forward only[1]
...
What about
* !false --ff-only ???
This is covered by an earlier entry ("*" stands for "any value"), I
think; it should fast-forward or fail. The reasoning goes like
this:
Ah, I just misunderstood *, nevermind!
The user configures pull.rebase to some kind of rebase; it could be
just true (the traditional flattening rebase), or the one that
preserves the shape of the history, or even the interactive one.
With the configuration, what the user declares is:
I may have my own development on top of the result of my last
integration with the upstream I did when I ran "git pull" the
last time, and when the upstream has more commits, the way I
want my local work to integrate with their work is to replay my
work on top of theirs (as opposed to "merging their work into my
history").
But by passing "--ff-only" from the command line, the user tells us
this:
This time only, I want fast-forward update and nothing else. I
do not remember doing any of my own development on top of their
history, and I expect that this update from the upstream would
fast-forward. If that is not the case, please error out, as I
need to inspect the situation further and I do not want to see
conflicts in unexpected commits I thought I did not have.
So the "action" would be
- If their history is a descendant of ours, that means that on top
of their history previously observed by us, we haven't added any
development of our own. We just move to the tip of their history
and we are done.
This is not so surprising anyway. If we are doing any kind of
rebasing, what happens is to start from the tip of their history
and then commits from our own development are replayed on top of
that. When their history is a descendant of ours, we end up
doing just fast-forward, as there is nothing to replay on top.
- Otherwise, because the user expects the command to fail if their
history is not a descendant of ours, we fail.
And "fast-forward only" in Elijah's table is a concise way to say
that.
Agree.
I concentrated on "if the configuration is set to do some kind of
rebase" case, as that was your question, but the above reasoning
applies equally to the case where pull.rebase is not specified or
set to false, i.e. the user tells us to merge.
Perfectly valid reasoning.
Initially I came from the situation where I (as maintainer of a
repository) proposed to do a `git pull --ff-only <remote-git-url>
<branch-name>` for the others to integrate the newest changes safely
(i.e. failing if they had errouneously worked on that branch, which it
is not intended for). I thought I could reach that safety with the
`--ff-only` part, but it seems one of the devs had pull.rebase set for
him locally and thus managed to bypass my "safety". Mr. Elijah Newren
called this a bug, see [1].
Another way for the others to integrate my changes would be to propose a
`git reset --hard ...` but that seems very... hard. It would overwrite
all local changes (only recoverable by the reflog then, and you would
even need to know that you had local changes in the first place).
[1]
https://lore.kernel.org/git/CABPp-BEHZcfZNL+PG1vmqXGf4Qs3eoULb4NDDgbmOB30HzJu_Q@xxxxxxxxxxxxxx/
--
aixigo AG
Karl-Friedrich-Str. 68, 52072 Aachen, Germany
phone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99
email: matthias.baumgarten@xxxxxxxxxx
web: https://www.aixigo.com
District Court Aachen – HRB 8057
Board: Christian Friedrich, Tobias Haustein
Chairman of the Supervisory Board: Dr. Roland Schlager
