On 11/16/2014 09:06 AM, Johannes Sixt wrote:
> Am 16.11.2014 um 08:21 schrieb Michael Haggerty:
>> @@ -559,9 +562,21 @@ int cmd_config(int argc, const char **argv, const char 
>> *prefix)
>>              if (given_config_source.blob)
>>                      die("editing blobs is not supported");
>>              git_config(git_default_config, NULL);
>> -            launch_editor(given_config_source.file ?
>> -                          given_config_source.file : git_path("config"),
>> -                          NULL, NULL);
>> +            config_file = xstrdup(given_config_source.file ?
>> +                                  given_config_source.file : 
>> git_path("config"));
>> +            launch_editor(config_file, NULL, NULL);
>> +
>> +            /*
>> +             * In git 2.1, there was a bug in "git init" that left
>> +             * the u+x bit set on the config file. To clean up any
>> +             * repositories affected by that bug, and just because
>> +             * it doesn't make sense for a config file to be
>> +             * executable anyway, clear any executable bits from
>> +             * the file (on a "best effort" basis):
>> +             */
>> +            if (!lstat(config_file, &st) && (st.st_mode & 0111))
> 
> At this point we cannot be sure that config_file is a regular file, can
> we? It could also be a symbolic link. Wouldn't plain stat() be more
> correct then?

You make a good point. But I'm a little nervous about following symlinks
and changing permissions on some distant file. Also, the bug that we are
trying clean up after would not have created a symlink in this place, so
I think the cleanup is not so important if "config" is a symlink.

So I suggest that we stick with lstat(), but add S_ISREG(st.st_mode) to
the && chain above. Does that sound reasonable?

>> +                    chmod(config_file, st.st_mode & 07666);
>> +            free(config_file);
>>      }
>>      else if (actions == ACTION_SET) {
>>              int ret;

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu

--
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

Reply via email to