check-attr doesn't respect recursive definitions

2013-03-30 Thread Jan Larres
Hi,

I am trying to write a custom archiving script that checks the
export-ignore attribute to know which files from an ls-files output it
should skip. Through this I noticed that for files in directories for
which the export-ignore (or any other) attribute is set, check-attr
still reports 'unspecified'. More precisely:

$ git init test
Initialized empty Git repository in /home/jan/test/.git/
$ cd test
$ mkdir foo
$ touch foo/bar
$ echo foo export-ignore  .gitattributes
$ git check-attr export-ignore foo
foo: export-ignore: set
$ git check-attr export-ignore foo/bar
foo/bar: export-ignore: unspecified

I would expect the last command to also report 'set'. I've also tried
other patterns like 'foo/' and 'foo*', but it didn't make any
difference. Is this expected behaviour? It does make checking the
attributes of single files somewhat more difficult.

git-archive ignores the directory as expected, but unfortunately it
doesn't have an option to just list the files it would archive instead
of actually archiving them.

This is with git version 1.7.10.4.

-Jan

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: check-attr doesn't respect recursive definitions

2013-04-03 Thread Jan Larres
Thanks for the clarifications. Just a quick comment about the summary:

Jeff King p...@peff.net wrote:
 Yeah, I had the same thought. So you would have to either:

   1. Hook the feature into git-archive, which knows about how it
  recurses, and can report the correct set of paths.

 or

   2. Tell check-attr (or some post-processor) to apply the attribute to
  elements below the path (or possibly to prune out such paths). This
  is not the same as recursive application, because you cannot negate
  it (i.e., you actually find out the final attrs for both foo and
  foo/bar, and then say the attr for 'foo' overrides the attr for
  'foo/bar'.

 I posted a patch for (1), but it felt not-very-general. But (2) also
 feels gross and not very general. Even though it could in theory be used
 for things besides git-archive, it is really just applying git-archive's
 pruning rule, which other programs likely don't care about.

I actually think the first approach is not such a bad idea, it would
make archive more of a general-purpose archiving tool/helper for the
repository rather than just something for the special cases of tars and
zips. But I guess that's somewhat subjective.

Cheers,
Jan

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: check-attr doesn't respect recursive definitions

2013-04-06 Thread Jan Larres
Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Mar 30, 2013 at 8:45 PM, Jan Larres j...@majutsushi.net wrote:
 I would expect the last command to also report 'set'. I've also tried
 other patterns like 'foo/' and 'foo*', but it didn't make any
 difference.

 Try foo/**. You need 1.8.2 though.

That indeed works exactly the way I would like! Thanks a lot!

Jan

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html