Re: Carrying over attributes when moving files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]