[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxkYTeY9h=VHFXi=gbXsnsHCRMAVZ9=1_EsFGSqr0sj9g@mail.gmail.com>
Date: Tue, 13 Feb 2018 09:33:02 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Junio C Hamano <gitster@...ox.com>
Cc: Mauro Carvalho Chehab <mchehab@....samsung.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Git Mailing List <git@...r.kernel.org>
Subject: Re: linux-next: unnecessary merge in the v4l-dvb tree
On Tue, Feb 13, 2018 at 9:18 AM, Junio C Hamano <gitster@...ox.com> wrote:
>
> That makes me wonder if another heuristic I floated earlier is more
> appropriate. When merging a tag object T, if refs/tags/T exists and
> it is that tag object, then an updated "merge" would default to "--ff";
> otherwise, it would keep the current default of creating a merge even
> when we could fast-forward, in order to record that tag T in the
> resulting history.
Oooh. Yes, that sounds like the right thing to do.
So the "no fast-forward" logic would trigger only if the name we used
for merging is one of the temporary ones (ie .git/{FETCH,MERGE}_HEAD),
not if the mentioned tag is already a normal tag reference.
Then it's very explicitly about "don't lose the signing information".
I'd still have to teach people to use "--only-ff" if they don't do the
"fetch and merge" model but literally just do "git pull upstream
vX.Y", but at least the case Mauro describes would automatically just
DTRT.
Me likey.
Linus
Powered by blists - more mailing lists