Re: git check-attr in bare repositories

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

 



On Mar 29, Jonathan Nieder wrote:
> 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!
--
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]