Re: [PATCH v2 11/14] tentative: pull: change the semantics of --ff-only
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Dec 5, 2020, 11:37 UTC
- Message-ID
- <CAMP44s3RcsFeE4qLC49GwipfxsB97c55TnxHK-dCGd3hEH5TVw@mail.gmail.com>
- In-Reply-To
- <CAMP44s1wFPQ0mEExYUQfxYx2AjMZS2=zL5ihfjp3qjp+EfNe9Q@mail.gmail.com>
On Fri, Dec 4, 2020 at 10:01 PM Felipe Contreras <felipe.contreras@gmail.com> wrote:
Show 28 quoted lines
> > On Fri, Dec 4, 2020 at 5:39 PM Elijah Newren <newren@gmail.com> wrote: > > > > On Thu, Dec 3, 2020 at 10:16 PM Felipe Contreras > > <felipe.contreras@gmail.com> wrote: > > > > > > We want --ff-only to make sense only when no --merge or --rebase option > > > is specified. > > > > A lot of git commands have opposite options, and git allows them both > > to be specified with the last one winning. Thus, much like > > git log --patch --no-patch > > mean show logs without patches and > > git log --no-patch --patch > > means show logs with patches, I would similarly expect the following > > two commands to have opposite behavior: > > git pull --merge --no-ff > > git pull --no-ff --merge > > Good point. > > Although I presume you meant --ff-only. > > Taking that into consideration it may be possible to make --ff-only > work straightforwardly. > > Further changes to the code are needed though. In the meantime I'm > sending a quick patch on top of this series.
Nevermind.
I have implemented the changes properly and v3 is ready with some interesting improvements, but it is still not straightforward.
Currently "git pull --ff-only --merge" fails with:
fatal: Not possible to fast-forward, aborting.
With the proposed change --merge would override --ff-only and make the pull essentially --no-ff.
That's still a semantic change. So there's no way around that.
Cheers.
-- Felipe Contreras