Re: Carrying over attributes when moving files

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2010, 04:05 UTC
Message-ID: <7vzl1pp23z.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100330213049.GB11192@progeny.tock>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 17 quoted lines

> Consider the following directory hierarchy.
>
> 	old-files/
> 		.gitattributes
> 		some-file.html
> 		other-file.html
> 	new-files/
> 		unrelated-file.html
>
> .gitattributes specifies that old HTML files use a CRLF line ending.
>
> 	*.html crlf
>
> What would you expect the following commands to do?
>
> 	git mv old-files/some-file.html new-files/
> 	git commit

I know what you are getting at, but I think it cuts both ways.

I can well imagine that the build structure where "make && make install" will go to old-files and new-files directories and install the contents overlayed in the same destination, and .gitattributes may be being used as a way to "fix" some aspect of "oldness" in old-files/ files until the sources are fixed. So an equally valid work sequence might be:

 	git mv old-files/some-file.html new-files/
	edit new-files/some-file.html
        git add new-files/some-file.html
 	git commit

in which case adding a new "some-file.html crlf" entry to .gitattributes in new-files/ directory would be just _wrong_.

So I am not opposed to a mechanism to _let_ users makes a copy of an entry that covers (or used to cover) one path to apply to another path that was not covered by it, but doing it unconditionally would not be such a good idea.