Linus Torvalds wrote:
quoted text
> 
> However, there's one fundamental reason:
> 
>  - if you have a file in ".git", that implies that even a "raw git repo" 
>    would have versions matter, since technically such a file would be 
>    inside the "raw" part. And that I find to be confusing. One of the 
>    whole points of a raw git repo is that because it doesn't have anything 
>    that is version-controlled and checked out, none of the branches or 
>    tags are special, and nothing needs to be updated when you push to such 
>    a repo.
> 
>    Now, if you have files in .git, suddenly that fundamental nature of a 
>    raw repository is no longer clear.
> 

Note that I didn't actually mean that they should necessarily represent 
files in .git/.  The point was more that if we wanted to have 
version-controlled metadata, using .git/ as a namespace would be suitable.

In particular, I believe that if we ever do that, git should obtain this 
metadata from the repository/object database.

quoted text
> In general, making any internal git data versionable is very confusing. So 
> you make the grafts file versionable - that suddenly means that different 
> branches may have different parents for the same commit. And that 
> depending on which branch you have checked out, git-fsck-cache may result 
> in an error, or it may not. That's _nasty_, in my opinion.
> 
> So I much prefer to say: everything under ".git" is not versionable, for 
> the fundamental reason that the files under .git are "global" to that git 
> repository. 
> 
> And I think .git/grafts in particular makes no sense to version.
> 
> If you want to track a git "grafts" file, you can do it as another git 
> repository and a symlink.

I fully concur with this (as I pointed out in my post, although perhaps 
fuzzily.)

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html