Re: git ls-files -o under .git/ prints all repository files

[Andy Parkins <andyparkins@gmail.com>]

On Friday 2007, January 19 08:32, Junio C Hamano wrote:

> Have you actually read the code to see what 'share' variable
> means there?  It is only false when creating the toplevel .git

Nope.  I'm an idiot :-) I assumed it was from the --shared command line 
argument.  What they say about assumptions is true isn't it?

> Nothing unusual.  The code explicitly asks for .git/config by
> name, so that does not involve readdir(".git"), which is what
> the 0333 change prevents from running.

In this case I was talking more about the user editing those files than the 
code looking for them.  I suppose if you know its there then a 
vim .git/config will be fine.

> > On ocassion I've found myself doing
> >   mv .git/refs/remotes/origin .git/refs/remotes/up
> >
> > Which this patch would break.
>
> Does it?

You're right it doesn't.  As long as you know the refs directory is there it 
doesn't stop you changing into it, and messing about in any way you want.  I 
was looking at it from the point of view of how I originally found out about 
these git inner workings - I did it by poking around in the .git directory.

> You all should not take "amusing" too seriously.  That was a
> tongue-in-cheek patch.

Fair enough.  I took it more as meaning,  "this would fix this problem /and/ 
it's funny too".  Apologies.

> In other words, I am not sure if there is anything worth fixing.

After a bit of thought; I think I agree.


Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com