| Summary: | .gitignore enhancement: common template with default values for components | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Gaetan Nadon <memsize> | ||||||
| Component: | Build/Modular | Assignee: | Gaetan Nadon <memsize> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | enhancement | ||||||||
| Priority: | low | CC: | alan.coopersmith, peter.hutterer | ||||||
| Version: | git | Keywords: | janitor | ||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 23814, 24206 | ||||||||
| Attachments: |
|
||||||||
|
Description
Gaetan Nadon
2009-09-30 17:46:35 UTC
Created attachment 29965 [details]
Comprehensive example using xserver .gitignore files
Created attachment 29966 [details]
The .gitignore template with default values for compoennts
for some reason, bugzilla doesn't give me the attachments right now, so I have to write part of this from memory, I looked at the template a few days ago
I like the idea in principle, though a few questions I have here.
- Do we want to continue using .gitignore in subdirectories? I'm not a big fan of having those sprinkled in "random" directories though I acknowledge that this is current practice. Though not without problems: for example, the xserver gitignore has overlapping .gitignore rules from the top-level and the subdirectory .gitignores. IMO in the long-term it'll be cleaner to have a single .gitignore.
- I think the template needs massive warnings in the top of the file to make sure nobody tries to add to the common section without updating all the other templates too. Is there anything we can do to avoid becoming inconsistent?
> What's the risk of erroneously ignoring a file? Next to none.
IMO, this is the biggest risk since one may forget to git add a new file and you won't notice until other people are shouting at you. Nothing easily fixable but it leaves the server unbuildable until that file is added again. Such commits should be avoided at all costs.
(In reply to comment #3) > for some reason, bugzilla doesn't give me the attachments right now, so I have > to write part of this from memory, I looked at the template a few days ago > I like the idea in principle, though a few questions I have here. > > - Do we want to continue using .gitignore in subdirectories? I'm not a big fan > of having those sprinkled in "random" directories though I acknowledge that > this is current practice. Though not without problems: for example, the xserver I have thought about it a lot. Centralize vs decentralize. I noted many entries were made as paths rather than pattern. So test/video/regdump wasn't meant as a pattern but as file in a particular location. There can't be more than one test/video directory. With this mind set, it is natural to think of .gitignore as a high level list of paths. But this isn't what .gitignore is about, the way I understand it. You specify file stem patterns which apply in whatever directory they happen to be. For example *.o or Makefile. You don't want to list hw/dmx/Makefile. Having said this, it also depends who is updating .gitignore. If it is one person who knows it all, it might be preferable to centralize. On the other hand, if subdirectories come and go, it's better to be decentralized. when a directory is removed, so is the .gitignore. I saw a lot of pollution in the toplevel one. It won't be possible to to never have a subdir .gitignore, for example there is a config.h in a subdir which is a normal header file. Unfortunatly, I had to write a few subdir .gitignore because of the man page generated from Docbook. Some generated files are checked-in which are ignore by the toplevel. Using the template does not enforce one method over the other. I noticed there were already files in subdirs so I followed this pattern. > gitignore has overlapping .gitignore rules from the top-level and the > subdirectory .gitignores. IMO in the long-term it'll be cleaner to have a > single .gitignore. > > - I think the template needs massive warnings in the top of the file to make > sure nobody tries to add to the common section without updating all the other > templates too. Is there anything we can do to avoid becoming inconsistent? > If the default section is changed, there won't be any harm done in the component so as long as he knows what he is doing. But we lose in consistency. A post-build tool checker is the only thing I can think of. Large projects have this for policy enforcement. > > What's the risk of erroneously ignoring a file? Next to none. > > IMO, this is the biggest risk since one may forget to git add a new file and > you won't notice until other people are shouting at you. Nothing easily fixable > but it leaves the server unbuildable until that file is added again. Such > commits should be avoided at all costs. > That statement was referring to the techniques I used to create the template. I did not mean that using the template will prevent erroneously ignoring a file. Apologies. Using a template will not contribute to this problem unless it is poorly designed. For instance, if I had included lex.c because I saw one place using it, it could ignore a valid (none generated) lex.c file somewhere. That's why the default section only contains known generated files that were already present and were cross-referenced by the documentation and searched over the Internet for use cases. If we are to generate the INSTALL file then I need to add it to the template. If there is a non-generated INSTALL file in a sub dir, you can add a .gitignore with !INSTALL or add in the toplevel one !subdir/INSTALL. Thanks, this was a good workout. Fix typo in title All patches applied. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.