Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> Yeah, I didn't consider the mode impact of using mkstemp. That is >> definitely a regression that should be fixed. Though of course if you >> really do want 0644, you should set your umask to 0022. :) >> ... >> If you haven't set core.sharedrepository, then adjust_shared_perm is a >> noop. But you shouldn't have to do that. Git should just respect your >> umask in this case. > > Thanks for a nicely done patch series, but I am not sure if I agree > with the analysis and its conclusion. > > If adjust_shared_perm is a no-op, how do we ensure that other files > that need to be served by a dumb HTTP server are readable by it? Is > it because we just happen not to use mkstemp() to create them (and > also is it because the pushers do not have umask 007 or stronger to > prevent files from being read by the HTTP server user)? > > Is our goal here to give the users this statement? > > For shared repository served by dumb HTTP and written by users > who are different from the user that runs the HTTP server, you > need to do nothing special. > > If that is the case, shouldn't the rule be something a lot looser > than "we should just respect your umask"? To satisify the above > goal, shouldn't we somehow make it readable by the HTTP user even > when some pusher has a draconian 0077 umask? But that, while still > complying to the promise of "nothing special", would imply we would > have to make everything readable everywhere, whish is an unachievable > goal. We need to somehow be able to say "this repository should be > readable by these people" per-repository basis. > > And we have a mechanism exactly designed to do so to defeat > draconian umask individual users have. > > It feels to me that the old set-up were "working" by accident, not > by design (I may be mistaken--so correct me if that were the case). > And if that is the case, I do not think it is a good idea to try to > hide the broken configuration under the rug longer. "As long as > everybody writes world-readable files, you do not have to do > anything" will break when the next person with 0xx7 umask setting > pushes, no? Having said all that, I agree that the patch series does the right thing in that it stops us from tightening without being told. It's just that the change is not a general solution for "you shouldn't have to set core.sharedrepository even when people with different umask settings push into the same repo". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html