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

From: Andy Parkins <andyparkins@gmail.com>
Date: Jan 19, 2007, 09:04 UTC
Message-ID: <200701190904.58515.andyparkins@gmail.com>
In-Reply-To: <7vfya7ju1l.fsf@assigned-by-dhcp.cox.net>

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.

Show 6 quoted lines

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