.gitignore files, take two
От | Tom Lane |
---|---|
Тема | .gitignore files, take two |
Дата | |
Msg-id | 22802.1285041639@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: .gitignore files, take two
Re: .gitignore files, take two Re: .gitignore files, take two Re: .gitignore files, take two |
Список | pgsql-hackers |
Back here I asked what we were going to do about .gitignore files: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01232.php The thread died off when the first git conversion attempt crashed and burned; but not before it became apparent that we didn't have much consensus. It seemed that there was lack of agreement as to: 1. Whether to keep the per-subdirectory ignore files (which CVS insisted on, but git doesn't) or centralize in a single ignore file. 2. Whether to have the ignore files ignore common cruft such as editor backup files, or only "expected" build product files. It was pointed out that exclusion rules could be configured locally to one's own repository, so one possible answer to issue #2 is to have only a minimal ignore-set embodied in .gitignore files, and let people who prefer to ignore more stuff set that up in local preferences. Although this point wasn't really brought up during that thread, it's also the case that the existing implementation is far from consistent about ignoring build products. We really only have .cvsignore entries for files that are not in CVS but are meant to be present in distribution tarballs. CVS will, of its own accord, ignore certain build products such as .o files; but it doesn't ignore executables for instance. So unless you do a "make distclean" before "cvs update", you will get notices about non-ignored files. That never bothered me particularly but I believe it annoys some other folks. So really there is a third area of disagreement: 3. What are the ignore filesets *for*, in particular should they list just the derived files expected in a distribution tarball, or all the files in the set of build products in a normal build? We need to get some consensus on this now. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: