home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] more git pedantry -- clarifications about .gitignore

  • Subject: Re: [OCLUG-Tech] more git pedantry -- clarifications about .gitignore
  • From: Alex Pilon <alp [ at ] alexpilon [ dot ] ca>
  • Date: Wed, 29 Apr 2015 12:48:20 -0400
> > On Wed, Apr 29, 2015 at 08:33:51AM -0400, Robert P. J. Day wrote:
> > >   and another thing ... why both of these lines?
> > >
> > > include/generated
> > > arch/*/include/generated
> > >
> > > isn't there a wildcard pattern that would subsume both of those
> > > entries?
> >
> On Wed, 29 Apr 2015, Alex Pilon wrote:
> > **/include/generated
>
On Wed, Apr 29, 2015 at 12:18:05PM -0400, Robert P. J. Day wrote:
>   which brings up even more pedantry (as you knew it would) ... from
> "man 5 gitignore", we read:
>
> "If the pattern ends with a slash, it is removed for the purpose of
> the following description, but it would only find a match with a
> directory. In other words, foo/ will match a directory foo and paths
> underneath it, ..."
>
>   in other words, "foo" would match all objects named "foo"
> recursively and, in this trivial case, would be entirely equivalent
> to:
>
>   **/foo
>
> however, it's not clear whether that equivalence would be true here:
>
>   **/foo/bar
>   foo/bar
>
> are *those* equivalent? based on my reading, i don't think so -- if
> you want to recursively match a multi-level pathname, you would appear
> to need the leading "**/", is that correct?

From a quick test I did, it seems you do need to add the double
asterisk. Try to replicate the arch/include/generated and
include/generated example.

Attachment: pgpyWQHLsUpQt.pgp
Description: PGP signature