Re: git check-attr in bare repositories

From: Eli Barzilay <eli@barzilay.org>
Date: Mar 30, 2010, 04:53 UTC
Message-ID: <19377.33747.838003.360864@winooski.ccs.neu.edu>
In-Reply-To: <20100329231501.GA28194@progeny.tock>

On Mar 29, Jonathan Nieder wrote:

Show 17 quoted lines

> Eli Barzilay wrote:
> > On Mar 29, Eli Barzilay wrote:
> >> On Mar 27, Jonathan Nieder wrote:
> [in a bare repository]
> 
> >>>  GIT_INDEX=tmp-index git check-attr "$@" &&
> [...]
> >> I tried that, but it doesn't work.  (I used GIT_INDEX_FILE.)
> 
> Yes, not sure how I confused myself.
> 
> git explicitly guards against that in attr.c.
> 
> 	/*
> 	 * Read from parent directories and push them down
> 	 */
> 	if (!is_bare_repository() || direction == GIT_ATTR_INDEX) {

Ugh...!

> That check comes from v1.5.6-rc3~9^2 (Ignore .gitattributes in bare
> repositories, 2008-06-08).  This is consistent with how bare
> repositories generally work: they are guarded against use with a
> populated index, since what filesystem tree would that index track?

Well, I've seen more than a few places that say that git attributes are the right choice to use for svn properties... (I think that I also asked a question about this here.)

There are a number of technicalities that make git attributes a poor substitute for svn properties -- mainly the fact that they limited in contents (basically just short strings, no quoting, no newlines), 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). Both of these are not too bad for what we use them (files don't move often, and we use short strings only). But having no access to them on the server (without a costly checkout) is making it even more problematic, to the point that coming up with our own home cooked thing is easier than using git attributes. Given that they're not intended for end-user consumption (eg, `check-attr' being an internal helper) it looks like we're not giving up much anyway.

> To support your use case, it would be nice for check-attr to learn a
> --direction option.  Maybe it would be safe to let check-attr read
> from the index in bare repositories by default anyway, since the
> index is usually missing anyway.

Well, using the index this way seems like a kind of a hack anyway, so I'm not sure that there is any reason to do this. If anything, I'd like it if `check-attr' could just use the repository directly instead of the index (or a work tree) in a bare repository. Without that, and the best solution that I see in the short term, it should throw an appropriate error instead of just producing an "unspecified".

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!