Re: Carrying over attributes when moving files

From: Eli Barzilay <eli@barzilay.org>
Date: Mar 31, 2010, 03:30 UTC
Message-ID: <19378.49617.251787.103542@winooski.ccs.neu.edu>
In-Reply-To: <20100330213049.GB11192@progeny.tock>

On Mar 30, Jonathan Nieder wrote:

Show 36 quoted lines

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