On Mar 30, Jonathan Nieder wrote:
> Eli Barzilay wrote:
>
> > There are a number of technicalities that make git attributes a
> > poor substitute for svn properties -- mainly
> [...]
> > and the fact that they're not tracked with the files (as in svn,
> > where moving a file somewhere will move its properties with it).
>
> It would be great to improve this.
>
> 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
>
> How about these?
>
> mv old-files/some-file.html new-files/
> git add new-files/some-file.html
> git commit -a
>
> I don’t think there’s any fundamental reason this hasn’t been taken
> care of; it’s just that nobody has done it yet.
There's of course a whole bunch of similar issues, like having
a/.gitattribute specifies: b/c foo=bar
a/b/.gitattribute specifies: c foo=bar
or even worse -- when the two values are different.
In any case, the way that attributes are specified (which is flexible
and convenient, fwiw) is part of what makes them a bad substitution
for subversion properties... Making attributes tracked with their
files would mean some change to how this specification is done. For
example, it could be that attributes that are in (tracked)
.gitattribute files nad that have no "/" and no glob characters in the
file names are the only ones that get tracked. In short -- only
simple names of immediate files and/or directories. Having such a
convention would also allow some equivalent of `svn propset' since
there's a canonical place to add them.
And this could be taken further -- for example, a command that will
crawl a tree and find "non-canonicalized" attributes, or will turn
them into such. Another example would be to take something like
"*.html crlf" as meaning that new *.html files should get the crlf
attribute, etc. But thinking about the kind of work that all of this
would imply, it seems to me that doing the svn thing and making the
attributes part of the content (ie, make them a part of the blob
objects somehow) makes more sense. But this is a big change too...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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