Hi Junio, On Wed, 2009-07-22 at 11:14 -0700, Junio C Hamano wrote: > Catalin Marinas <catalin.marinas@xxxxxxx> writes: > > Every time an option is set, the config file protection mode is changed > > to 0666 & ~umask even if it was different before. This patch is useful > > if people store passwords (SMTP server in the StGit case) and do not > > want others to read the .gitconfig file. [...] > Your log message talks about .git/config and nothing else, but I think > this codepath affects everything that is created under the lock, such as > the index and refs. I haven't checked all the places where this function is called. For my use-case, I store the SMTP password in the .git/config file (or ~/.gitconfig) and every time I update this file (with git or via stgit), the permission gets changed. > The patch description must defend itself a bit better, perhaps by saying > something like this at the end. > > This patch touches the codepath that affects not just .git/config > but other files like the index and the loose refs, so they also > inherit the original protection bits. In a private repository, > this is not an issue exactly because the repository is private, > > In a shared repository, a later call made in this function to > adjust_shared_perm() widens the permission bits as configured. > Because adjust_shared_perm() is designed to do so from any mode > limited by user's umask, even though this patch changes the > behaviour in the strict sense, it should not affect the outcome in > a negative way and what is explicitly marked as allowed in the > configuration will still be allowed. Thanks for the explanation. Would you like me to repost with your description? Thanks. -- Catalin -- 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