On Dec 3, 2018, at 8:50 PM, Jeff King wrote:
>
> I don't suppose this is leaving those incoming-* directories sitting
> around so we can inspect their permissions (it's suppose to clean them
> up, so I doubt it). If you're up for it, it might be interesting to
> patch Git to inspect the umask and
On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote:
> On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
> >
> > but it works fine. Might there be some effective-uid trickiness with the
> > way the server side of git is invoked? Or is this a network mount where
> > the filesystem uid might
On Dec 3, 2018, at 8:19 PM, Jamie Zawinski wrote:
>
> (Oh, I didn't check what umask was, but it should have been 022...)
Typo, I mean to say 002.
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
>
> but it works fine. Might there be some effective-uid trickiness with the
> way the server side of git is invoked? Or is this a network mount where
> the filesystem uid might not match the process uid?
Huh. They're on the same ext4 fs (it's an AWS
On Mon, Dec 03, 2018 at 07:27:13PM -0800, Jamie Zawinski wrote:
> I think sharedrepository=group stopped working some time between
> 2.10.5 (works) and 2.12.4 (does not). 2.19.2 also does not.
Hmm. Given the time-frame and the fact that your strace shows problems
writing into the objects/incoming
I think sharedrepository=group stopped working some time between 2.10.5 (works)
and 2.12.4 (does not). 2.19.2 also does not.
I have a user trying to push to a shared repo; the user is not the owner of the
files but it is in the same group. All the repo files are g+rw and all the repo
directorie
6 matches
Mail list logo
