On Sun, 21 Oct 2007, Steffen Prohaska wrote:

quoted text
> 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. Files are expected to be converted as
> configured in the .gitattributes that is available in the head
> we're switching to.
>
> This adds a test case revealing deficiencies of the current
> handling of .gitattributes.
>
> At a first glance, I saw two possible resolutions:
> 1) .gitattributes from the index has precedence. It's unclear
>   how merging can be handled appropriately.
> 2) .gitattributes are handled as a special file. Checkout is a
>   two pass process. In the first pass only the special file
>   .gitattributes is checked out. In th second pass the remaining
>   files are added. Maybe this gives a perspective how to handle
>   merges.
>
> But actually the issue is much harder to solve.
>
> Here is what needs to be done: Whenever the attributes of a file
> change the file must be freshly checked out according to the
> attributes of the head we switch to.

this is the same problem that we would have with the extended file 
attributes, in the discussion for those it was suggested that I refrence 
the file from the index rather then from the file system to avoid needing 
to do two passes.

quoted text
> The file itself does not
> necessarily change between the two commits. A fresh checkout is
> already needed if only .gitattributes change.
>
> But this is really hard to solve. We would need to compare
> attributes before and after for _all_ files that have attributes
> in one of the two commits and check if they changed. If so, we
> need to do a fresh checkout according to the new attributes.

if you know that you will get the new .gitattributes if it changes, setup 
a post-checkout hook to checkout everything if it has changed. it's far 
from ideal, but it should be a good, safe, first approximation.

you shouldn't need to check all files of all attributes, only on any that 
match the lines that get changed. the hook for this is exactly the type of 
thing that I was talking about in the metastore thread.

quoted text
> 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.

David Lang

quoted text
> So, I need some help.
>    Steffen
>
> ---
> t/t0020-crlf.sh |   23 +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> index 62bc4bb..5d7e033 100755
> --- a/t/t0020-crlf.sh
> +++ b/t/t0020-crlf.sh
> @@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
> 	}
> '
>
> +test_expect_success 'in-tree .gitattributes (5)' '
> +
> +	git reset --hard master &&
> +	echo >.gitattributes &&
> +	git add .gitattributes &&
> +	git commit -m "empty .gitattributes" &&
> +	rm -rf tmp one dir .gitattributes patch.file three &&
> +	git reset --hard master &&
> +	git checkout master^ &&
> +
> +	if remove_cr one >/dev/null
> +	then
> +		echo "Eh? one should not have CRLF"
> +		false
> +	else
> +		: happy
> +	fi &&
> +	remove_cr three >/dev/null || {
> +		echo "Eh? three should still have CRLF"
> +		false
> +	}
> +'
> +
> test_expect_success 'invalid .gitattributes (must not crash)' '
>
> 	echo "three +crlf" >>.gitattributes &&
>
-
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