tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is
intended to ignore the following build artifact:
tools/bpf/bpftool/bpftool
However, the .gitignore entry is effective not only for the current
directory, but also for any sub-directories.
So, the following file is also considered to be ignored:
tools/bpf/bpftool/bash-completion/bpftool
It is obviously version-controlled, so should be excluded from the
.gitignore pattern.
You can fix it by prefixing the pattern with '/', which means it is
only effective in the current directory.
I prefixed the other patterns consistently. IMHO, '/' prefixing is
safer when you intend to ignore specific files.
Signed-off-by: Masahiro Yamada <[email protected]>
---
tools/bpf/bpftool/.gitignore | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
index 67167e4..19efcc8 100644
--- a/tools/bpf/bpftool/.gitignore
+++ b/tools/bpf/bpftool/.gitignore
@@ -1,5 +1,5 @@
*.d
-bpftool
-bpftool*.8
-bpf-helpers.*
-FEATURE-DUMP.bpftool
+/bpftool
+/bpftool*.8
+/bpf-helpers.*
+/FEATURE-DUMP.bpftool
--
2.7.4
2019-04-29 23:47 UTC+0900 ~ Masahiro Yamada <[email protected]>
> tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is
> intended to ignore the following build artifact:
>
> tools/bpf/bpftool/bpftool
>
> However, the .gitignore entry is effective not only for the current
> directory, but also for any sub-directories.
>
> So, the following file is also considered to be ignored:
>
> tools/bpf/bpftool/bash-completion/bpftool
>
> It is obviously version-controlled, so should be excluded from the
> .gitignore pattern.
>
> You can fix it by prefixing the pattern with '/', which means it is
> only effective in the current directory.
>
> I prefixed the other patterns consistently. IMHO, '/' prefixing is
> safer when you intend to ignore specific files.
>
> Signed-off-by: Masahiro Yamada <[email protected]>
> ---
Hi,
“Files already tracked by Git are not affected” by the .gitignore (says
the relevant man page), so bash completion file is not ignored. It would
be if we were to add the sources to the index of a new Git repo. But
sure, it does not cost much to make the .gitignore cleaner.
>
> tools/bpf/bpftool/.gitignore | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
> index 67167e4..19efcc8 100644
> --- a/tools/bpf/bpftool/.gitignore
> +++ b/tools/bpf/bpftool/.gitignore
> @@ -1,5 +1,5 @@
> *.d
> -bpftool
> -bpftool*.8
> -bpf-helpers.*
> -FEATURE-DUMP.bpftool
> +/bpftool
> +/bpftool*.8
> +/bpf-helpers.*
Careful when you add all those slashes, however. "bpftool*.8" and
"bpf-helpers.*" should match files under Documentation/, so you do NOT
want to prefix them with just a "/".
Quentin
> +/FEATURE-DUMP.bpftool
>
Hi Quentin,
On Tue, Apr 30, 2019 at 12:33 AM Quentin Monnet
<[email protected]> wrote:
>
> 2019-04-29 23:47 UTC+0900 ~ Masahiro Yamada <[email protected]>
> > tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is
> > intended to ignore the following build artifact:
> >
> > tools/bpf/bpftool/bpftool
> >
> > However, the .gitignore entry is effective not only for the current
> > directory, but also for any sub-directories.
> >
> > So, the following file is also considered to be ignored:
> >
> > tools/bpf/bpftool/bash-completion/bpftool
> >
> > It is obviously version-controlled, so should be excluded from the
> > .gitignore pattern.
> >
> > You can fix it by prefixing the pattern with '/', which means it is
> > only effective in the current directory.
> >
> > I prefixed the other patterns consistently. IMHO, '/' prefixing is
> > safer when you intend to ignore specific files.
> >
> > Signed-off-by: Masahiro Yamada <[email protected]>
> > ---
>
> Hi,
>
> “Files already tracked by Git are not affected” by the .gitignore (says
> the relevant man page), so bash completion file is not ignored. It would
> be if we were to add the sources to the index of a new Git repo. But
> sure, it does not cost much to make the .gitignore cleaner.
Right, git seems to be flexible enough.
But, .gitignore is useful to identify
build artifacts in general.
In fact, other than git, some projects
already parse this.
For example, tar(1) supports:
--exclude-vcs-ignores
read exclude patterns from the VCS ignore files
As of writing, this option works only to some extent,
but I thought this would be useful to create a source
package without relying on "git archive".
When I tried "tar --exclude-vcs-ignores", I noticed
tools/bpf/bpftool/bash-completion/bpftool was not
contained in the tarball.
That's why I sent this patch.
I can add more info in v2 to clarify
my motivation though.
> >
> > tools/bpf/bpftool/.gitignore | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
> > index 67167e4..19efcc8 100644
> > --- a/tools/bpf/bpftool/.gitignore
> > +++ b/tools/bpf/bpftool/.gitignore
> > @@ -1,5 +1,5 @@
> > *.d
> > -bpftool
> > -bpftool*.8
> > -bpf-helpers.*
> > -FEATURE-DUMP.bpftool
> > +/bpftool
> > +/bpftool*.8
> > +/bpf-helpers.*
>
> Careful when you add all those slashes, however. "bpftool*.8" and
> "bpf-helpers.*" should match files under Documentation/, so you do NOT
> want to prefix them with just a "/".
OK, I should not have touched what I was unsure about.
Will fix in v2.
> Quentin
>
> > +/FEATURE-DUMP.bpftool
> >
>
--
Best Regards
Masahiro Yamada
2019-04-30 09:15 UTC+0900 ~ Masahiro Yamada <[email protected]>
> Hi Quentin,
>
>
> On Tue, Apr 30, 2019 at 12:33 AM Quentin Monnet
> <[email protected]> wrote:
>>
>> 2019-04-29 23:47 UTC+0900 ~ Masahiro Yamada <[email protected]>
>>> tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is
>>> intended to ignore the following build artifact:
>>>
>>> tools/bpf/bpftool/bpftool
>>>
>>> However, the .gitignore entry is effective not only for the current
>>> directory, but also for any sub-directories.
>>>
>>> So, the following file is also considered to be ignored:
>>>
>>> tools/bpf/bpftool/bash-completion/bpftool
>>>
>>> It is obviously version-controlled, so should be excluded from the
>>> .gitignore pattern.
>>>
>>> You can fix it by prefixing the pattern with '/', which means it is
>>> only effective in the current directory.
>>>
>>> I prefixed the other patterns consistently. IMHO, '/' prefixing is
>>> safer when you intend to ignore specific files.
>>>
>>> Signed-off-by: Masahiro Yamada <[email protected]>
>>> ---
>>
>> Hi,
>>
>> “Files already tracked by Git are not affected” by the .gitignore (says
>> the relevant man page), so bash completion file is not ignored. It would
>> be if we were to add the sources to the index of a new Git repo. But
>> sure, it does not cost much to make the .gitignore cleaner.
>
> Right, git seems to be flexible enough.
>
>
> But, .gitignore is useful to identify
> build artifacts in general.
> In fact, other than git, some projects
> already parse this.
>
> For example, tar(1) supports:
>
> --exclude-vcs-ignores
> read exclude patterns from the VCS ignore files
>
>
> As of writing, this option works only to some extent,
> but I thought this would be useful to create a source
> package without relying on "git archive".
>
> When I tried "tar --exclude-vcs-ignores", I noticed
> tools/bpf/bpftool/bash-completion/bpftool was not
> contained in the tarball.
>
> That's why I sent this patch.
Ok, thanks for explaining! Makes sense to me now.
>
> I can add more info in v2 to clarify
> my motivation though.
Sounds good, yes please.
>
>
>>>
>>> tools/bpf/bpftool/.gitignore | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
>>> index 67167e4..19efcc8 100644
>>> --- a/tools/bpf/bpftool/.gitignore
>>> +++ b/tools/bpf/bpftool/.gitignore
>>> @@ -1,5 +1,5 @@
>>> *.d
>>> -bpftool
>>> -bpftool*.8
>>> -bpf-helpers.*
>>> -FEATURE-DUMP.bpftool
>>> +/bpftool
>>> +/bpftool*.8
>>> +/bpf-helpers.*
>>
>> Careful when you add all those slashes, however. "bpftool*.8" and
>> "bpf-helpers.*" should match files under Documentation/, so you do NOT
>> want to prefix them with just a "/".
>
> OK, I should not have touched what I was unsure about.
> Will fix in v2.
Thanks!
Quentin