On Wed, Nov 7, 2018 at 3:39 AM Guenter Roeck wrote:
>
> This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
>
> The reverted patch results in attempted write access to the source
> repository, even if that repository is mounted read-only.
>
> Output from "strace git status -uno
On Wed, Nov 7, 2018 at 3:39 AM Guenter Roeck wrote:
>
> This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
>
> The reverted patch results in attempted write access to the source
> repository, even if that repository is mounted read-only.
>
> Output from "strace git status -uno
On Wed, Nov 7, 2018 at 12:05 PM Christian Kujau wrote:
>
> On Tue, 6 Nov 2018, Brian Norris wrote:
> > > Perhaps both scenarios could be satisfied by having
> > > scripts/setlocalversion first check if .git has write permissions, and
> > > acting accordingly. Looking into history, this actually
On Wed, Nov 7, 2018 at 12:05 PM Christian Kujau wrote:
>
> On Tue, 6 Nov 2018, Brian Norris wrote:
> > > Perhaps both scenarios could be satisfied by having
> > > scripts/setlocalversion first check if .git has write permissions, and
> > > acting accordingly. Looking into history, this actually
On Thu, Nov 8, 2018 at 12:20 PM Brian Norris wrote:
>
> On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson wrote:
> > On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
> > > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck
> > > wrote:
> > > > Ubuntu 16.04 ships with git version 2.7.4.
> > >
> > >
On Thu, Nov 8, 2018 at 12:20 PM Brian Norris wrote:
>
> On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson wrote:
> > On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
> > > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck
> > > wrote:
> > > > Ubuntu 16.04 ships with git version 2.7.4.
> > >
> > >
On Thu, Nov 8, 2018 at 5:58 AM Guenter Roeck wrote:
>
> On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> > On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
> > wrote:
> > > On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > > > On a different tangent: how about the
On Thu, Nov 8, 2018 at 5:58 AM Guenter Roeck wrote:
>
> On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> > On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
> > wrote:
> > > On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > > > On a different tangent: how about the
On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson wrote:
> On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
> > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> > > 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
On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson wrote:
> On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
> > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> > > 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
On Wed, 7 Nov 2018 13:18:19 -0800, Doug Anderson wrote:
> 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
I see,
On Wed, 7 Nov 2018 13:18:19 -0800, Doug Anderson wrote:
> 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
I see,
Hi,
On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
>
> On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck 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
Hi,
On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
>
> On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck 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
On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck 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
>
On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck 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
>
On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
> 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
On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
> 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
On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
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
On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
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
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.
I think I can add a
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.
I think I can add a
On Tue, Nov 6, 2018 at 6:58 PM Christian Kujau wrote:
> FWIW, the issue I reported back in 2013[0] was not an ill-configured NFS
> export, but a read-only NFS export (and then a read-write exported NFS
> export, but the user compiling the kernel did not have write permission)
> and so "test -w
On Tue, Nov 6, 2018 at 6:58 PM Christian Kujau wrote:
> FWIW, the issue I reported back in 2013[0] was not an ill-configured NFS
> export, but a read-only NFS export (and then a read-write exported NFS
> export, but the user compiling the kernel did not have write permission)
> and so "test -w
On 11/6/18 6:58 PM, Christian Kujau wrote:
On Tue, 6 Nov 2018, Brian Norris wrote:
Perhaps both scenarios could be satisfied by having
scripts/setlocalversion first check if .git has write permissions, and
acting accordingly. Looking into history, this actually used to be
done, but cdf2bc632ebc
On 11/6/18 6:58 PM, Christian Kujau wrote:
On Tue, 6 Nov 2018, Brian Norris wrote:
Perhaps both scenarios could be satisfied by having
scripts/setlocalversion first check if .git has write permissions, and
acting accordingly. Looking into history, this actually used to be
done, but cdf2bc632ebc
On Tue, 6 Nov 2018, Brian Norris wrote:
> > Perhaps both scenarios could be satisfied by having
> > scripts/setlocalversion first check if .git has write permissions, and
> > acting accordingly. Looking into history, this actually used to be
> > done, but cdf2bc632ebc ("scripts/setlocalversion on
On Tue, 6 Nov 2018, Brian Norris wrote:
> > Perhaps both scenarios could be satisfied by having
> > scripts/setlocalversion first check if .git has write permissions, and
> > acting accordingly. Looking into history, this actually used to be
> > done, but cdf2bc632ebc ("scripts/setlocalversion on
Hi Genki,
On Tue, Nov 06, 2018 at 11:23:05AM -0800, Genki Sky wrote:
> On Tue, 6 Nov 2018 10:10:38 -0800, Guenter Roeck wrote:
> > This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
> >
> > The reverted patch results in attempted write access to the source
> > repository, even if
Hi Genki,
On Tue, Nov 06, 2018 at 11:23:05AM -0800, Genki Sky wrote:
> On Tue, 6 Nov 2018 10:10:38 -0800, Guenter Roeck wrote:
> > This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
> >
> > The reverted patch results in attempted write access to the source
> > repository, even if
Hi Guenter,
On Tue, 6 Nov 2018 10:10:38 -0800, Guenter Roeck wrote:
> This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
>
> The reverted patch results in attempted write access to the source
> repository, even if that repository is mounted read-only.
>
> Output from "strace git
Hi Guenter,
On Tue, 6 Nov 2018 10:10:38 -0800, Guenter Roeck wrote:
> This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
>
> The reverted patch results in attempted write access to the source
> repository, even if that repository is mounted read-only.
>
> Output from "strace git
This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
The reverted patch results in attempted write access to the source
repository, even if that repository is mounted read-only.
Output from "strace git status -uno --porcelain":
getcwd("/tmp/linux-test", 129) = 16
This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349.
The reverted patch results in attempted write access to the source
repository, even if that repository is mounted read-only.
Output from "strace git status -uno --porcelain":
getcwd("/tmp/linux-test", 129) = 16
34 matches
Mail list logo
