Re: .gittattributes handling has deficiencies

On Oct 22, 2007, at 7:01 AM, Shawn O. Pearce wrote:

david@lang.hm wrote:

quoted

On Sun, 21 Oct 2007, Steffen Prohaska wrote:

quoted

If a .gitattributes is in the work tree and we checkout a
different head, the .gitattributes of the head we are switching
to must have precedence.

Maybe the gitattributes of a file should be part of the per-file
flags in the index. Thus we could verify if the flags changed and
if so, adjust the work tree accordig to the new flags.  I'm
lacking a deeper insight into the git internals.  Therefore, I
can't really say if the index is the right place.  But it looks
to me as if changing an attribute should be treated similar to a
changing sha1, as far as the work tree is concerned.

the problem with this is that each attribute ends up needing it's own
flag, which severely limits extending things (see the discussions  
on file
permissions for examples). it's also much harder to manipulate  
them then
in a file.

Yea, you really don't want to copy .gitattributes into the per-file
records in the index.  That's not going to scale as more types of
attributes are defined.

Fortunately the .gitattributes file format was designed to be
readable even when there's merge conflicts; that is it is a
very simple line-oriented record format.  One could difference
the old .gitattributes currently found in the index against the
.gitattributes we are switching to (from the target tree-ish),
scan the lines removed/added, find which files those match against
in the target tree-ish, and just add those files to the list of
things we need to checkout.

If any of those files is dirty then we just refuse the checkout,
just as if the file was modified and we were switching branches.
The user then needs to decide how to continue (probably stash the
file and then restart the checkout).

Sounds like a reasonable plan. I have no time to look into this
right away.

Rather simple IMHO.  Of course I haven't gone into that part of
read-tree recently, and the .gitattribute parser reads from the
working directory, so you need to make sure you checkout the target
.gitattributes file before anything else in the "to process list".

.gitattributes is first looked for in the working directory,
and if not there, .gitattributes is read from the index.

	Steffen