[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Wcxf7p1DyJdVEqODbc6TdTtbPiLszWCAS1xC6=4kkLbw@mail.gmail.com>
Date: Wed, 7 Nov 2018 13:18:19 -0800
From: Doug Anderson <dianders@...omium.org>
To: sky@...ki.is
Cc: Guenter Roeck <linux@...ck-us.net>,
Brian Norris <briannorris@...omium.org>, lists@...dbynature.de,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check
more robust"
Hi,
On Wed, Nov 7, 2018 at 1:07 PM Genki Sky <sky@...ki.is> wrote:
>
> On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck <linux@...ck-us.net> wrote:
> > I do not think it is a good idea to create a random file in the .git directory
> > under any circumstance, and much less so if an output directory was specified,
> > no matter if the path is read-only or not. I also still think that it is a
> > bad idea to touch the source tree if an output directory was specified.
> > It defeats the purpose of specifying an output directory.
>
> I was thinking of touching a pre-existing file like .git/config or
> .git/description, which I was hoping would be harmless. But sounds
> like that's still not desired?
>
> Okay, I guess one approach is to only refresh the index if $objtree ==
> $srctree, by passing some flag to scripts/setlocalversion from
> scripts/package/Makefile. Is that what you're thinking? Feels a little
> strange, but it seems it'd satisfy everyone.
>From reading the thread it sounds like Guenter was not even super
happy with that based on the principal that you wouldn't expect a
kernel build to be doing write operations in your .git directory even
if $objtree == $srctree
> > Ubuntu 16.04 ships with git version 2.7.4.
>
> Okay. I guess --no-optional-locks is a no-go then.
In theory you could wrap it. If passing git with
"--no-optional-locks" doesn't work you could fall back to the old
code? That would mean only people with newer git would get your new
feature and everyone else would stick with the pre-existing behavior.
It does seem like any things like this should be done atop Guenter's
revert. AKA: revert first to get things working the way that they
were and then start talking about how to make it better.
-Doug
Powered by blists - more mailing lists