"Philip Oakley" <philipoakley@xxxxxxx> writes:
> From: "Junio C Hamano" <gitster@xxxxxxxxx>
>> John Keeping <john@xxxxxxxxxxxxx> writes:
>>
>>> I think there are two distinct uses for pull, which boil down to:
>>>
>>> (1) git pull
>> ...
>> Peff already covered (1)---it is highly doubtful that a merge is
>> "almost always wrong". In fact, if that _were_ the case, we should
>> simply be defaulting to rebase, not failing the command and asking
>> between merge and rebase like jc/pull-training-wheel topic did.
>>
>> We simply do not know what the user wants, as it heavily depends on
>> the project, so we ask the user to choose one (and stick to it).
>
> We only offer a limited list. It won't be sufficient for all use
> cases. It wasn't for me.
Very interesting. Tell us more.
When "git pull" stops because what was fetched in FETCH_HEAD does
not fast-forward, then what did _you_ do (and with the knowledge you
currently have, what would you do)? In a single project, would you
choose to sometimes rebase and sometimes merge, and if so, what is
the choice depend on? "When I am on these selected branches, I want
to merge, but on other branches I want to rebase?"
If that is the issue you are trying to raise (I cannot tell yet), a
repository-wide "pull.rebase = merge/rebase" is still too blunt an
instrument, but then "branch.<name>.rebase" can be set to
selectively override it, so that case is covered.
[pull]
rebase = merge
[branch "po/topic"]
rebase = yes
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after "git pull" fetches from the other
side? Nothing?
Side note: a knee-jerk response to a "yes" answer to the
last question from me has always been "then why are you
running 'git pull' in the first place. The next paragraph is
my attempt to extend my imagination a bit, stepping outside
that reaction.
I can imagine users might want to say "when I am on these small
number of branches, I want to merge (or rebase), but when I am on
other, majority of my branches, because they are private, unfinished
and unpublished work, please stop me from accidentally messing their
histories with changes from upstream or anywhere else for that
matter". If that is the issue you are trying to raise, because
there is no
[pull]
rebase = fail
[branch "master"]
rebase = yes
to force "git pull" to fail by default on any branch while allowing
it to rebase (or merge, for that matter) only on a few selected
branches, we fall a bit short.
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.
Am I on the right track following (eh, rather "trying to guess")
what you are trying to get at?
--
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