[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181107205514.GB12273@roeck-us.net>
Date: Wed, 7 Nov 2018 12:55:14 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Genki Sky <sky@...ki.is>
Cc: Brian Norris <briannorris@...omium.org>, lists@...dbynature.de,
yamada.masahiro@...ionext.com,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check
more robust"
On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris <briannorris@...omium.org> wrote:
> > On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > > On a different tangent: how about the --no-optional-locks (see
> > > git(1))? Will this get you your "up-to-date" result without writing to
> > > the .git directory? I've only read the documentation, but not tested
> > > it.
>
> This option definitely seems to be what we want, good find.
>
> > Unfortunately, --no-optional-locks is new as of git 2.14. Dunno how new
> > of a git we expect people to use.
>
> Hmm, I'm not sure who can speak to this.
>
> Though if it's too recent, then based on earlier discussion, it sounds
> like something like this (hack) might work best:
>
> [ -w .git ] &&
> touch .git/some-file-here 2>/dev/null &&
> git update-index --refresh --unmerged >/dev/null
> if git diff-index --name-only HEAD | ...
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.
Ubuntu 16.04 ships with git version 2.7.4.
Guenter
Powered by blists - more mailing lists