Re: permissions
Show 17 quoted lines
> On Wed, Jun 9, 2010 at 00:27, William Pursell <bill.pursell@gmail.com> wrote:
>> Junio C Hamano wrote:
>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>
>>>> On Tue, Jun 8, 2010 at 12:25, William Pursell <bill.pursell@gmail.com> wrote:
>>>>> Here's a patch. This doesn't address the issue of a damaged
>>>>> repository, but just catches access errors and permissions.
>>>> The change looks fishy.
>>>>
>>>> The patch moves the function is_git_directory at the level of user
>>>> interface where it wasn't before: it now complains and die.
>>>> Not all callers of the function call it only to die if it fails.
>>> Thanks for shooting it down before I had to look at it ;-)
>> The point of the patch is that it now complains and dies.
>
> At wrong point. Points, actually. There are many callers of the
> function you modified. You should have looked at them all.
I did look at all 4 calls, and it seemed to me that localizing the change in one location is a better design than adding logic to 4 different locations.
>> Perhaps I'm being obtuse, but can you describe a situation
>> in which this causes git to terminate inappropriately?
>
> Maybe. BTW, can you? (if you try, I mean).
No, I can't. As far as I can tell, the patch adds exactly the functionality that I want it to add. You do make good points about its problems below, however, and you are right that I did miss the point of your criticism. Thank you for clarifying.
Show 7 quoted lines
> But your questions
> misses the point of my complaint about your patch:
>
> The patch makes the function you modified act not as one
> can guess from its other uses. Imagine someone replaced
> open(2) implementation to kill your program everytime you
> tried to open /etc/passwd. How'd you like that?
I think there is a substantial difference between changing a basic library call and changing a statically linked function called from only 4 locations, but I'll agree that you have a valid point about the function not behaving as expected. The functionality I've added disagrees with the name of the function, so on that point alone I will agree that the patch is no good.
Show 5 quoted lines
>
> That alone is reason enough to dislike the change and put
> you personally into a list of persons to be careful with (as
> you don't seem to care about what happens with the code
> after you changed it).
I do care quite a lot actually. My primary goal was to minimize the changes, and it seemed that is_git_directory() was the right place to make the change with minimal impact. Perhaps the following patch would be more to your liking:
diff --git a/setup.c b/setup.c
index 7e04602..b25da21 100644
--- a/setup.c
+++ b/setup.c
@@ -303,6 +303,9 @@ const char *read_gitfile_gently(const char *path)
buf = dir;
}
+ if (access(dir, X_OK))
+ die_errno("Unable to access %s", dir);
+
if (!is_git_directory(dir))
die("Not a git repository: %s", dir);
path = make_absolute_path(dir);
@@ -370,6 +373,9 @@ const char *setup_git_directory_gently(int *nongit_ok)
*nongit_ok = 1;
return NULL;
}
+ if (access(gitdirenv, X_OK))
+ die_errno("Unable to access %s", gitdirenv);
+
die("Not a git repository: '%s'", gitdirenv);
}
@@ -407,6 +413,11 @@ const char *setup_git_directory_gently(int *nongit_ok)
}
if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
break;
+ if (access(DEFAULT_GIT_DIR_ENVIRONMENT, X_OK)
+ && errno != ENOENT )
+ die_errno("Unable to access %s/%s",
+ cwd, DEFAULT_GIT_DIR_ENVIRONMENT);
+
if (is_git_directory(".")) {
inside_git_dir = 1;
if (!work_tree_env)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index cb14425..9f6f756 100755
--- a/t/t0002-gitfile.sh
+++ b/t/t0002-gitfile.sh
@@ -46,7 +46,7 @@ test_expect_success 'bad setup: invalid .git file path' '
echo "git rev-parse accepted an invalid .git file path"
false
fi &&
- if ! grep "Not a git repository" .err
+ if ! grep "Unable to access $REAL.not" .err
then
echo "git rev-parse returned wrong error"
false
--
William Pursell
William Pursell
