Create .gitignore file for excluding any binary/executable files from…

[reshke]

… git.

[yugo-n]

Thanks!

I usually use Linux & gcc, so I'm not familiar to some extensions you include in .gitigonre. Is it possible that all of them are created during building pg_ivm?

[reshke]

Thanks!

I usually use Linux & gcc, so I'm not familiar to some extensions you include in .gitigonre. Is it possible that all of them are created during building pg_ivm?

I just used github .gitignore file template for C development:) I'm pretty sure that *.exe files will not ever be created. I cam remove some of file patterns.

[yugo-n]

I'm pretty sure that *.exe files will not ever be created.

Definitely. pg_ivm doesn't create executable file, so *.out will not, either.

I cam remove some of file patterns.

Yeah, I prefer simpler one.

I've researched .gitigonres in some popular extensions for PostgreSQL.

https://github.com/pgbigm/pg_bigm/blob/master/.gitignore https://github.com/pgpartman/pg_partman/blob/master/.gitignore https://github.com/pgvector/pgvector/blob/master/.gitignore https://github.com/ossc-db/pg_hint_plan/blob/master/.gitignore https://github.com/pgaudit/pgaudit/blob/master/.gitignore https://github.com/citusdata/pg_cron/blob/main/.gitignore https://github.com/timescale/timescaledb/blob/main/.gitignore https://github.com/postgis/postgis-java/blob/main/.gitignore

Some are short and others are long, but the trend seems that smaller the code size is, the shorter .gitignore is. I think starting from simpler is better, so how about including .bc, .o, and *.so, and files/directories generated for regression tests, like that of pg_bigm or pgaudit?

I wonder files generated in Windows are not necessary for now, and we would add them if developers using Windows claim it.

What do you think?

[reshke]

I'm pretty sure that *.exe files will not ever be created.

Definitely. pg_ivm doesn't create executable file, so *.out will not, either.

I cam remove some of file patterns.

Yeah, I prefer simpler one.

I've researched .gitigonres in some popular extensions for PostgreSQL.

https://github.com/pgbigm/pg_bigm/blob/master/.gitignore https://github.com/pgpartman/pg_partman/blob/master/.gitignore https://github.com/pgvector/pgvector/blob/master/.gitignore https://github.com/ossc-db/pg_hint_plan/blob/master/.gitignore https://github.com/pgaudit/pgaudit/blob/master/.gitignore https://github.com/citusdata/pg_cron/blob/main/.gitignore https://github.com/timescale/timescaledb/blob/main/.gitignore https://github.com/postgis/postgis-java/blob/main/.gitignore

Some are short and others are long, but the trend seems that smaller the code size is, the shorter .gitignore is. I think starting from simpler is better, so how about including .bc, .o, and *.so, and files/directories generated for regression tests, like that of pg_bigm or pgaudit?

I wonder files generated in Windows are not necessary for now, and we would add them if developers using Windows claim it.

What do you think?

Hi and sorry for long response... So, my opinion is that best choice for now is copy-pasting pgvector's version of gitignore, because this extension is similar to pg_ivm (in terms of code size) the most.

[reshke]

copy-pasting pgvector's version of gitignore

Did that

[yugo-n]

Thank you for your update.

So, my opinion is that best choice for now is copy-pasting pgvector's version of gitignore, because this extension is similar to pg_ivm (in terms of code size) the most.

Well, although I mentioned the code size, I am not sure this necessary decides which one is the best choice among these examples I selected arbitrarily. Also, that of pgvector contains definitely unnecessary patterns like "/sql/vector--?.?.?.sql" and "/dist". On Windows, we may also ignore "*.exp", but I have no idea exactly what files should be ignored in the pg_ivm case... So, could we start more simpler one like that of pg_bigm? If you want to ignore other types of files, you can modify this to add these patterns.

[reshke]

So, could we start more simpler one like that of pg_bigm?

Ok, looks reasonable

[yugo-n]

Thank you for updating it! It seems good, so I'll merge it soon.