Using --git-commit-id option with verbose logging outputs "Found migration x that is not present in loaded migration."

[jag-ermeister]

After viewing some of the other open and closed issues around the --git-commit-id option, I have come up with this command:

python manage.py lintmigrations --git-commit-id 2f69ac96ce080b45f4749cf95165341a8c0447e4 --project-root-path '.' -v 3

After executing that command, I receive this output:

Chosen SQL analyser class: <class 'django_migration_linter.sql_analyser.sqlite.SqliteAnalyser'>
Executing cd . && git diff --relative --name-only --diff-filter=AR 2f69ac96ce080b45f4749cf95165341a8c0447e4
Found migration file (0002_rename_author_books_author_name.py, migrations) that is not present in loaded migration.
*** Summary ***
Valid migrations: 0/0
Erroneous migrations: 0/0
Migrations with warnings: 0/0
Ignored migrations: 0/0

So the migration in question (which has a backwards-incompatible change) is found, but it is ignored for some reason. Why is this?

If I run this command python manage.py lintmigrations, I get the output that I expect:

(migrations, 0001_initial)... OK
(migrations, 0002_rename_author_books_author_name)... ERR
        RENAMING columns (table: migrations_books, column: author)
*** Summary ***
Valid migrations: 1/2
Erroneous migrations: 1/2
Migrations with warnings: 0/2
Ignored migrations: 0/2

Any ideas? Thanks!

[jag-ermeister]

In case it is relevant, my project looks like this

I have the settings.py in the migrationdemo folder, and then the migrations are within another Django app called migrations.

[jag-ermeister]

The tuple that gets returned after identifying migrations seems to be flipped when getting them from git. When getting them with the --git-commit-id file, it outputs (0002_rename_author_books_author_name.py, migrations). Without that flag, it outputs (migrations, 0002_rename_author_books_author_name.py). It seems to think that 0002_rename_author_books_author_name.py is the app_label and migrations is the name.

[phillipuniverse]

@jag-ermeister is it possible that you have the same issue described at #249 and fixed in #248?

[jag-ermeister]

@phillipuniverse I would say it is very possible that this is the same issue. I can definitely check that out after #248 merged and released.

[jag-ermeister]

A colleague of mine tried out version 5 of this library and this functionality worked beautifully. I think that commit #248 was the fix. Thanks!

[phillipuniverse]

@jag-ermeister just FYI #248 was never merged

[David-Wobrock]

Hello you all 👋
Thanks for taking interest in the project!

Sorry we weren't able to tackle this issue yet.
But I'll keep it in mind the next time we work on the library! Hopefully in a couple of weeks/months :)

I'm happy to read it was fixed serendipitously - and if it wasn't, feel free to re-open the issue. We'll have a look at the PR anyway :)