Re: .gittattributes handling has deficiencies

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 22, 2007, 05:45 UTC
Message-ID: <565E1D52-59C4-4EB8-AA81-FF94F346FE61@zib.de>
In-Reply-To: <20071022050111.GL14735@spearce.org>

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

Show 38 quoted lines

> david@lang.hm wrote:
>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>>> 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