Duy Nguyen wrote:
> On Sat, Mar 30, 2013 at 8:45 PM, Jan Larres 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 w
On Sat, Mar 30, 2013 at 8:45 PM, Jan Larres 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.
--
Duy
--
To unsubscribe from this list: send the line "uns
Thanks for the clarifications. Just a quick comment about the summary:
Jeff King 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
On Tue, Apr 02, 2013 at 10:16:55AM -0700, Junio C Hamano wrote:
> > Yes, but as I explained later, the meaning of "apply an attribute to
> > dir" in such cases is always equivalent to "apply attribute
> > recursively to dir/*". So I do not think we are violating that rule to
> > recursively apply
Jeff King writes:
> On Tue, Apr 02, 2013 at 09:43:30AM -0700, Junio C Hamano wrote:
>
>> > In some systems, yes, but git does not have any notion of "doc/" as an
>> > item (after all, we track content in files, not directories), so I do
>> > not see what it means to specify a directory except to
On Tue, Apr 02, 2013 at 12:51:28PM -0400, Jeff King wrote:
> But let's take a step back. I think Jan is trying to do a very
> reasonable thing: come up with the same set of paths that git-archive
> would. What's the best way to solve that? Recursive application of
> attributes is one way, but is t
On Tue, Apr 02, 2013 at 09:43:30AM -0700, Junio C Hamano wrote:
> > In some systems, yes, but git does not have any notion of "doc/" as an
> > item (after all, we track content in files, not directories), so I do
> > not see what it means to specify a directory except to say "everything
> > under
Jeff King writes:
> On Tue, Apr 02, 2013 at 09:11:02AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Yes, it is the expected behavior, though I cannot offhand think of
>> > anything that would break if we did apply it recursively.
>>
>> Conceptually that breaks our brain. "All f
On Tue, Apr 02, 2013 at 09:11:02AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, it is the expected behavior, though I cannot offhand think of
> > anything that would break if we did apply it recursively.
>
> Conceptually that breaks our brain. "All files in doc/ directories
> ar
Jeff King writes:
> Yes, it is the expected behavior, though I cannot offhand think of
> anything that would break if we did apply it recursively.
Conceptually that breaks our brain. "All files in doc/ directories
are text" and "doc/ directory is text" are two different things, no?
--
To unsub
On Tue, Apr 02, 2013 at 10:31:30AM -0400, Jeff King wrote:
> On Sat, Mar 30, 2013 at 09:45:51AM +, Jan Larres wrote:
>
> > 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
On Sat, Mar 30, 2013 at 09:45:51AM +, Jan Larres wrote:
> 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 (o
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 'unspeci
13 matches
Mail list logo
