Re: When are you going to stop ignoring pull.mode?
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Jul 19, 2021, 17:15 UTC
- Message-ID
- <60f5b3143fd26_13f2e220892@natae.notmuch>
- In-Reply-To
- <948ef19f-5588-62e9-6fc7-aa6d82f21a1b@aixigo.com>
Matthias Baumgarten wrote:
> On 7/17/21 11:22 PM, Junio C Hamano wrote:
Show 16 quoted lines
> > 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].
It's not a bug. It could be made a bug if the semantics of --ff-only were changed to something that overrides pull.rebase, but that something doesn't exist yet:
pull.mode=fast-forward
Right now it can't be done.
-- Felipe Contreras