| Message ID | 202009092153.089LrA2R039188@m5p.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | None | expand |
On 02.09.2020 03:08, Elliott Mitchell wrote: > @@ -33,12 +38,12 @@ cscope.po.out > .vscode > > dist > -stubdom/*.tar.gz > > autom4te.cache/ > config.log > config.status > config.cache > +config.h > config/Toplevel.mk > config/Paths.mk While in userland config.h may indeed be a typically generated file, there are three source files by this name under xen/. Patch 6 also doesn't look to override this in any way for xen/. I think this wants to move a level down, into tools/ and wherever else it may be applicable. Jan
On Thu, Sep 24, 2020 at 05:44:09PM +0200, Jan Beulich wrote: > On 02.09.2020 03:08, Elliott Mitchell wrote: > > @@ -33,12 +38,12 @@ cscope.po.out > > .vscode > > > > dist > > -stubdom/*.tar.gz > > > > autom4te.cache/ > > config.log > > config.status > > config.cache > > +config.h > > config/Toplevel.mk > > config/Paths.mk > > While in userland config.h may indeed be a typically generated file, > there are three source files by this name under xen/. Patch 6 also > doesn't look to override this in any way for xen/. I think this wants > to move a level down, into tools/ and wherever else it may be > applicable. Another possibility is Git isn't as aggressive with enforcing ignores as some other version control software is. A file which matches a .gitignore pattern will not show up under "Untracked files" in `git status`; however, /modifying/ a file which is already under control, but matches an ignore pattern *will* cause it to show up under "Changes not staged for commit". Git will also allow you to use `git add -f` on a file which matches an ignore pattern. There are already a few files in Git which have targetted matches pointed at them, yet are still present. Perhaps these were added by mistaken use of `add -f`, perhaps they were deliberately added and the author missed removing the .gitignore entry. As such perhaps the generalized "config.h" pattern is appropriate and move towards removing the few examples which currently exist?
On 24.09.2020 23:48, Elliott Mitchell wrote: > On Thu, Sep 24, 2020 at 05:44:09PM +0200, Jan Beulich wrote: >> On 02.09.2020 03:08, Elliott Mitchell wrote: >>> @@ -33,12 +38,12 @@ cscope.po.out >>> .vscode >>> >>> dist >>> -stubdom/*.tar.gz >>> >>> autom4te.cache/ >>> config.log >>> config.status >>> config.cache >>> +config.h >>> config/Toplevel.mk >>> config/Paths.mk >> >> While in userland config.h may indeed be a typically generated file, >> there are three source files by this name under xen/. Patch 6 also >> doesn't look to override this in any way for xen/. I think this wants >> to move a level down, into tools/ and wherever else it may be >> applicable. > > Another possibility is Git isn't as aggressive with enforcing ignores as > some other version control software is. A file which matches a > .gitignore pattern will not show up under "Untracked files" in > `git status`; however, /modifying/ a file which is already under control, > but matches an ignore pattern *will* cause it to show up under > "Changes not staged for commit". Git will also allow you to use > `git add -f` on a file which matches an ignore pattern. > > There are already a few files in Git which have targetted matches pointed > at them, yet are still present. Perhaps these were added by mistaken use > of `add -f`, perhaps they were deliberately added and the author missed > removing the .gitignore entry. > > As such perhaps the generalized "config.h" pattern is appropriate and > move towards removing the few examples which currently exist? I don't think so, no - new ports will similarly have asm-<arch>/config.h, and there shouldn't be a requirement to "git add -f" them at that point. The role of such named files really is too different to have such a top level entry imo. Jan
On Fri, Sep 25, 2020 at 08:49:01AM +0200, Jan Beulich wrote: > I don't think so, no - new ports will similarly have asm-<arch>/config.h, > and there shouldn't be a requirement to "git add -f" them at that point. > The role of such named files really is too different to have such a top > level entry imo. Okay. I had thought autoconf/configure was by far the most common source of config.h files, and thus best to have in there, but my local copies have been adjusted. There aren't many config.h entries so dumping an attempt at a common pattern is quite appropriate.
diff --git a/.gitignore b/.gitignore index 0f0e79b6d1..507f1eb0cd 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +!__*__.py .hg .*.cmd *.orig @@ -12,11 +13,15 @@ *.so.[0-9]* *.bin *.bak +*.tar +*.tar.*z* *.tmp *.spot *.spit *.gcno *.gcda +*.old +*.pc *.py[ocd] TAGS GTAGS @@ -33,12 +38,12 @@ cscope.po.out .vscode dist -stubdom/*.tar.gz autom4te.cache/ config.log config.status config.cache +config.h config/Toplevel.mk config/Paths.mk @@ -89,33 +94,23 @@ stubdom/vtpm/vtpm_manager.h stubdom/xenstore stubdom/zlib-* tools/*/build/lib*/*.py -tools/config.h config/Tools.mk config/Stubdom.mk config/Docs.mk tools/libs/toolcore/headers.chk -tools/libs/toolcore/xentoolcore.pc tools/libs/toollog/headers.chk -tools/libs/toollog/xentoollog.pc tools/libs/evtchn/headers.chk -tools/libs/evtchn/xenevtchn.pc tools/libs/gnttab/headers.chk -tools/libs/gnttab/xengnttab.pc tools/libs/hypfs/headers.chk -tools/libs/hypfs/xenhypfs.pc tools/libs/call/headers.chk -tools/libs/call/xencall.pc tools/libs/foreignmemory/headers.chk -tools/libs/foreignmemory/xenforeignmemory.pc tools/libs/devicemodel/headers.chk -tools/libs/devicemodel/xendevicemodel.pc tools/console/xenconsole tools/console/xenconsoled tools/console/client/_paths.h tools/console/daemon/_paths.h tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/* tools/debugger/gdb/gdb-6.2.1/* -tools/debugger/gdb/gdb-6.2.1.tar.bz2 tools/debugger/gdbsx/gdbsx tools/debugger/xenitp/xenitp tools/firmware/*/biossums @@ -136,7 +131,6 @@ tools/firmware/rombios/rombios[^/]*.s tools/firmware/rombios/32bit/32bitbios_flat.h tools/firmware/vgabios/vbetables-gen tools/firmware/vgabios/vbetables.h -tools/firmware/xen-dir/*.old tools/firmware/xen-dir/linkfarm.stamp* tools/firmware/xen-dir/xen-root tools/firmware/xen-dir/xen-shim @@ -182,11 +176,8 @@ tools/include/xen/* tools/include/xen-xsm/* tools/include/xen-foreign/*.(c|h|size) tools/include/xen-foreign/checker -tools/libvchan/xenvchan.pc -tools/libxc/*.pc tools/libxl/_libxl.api-for-check tools/libxl/*.api-ok -tools/libxl/*.pc tools/libxl/dsdt* tools/libxl/libxlu_cfg_y.output tools/libxl/mk_dsdt @@ -232,7 +223,6 @@ tools/xenmon/xenbaked tools/xenpaging/xenpaging tools/xenpmd/xenpmd tools/xenstat/libxenstat/src/_paths.h -tools/xenstat/libxenstat/xenstat.pc tools/xenstat/xentop/xentop tools/xenstore/xenstore tools/xenstore/xenstore-chmod @@ -245,7 +235,6 @@ tools/xenstore/xenstore-control tools/xenstore/xenstore-ls tools/xenstore/xenstored tools/xenstore/xenstored_test -tools/xenstore/xenstore.pc tools/xenstore/xs_tdb_dump tools/xentrace/xentrace_setsize tools/xentrace/tbctl @@ -253,7 +242,6 @@ tools/xentrace/xenctx tools/xentrace/xentrace xen/.banner xen/.config -xen/.config.old xen/.xen.elf32 xen/System.map xen/arch/x86/asm-macros.i @@ -284,7 +272,6 @@ xen/include/xen/*.new xen/include/xen/acm_policy.h xen/include/xen/compile.h xen/include/xen/lib/x86/cpuid-autogen.h -xen/test/livepatch/config.h xen/test/livepatch/expect_config.h xen/test/livepatch/*.livepatch xen/tools/symbols @@ -327,7 +314,6 @@ tools/libxl/libxl-save-helper tools/libxl/test_timedereg tools/libxl/test_fdderegrace tools/firmware/etherboot/eb-roms.h -tools/firmware/etherboot/gpxe-git-snapshot.tar.gz tools/libvchan/vchan-node[12] tools/libvchan/vchan-socket-proxy tools/ocaml/*/.ocamldep.make @@ -359,7 +345,6 @@ tools/ocaml/test/list_domains tools/ocaml/test/dmesg tools/ocaml/test/raise_exception tools/debugger/kdd/kdd -tools/firmware/etherboot/ipxe.tar.gz tools/firmware/etherboot/ipxe/ tools/python/xen/lowlevel/xl/_pyxl_types.c tools/python/xen/lowlevel/xl/_pyxl_types.h
"stubdom/*.tar.gz" already existed as an entry. Given the presence of tarball ignore rules for tools, generalize the entry to match most tarballs. Tarballs should generally be left out of git repositories and "-f" is appropriate for the very rare exception. Multiple "config.h" entries had been present. This is common enough to add a common entry to cover the pattern everywhere. Substantial numbers of pkg-config file ignore lines were present. While use of pkg-config is being reduced, ignoring such files in general seems like an appropriate measure. Python is growing in use, since patterns for underscore files seem likely to be added, add a safety pattern to ensure Python double-underscore files are preserved. I'm pretty sure anything .old is unlikely to need to remain in history. Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> --- Question I have is: Should "_*.[chS]" or "_*" be added as ignore patterns? Underscore is frequently used to mark intermediate files used during build, but not worthy of preservation. There are a bunch of directories where "_paths.h" is ignored, and some "_*.[ch]" entries. Yet should this be generalized to *all* underscore files? Preparing for this I've added "!__*__.py" which will override such and ensure "__init__.py" files are *not* ignored. I forsee a future where Python adds another similar filename. --- .gitignore | 27 ++++++--------------------- 1 file changed, 6 insertions(+), 21 deletions(-)