The original (shell coded) version of the git-clone just used mkdir(1)
to create the working directories. The builtin changed the mode argument
to mkdir(2) to 0755, which was a bit unfortunate, as there are use
cases where umask-controlled creation is preferred and in any case
it is a well-known behaviour for new directory/file creation.
---
On Fri, 6 Jul 2012, Daniel Barkalow wrote:
> On Fri, 6 Jul 2012, Alex Riesen wrote:
>> when git-clone was built in, its treatment of umask has changed: the shell
>> version respected umask for newly created directories by using plain
>> mkdir(1),
>> and the builtin version just uses mkdir(work_tree, 0755).
>>
>> Is it intentional?
>
> I have the vague feeling that it was intentional, but it's entirely
> plausible that I just overlooked that mkdir(2) applies umask and went for
> the mode that you normally want. I don't think there's any particular need
> for this operation to be more restrictive than umask.
I didn't look hard enough, but still, I found not much of complaining either
way (frankly - none, but as I said, I didn'l look hard): none before - for
being too permissive, the only one in original post after building the thing
in - for being too restrictive.
Maybe we should reconsider and go back to the old permission handling?
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index d3b7fdc..e314b0b 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -708,7 +708,7 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
if (safe_create_leading_directories_const(work_tree) < 0)
die_errno(_("could not create leading directories of
'%s'"),
work_tree);
- if (!dest_exists && mkdir(work_tree, 0755))
+ if (!dest_exists && mkdir(work_tree, 0777))
die_errno(_("could not create work tree dir '%s'."),
work_tree);
set_git_work_tree(work_tree);
--
1.7.11.1.185.g5abe2c9
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
