From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Sunday, September 08, 2013 7:10 PM
Richard Hansen <rhansen@xxxxxxx> writes:
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano <gitster@xxxxxxxxx>
wrote:
Which can be solved by adding the above "fail" option, and then
renaming them to "pull.integrate" and "branch.<name>.integrate" to
clarify what these variables are about (it is no longer "do you
rebase or not---if you choose not to rebase, by definition you are
going to merge", as there is a third choice to "fail"), while
retaining "pull.rebase" and "branch.<name>.rebase" as a deprecated
synonym.
All these names are completely unintuitive. First of all, why
"integrate"? Integrate what to what? And then, why "fail"? Fail on
what circumstances? Always?
My proposal that does:
pull.mode = merge/rebase/merge-ff-only
Is way more intuitive.
+1
What about something like:
pull.mergeoptions (defaults to --ff-only)
pull.rebaseoptions (defaults to empty? --preserve-merges?)
branch.<name>.pull.mergeoptions (defaults to pull.mergeoptions)
branch.<name>.pull.rebaseoptions (defaults to pull.rebaseoptions)
As "pull" has two distinct phases "fetch" and "merge/rebase", your
mergeoptions/rebaseoptions is much better than "mode", which does
not tell which phase of "pull" the mode refers to. It is clear that
they apply to the process to integrate the history obtained from
the other side and your own history into one history.
But it does not help Philip's case, if I understand correctly, where
running "git pull" on some branches is always a mistake
Not quite always, it's when it won't fast forward
and the user
wants it to stop at "fetch the history and objects needed to
complete the history from the other side" phase without proceeding
to the "then integrate the history from the other side and the
history of your branch into one" step,
Yes, it/Git should stop and wait for instructions...
which may be done with either
merge or rebase.
Here I would typically rebase onto an adjusted destination, e.g. onto
pu, or maybe next, rather than master (or vice versa depending on
expectations). That is its a feature branch that needs to decide what
it's on top of (well, I need to decide ;-)
Even if we ignore that "always fail, do not do
anything" use case, your two seemingly independent "mergeoptions"
and "rebaseoptions" do not tell us which one is preferred between
merge and rebase. A single
pull.<someoption> = rebase | merge [| always-fail]
makes that choice in a clear way, I think.
or 'fail on non-ff' (which may or may not be the users, or Git's
default, as per the series title ;-)
Regarding the verb "integrate".
We used to explain "pull" is a "fetch" followed by a "merge". With
more people using "git pull --rebase", the word "merge" used in that
explanation of "pull" stopped being generic enough. Simplarily the
"upstream branch" of local branch X is "what you fetch and merge to
update the branch X" but that 'merge' can be 'rebase'. We needed a
verb to call the process of integrate the two histories into one.
"git pull --help" since 153d7265 (pull: change the description to
"integrate" changes, 2013-07-07) uses that verb [*1*].
And that is where the name of the single configuration to pick how
to integrate the history obtained by the first phase of "pull" came
from.
[Footnote]
*1* I suspect that there may still be places in the documentation
that have not been updated since the days back when the only valid
way to integrate two lines of histories was to merge, and updating
them may be a low-hanging fruit. Hint, hint.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html