Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.

Dmitry Kakurin [off-list ref] writes:

I thought I did: I've observed that these problem are caused by
storing metadata in regular files (that exist both in repo/index and
in workplace).

And that observation solves the initial checkout issue how?

My knowledge of Git internals is quite limited, but if *I* were to do
it right now, I'd introduce a META entry in every TREE object that
would point to a BLOB that contains combined content of
.gitattributes, .gitignore etc.

A tree that has .gitattributes (and I am assuming in the longer
term you can use "ignore" and "precious" in .gitattributes
instead of using .gitignore) POINTS TO A BLOB already, so what
you are saying does not add anything to what we already have,
other than that you are renaming .gitattributes to "META ENTRY".

When you do "git checkout -- this-path", you are checking things
out from the index and at that point you may not have _any_ tree
yet (think "before initial commit").  A "META ENTRY" that exists
only in a tree does not work -- it has to come to index somehow
for it to work with how git works.

----- Original Message ----- 
From: "Junio C Hamano" <redacted>

Dmitry Kakurin [off-list ref] writes:

quoted

I thought I did: I've observed that these problem are caused by
storing metadata in regular files (that exist both in repo/index and
in workplace).

And that observation solves the initial checkout issue how?

There is always only one place to check for metadata - the index.

quoted

My knowledge of Git internals is quite limited, but if *I* were to do
it right now, I'd introduce a META entry in every TREE object that
would point to a BLOB that contains combined content of
.gitattributes, .gitignore etc.

A tree that has .gitattributes (and I am assuming in the longer
term you can use "ignore" and "precious" in .gitattributes
instead of using .gitignore) POINTS TO A BLOB already, so what
you are saying does not add anything to what we already have,
other than that you are renaming .gitattributes to "META ENTRY".

Almost true! The difference is: META BLOBS are not created as files in the workspace (not during checkout, not ever).
In order to edit it you'd have to use 'git meta' command.
So once again, there is only one place to check for metadata - the index.

When you do "git checkout -- this-path", you are checking things
out from the index and at that point you may not have _any_ tree
yet (think "before initial commit").  A "META ENTRY" that exists
only in a tree does not work -- it has to come to index somehow
for it to work with how git works.

I don't fully understand the difficulty. Here is how I see the initial checkin to work:
Let's say you just did 'git init' and want to add file.txt with unusual crlf. So you don't want automatic translation.
What you'll do is:
* git meta
  In vi you put 'file.txt -crlf'
  git creates a TREE object in the index with only entry META that point to BLOB with this file.
  so it's kind of an empty tree from user's perspective.
* git add file.txt
  while adding the file git consults META BLOB from the TREE (stored in index) and does not do any crlf translation
  the TREE now contains 2 entries: META, and BLOB for file.txt
* git commit
   nothing special here

Now someone else doing initial checkout:
* git checkout
  Before writing file.txt to disk git consults META BLOB (in the index) and does not do any crlf translation.

- Dmitry

On Sun, Aug 26, 2007 at 10:02:50AM CEST, Dmitry Kakurin wrote:

quoted

quoted

My knowledge of Git internals is quite limited, but if *I* were to do
it right now, I'd introduce a META entry in every TREE object that
would point to a BLOB that contains combined content of
.gitattributes, .gitignore etc.

A tree that has .gitattributes (and I am assuming in the longer
term you can use "ignore" and "precious" in .gitattributes
instead of using .gitignore) POINTS TO A BLOB already, so what
you are saying does not add anything to what we already have,
other than that you are renaming .gitattributes to "META ENTRY".

Almost true! The difference is: META BLOBS are not created as files in the 
workspace (not during checkout, not ever).
In order to edit it you'd have to use 'git meta' command.
So once again, there is only one place to check for metadata - the index.

That sounds so incredibly ugly, I really would hate to see that.

It's still not clear to me how this would help anything, though I didn't
watch late Git development. Can you explain some particular scenario
where this would improve the current situation?

-- 
				Petr "Pasky" Baudis
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Dmitry Kakurin wrote:

quoted

A tree that has .gitattributes (and I am assuming in the longer
term you can use "ignore" and "precious" in .gitattributes
instead of using .gitignore) POINTS TO A BLOB already, so what
you are saying does not add anything to what we already have,
other than that you are renaming .gitattributes to "META ENTRY".

Almost true! The difference is: META BLOBS are not created as files in
the workspace (not during checkout, not ever).
In order to edit it you'd have to use 'git meta' command.
So once again, there is only one place to check for metadata - the index.

Can I just chime in here and express my distaste for this idea, on
several grounds, but the summary is that svn does it this way, so it
must be wrong.

These files which store metadata would be stored in a way that is "in
another dimension" to the project files, despite being a part of the
history.  That means that all tools built to deal with regular files and
directories will not be able to merge the changes to the attributes
without special support.  I think this is broken.

This is something I frequently run up against with people coming from
Subversion, which supports unversioned revision properties which can
change randomly and without trace, and per-file/directory properties
which are simply files which you can't refer to in the regular way, and
are interpreted in an application-specific way.

My question to these people, and my question to you is: why do these
files need to be served from another dimension, what value does it add?

You see, either way, their contents need to be processed in an
application-specific way.  Same thing with git's "commit properties" -
basically just RFC822.. headers used in the commit message.  People I
have talked to have described this as "more arbitrary" than conventions
for attributes which are structured.  However, when pressed I have yet
to hear a clear argument why this is the case.

As far as file properties goes, I still like Linus' idea of making these
files which are accessed by treating the file as a directory (eg
filename.txt/ACL, filename.txt/mime-type), and that approach could be
represented in git well.

Sam.