Hi, On Sat, Aug 31, 2019 at 7:45 AM Jelmer Vernooij <jel...@debian.org> wrote:
> On Sun, Jul 28, 2019 at 11:01:29PM -0400, Felipe Sateler wrote: > > On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij <jel...@debian.org> wrote: > > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote: > > > > lintian-brush complains repository is dirty, but repo is clean: > > > > > > > > felipe@felipedell:csound% lintian-brush > > > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending > > > changes first. > > > > % git status > > > > On branch master > > > > Your branch is ahead of 'origin/master' by 3 commits. > > > > (use "git push" to publish your local commits) > > > > > > > > nothing to commit, working tree clean > > > > > > > > > > > > Turns out there are gitignored files: > > > > > > > > % git clean -fdX > > > > Removing .pc/ > > > > Removing .vscode/ > > > > Removing test.wav > > > > > > > > After this lintian-brush can work. > > > > > > > > I think lintian-brush should also ignore gitignored files > > > > > > lintian-brush attempts to ignore gitignored files, but it seems that > > > this doesn't always work. > > > > > > In this particular case, it appears that it does properly ignore > > > test.wav because "*.wav" exists in .gitignore. > > > > > > I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do > > > you perhaps have them in ~/.git/ignore ? > > Yes, I have .vscode in the global gitignore. > > > > Were there any files under > > > .pc/ or .vscode/ that you can remember? > > > > > I don't know if .pc had anything in it, but .vscode probably did. > Can you try again with dulwich currently in unstable? Several > gitignore fixes have gone in that may have addressed this. > It's still failing. I think global gitignore is not processed by lintian-brush. > > > I wonder why not just rely on git status (or the plumbing equivalent) > > instead of detecting changes manually? > Mostly to avoid shelling out - lintian-brush runs the equivalent of > git status times before and after running each fixer - that can be > quite slow on large repositories, where each run takes ~.5 seconds. > Rather than statting, it uses inotify to watch what files have > changed by each fixer, and then checks if those are ignored files or > not. > But why is it necessary to run after each fixer? Perhaps a single one at the start is necessary. -- Saludos, Felipe Sateler
