On 3/19/24 11:02, Martin Kletzander wrote:
On Mon, Mar 18, 2024 at 09:35:32PM +0100, Denis V. Lunev wrote:
> On 3/18/24 15:25, Martin Kletzander wrote:
>> On Mon, Mar 18, 2024 at 02:25:53PM +0100, Pavel Hrdina wrote:
>>> On Mon, Mar 18, 2024 at 01:31:27PM +0100, Peter Krempa wrote:
>>>> On Mon, Mar 18, 2024 at 13:14:54 +0100, Michal Prívozník wrote:
>>>> > On 3/18/24 12:45, Denis V. Lunev wrote:
>>>> > > On 3/18/24 11:42, Michal Prívozník wrote:
>>>> > >> On 3/17/24 16:00, Denis V. Lunev wrote:
>>>> > >>> Signed-off-by: Denis V. Lunev <den(a)openvz.org>
>>>> > >>> ---
>>>> > >>> .gitignore | 1 +
>>>> > >>> 1 file changed, 1 insertion(+)
>>>> > >>>
>>>> > >>> diff --git a/.gitignore b/.gitignore
>>>> > >>> index 4695391342..44a9b446bd 100644
>>>> > >>> --- a/.gitignore
>>>> > >>> +++ b/.gitignore
>>>> > >>> @@ -20,6 +20,7 @@ __pycache__/
>>>> > >>> /build/
>>>> > >>> /ci/scratch/
>>>> > >>> tags
>>>> > >>> +cscope.*
>>>> > >>> # clangd related ignores
>>>> > >>> .clangd
>>>> > >> Apparently, at some point in time this was here, but it
was
>>>> removed:
>>>> > >>
>>>> > >>
>>>>
https://gitlab.com/libvirt/libvirt/-/commit/8a63add283c310952b7df161b4b41...
>>>>
>>>> > >>
>>>> > >> Michal
>>>> > >>
>>>> > > This is quite strange for me:
>>>> > >
>>>>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/....
>>>>
>>>> > >
>>>>
https://gitlab.com/qemu-project/qemu/-/blob/master/.gitignore?ref_type=heads
>>>>
>>>> > >
>>>> > > I do not see any obvious reason how big and extensive
>>>> > > list of files in .gitignore could hurt us while it
>>>> > > is obviously convenient.
>>>> >
>>
>> It might be that once there is too much of it there might be some false
>> positives and it is harder to maintain.
>>
>>>> > Yeah, it feels a bit selective. I mean, we allow vim swap files to
>>>> be in
>>>> > .gitignore, we allow tags file to be there too (which strictly
>>>> speaking
>>>> > is a tooling helper file), but not cscope?
>>>>
>>>> The reasoning to keep 'tags' ignored is because we ship .ctags,
but
>>>> generally tooling files should be ignored by "personal"
>>>> .gitignores as
>>>> we can't cover all of it especially if we don't configure it.
>>>
>>> Agreed, I see we have ignores for vim and emacs, but honestly these
>>> could be removed as well because everyone can just edit
>>> `.config/git/ignore` and put the files created by their favorite
>>> editor
>>> into that file and it will work for every project you participate in.
>>>
>>> Pavel
>>>
>>>> > Martin, do you remember the reasoning there?
>>
>> No, not really, it was most probably what others said above. I don't
>> remember having issues with those ignores, it might've been an end to
>> some discussion we had, not sure. Even though I don't have issues with
>> tool-specific gitignores being there I copied all the non-libvirt
As I said I don't have problems with that ^^, I thought the line could
be based on what we have configs or targets for, for example.
But just out of curiosity I have few questions below.
>> related ignores from our .gitignore to my existing ~/.config/git/ignore
>> and I know I'll be fine in other projects as well. Maybe we were
>> trying
>> to help others learn this "trick" to help them in other repositories.
>>
> For me this is not looking like a reasonable option.
>
> Rationale:
> * I am working on tenth of different hosts in the corporate
> environment and building libvirt not only locally but
> on those hosts too
Are you building it with some script or a long command line that these
files get generated for you? Default build for me does not generate
those.
scope files appear once I am starting to work in the same
way as tags. I need them to navigate over sources.
They do not have any connection to the building procedure.
That is why they are special and falls into the same
category as tags.
Or do you need those tags to browse the code? That would suggest
you
want some configuration setup on those machines as well.
As above. They are heavily used to navigate sources and
unfortunately, I do not have such influence to bring
by default .gitignore to user defaults on the system.
Den
> * This is unavoidable as always there are several different
> versions involved
>
> Within the proposed way, I have EACH time to copy personal
> settings from the root node to all working nodes. This
> looks like a personal pain to me.
>
> I would say, once again, that other projects are going
> different way and the chosen approach does not fit the
> my scenario.
>
> Den
>