Re: .gittattributes handling has deficiencies

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

 




On Oct 22, 2007, at 12:29 PM, Johannes Schindelin wrote:


On Mon, 22 Oct 2007, Steffen Prohaska wrote:

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

Of course we could change that to do it the other way round.  But this
would contradict expectations when you edit .gitattributes and then
checkout single files without having git-add'ed .gitattributes first.

The biggest problem in your setup, however, is not if .gitattributes is read from the index or the working directory. The biggest problem is that
files are not touched when their contents have not changed.

IOW if you have .gitattributes in the to-be-checked-out branch which say
that README is crlf, and in the current branch it is not, and README's
_contents_ are identical in both branches, a "git checkout
<that-other-branch>" will not rewrite README, and consequently not change
the working copy to crlf.

Exactly. The order of reading .gitattributes from the working
directory or the index doesn't matter. The current mechanism
has a more fundamental deficiency.

Changes of.gitattributes can influence how the same content
is checked out to the work tree. If .gitattributes change the
checkout may need to be updated, even if the real content did
not change.

	Steffen
-
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]

  Powered by Linux