Re: Patch to .gitignore
От | Tom Lane |
---|---|
Тема | Re: Patch to .gitignore |
Дата | |
Msg-id | 23775.1369400244@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch to .gitignore (Fabrízio de Royes Mello <fabriziomello@gmail.com>) |
Список | pgsql-hackers |
Fabrízio de Royes Mello <fabriziomello@gmail.com> writes: > On Fri, May 24, 2013 at 12:04 AM, Christopher Browne <cbbrowne@gmail.com>wrote: >> There hasn't been general agreement on the merits of particular .gitignore >> rules of this sort. > I agree with you about vim-oriented patterns, because its a particular > tool, but "ctags" and "etags" be part of postgres source tree and its > generate some output inside them, so I think we must ignore it. [ shrug... ] Editor backup files get generated inside the source tree as well. Chris stated the policy accurately: if you use tools that leave unexpected files in the source tree, it's up to you to have a personal .gitignore for those, assuming you want them ignored. The project's .gitignore files are only supposed to list files that get generated by the standard build processes. FWIW, my personal .gitexclude file looks like *~ *.orig where the latter one is for junk generated by "patch". I believe patch's extension for saved files varies across versions, so it wouldn't be too sensible to have an exclusion like that in the project-wide file. Note also that I intentionally *don't* have an exclusion for *.rej --- if any patch hunk failed, I want git to mention it. But that's a matter of personal preference. I rather imagine that other people configure it differently, and that's fine. As long as we don't try to put such things in the project-wide exclusion list, we don't have to have a consensus about it. regards, tom lane
В списке pgsql-hackers по дате отправления: