Am 20.09.2016 um 16:39 hat Daniel P. Berrange geschrieben: > On Tue, Sep 20, 2016 at 09:38:33AM -0500, Eric Blake wrote: > > On 09/20/2016 09:15 AM, Daniel P. Berrange wrote: > > >>> I guess we could keep things simple by not inventing a new format, > > >>> but instead of using 'check.time', use 'check.time.$FORMAT-$PROTOCOL' > > >>> eg 'check.time.qcow2-file' > > >> > > >> Seems more palatable. Lots of files rather than lots of lines in a > > >> single file; searching is now fast (if you can come up with the right > > >> file name, the OS does the searching for you rather than us having to > > >> figure out which (if any) portion of a large file applies). We may > > >> still want a command for easily cleaning everything, and if we do switch > > >> to new file names, we'll still want to clean up the old files. > > > > > > Isn't that command called 'git clean -f' - if we remove 'check.time' > > > from the gitignore file, it'll be deleted by a git clean, without > > > needing to ass the -i flag. I don't think we really need to reinvent > > > a special way to clean just these timing files, particularly since > > > they are not large. > > > > I'd still rather have the gitignore file ignore anything that we don't > > want to check into the tree (I'm a big fan of 'git add -a .', and hate > > it when non-ignored generated files interfere with that; yes I know I > > can munge .git/info/exclude locally, but it feels cleaner when generated > > files are ignored at the project level). > > > > But yes, relying on git to do the cleanup is fine from my point of view. > > NB, I'd still suggest ignoring check.time-$FORMAT-BACKEND files since > those are current. I was just refering to removal of the legacy check.time > file so next git cleanup kills the obsolete file
Was there a v2 of this series that I missed or was it just forgotten? Kevin