The problem with --update is that if overwrites the most recent migration, then it might be used to modify a committed and distributed migration, which is a Bad Thing. The flag would probably be useful to people with my use case, if they trust themselves to use the flag with care and remember to not use it immediately after committing. Was this the reason that you didn't carry --update from South to Django?
Entertainingly, I was about to defend my original proposal, but have just realised that for the last few days while we've been having this conversation, I have not been remembering to run makemigrations before committing, thereby falling into exactly the trap that you predicted my behaviour would produce! Given that --update and my original proposal both have significant dangers if not used properly, my new thought is to write a "safe update migrations" script that used Git to delete all uncommitted migrations and runs makemigrations again. This could give me the best of both worlds - tests that "just work", no build up of many tiny migrations files, and no risk of trashing the committed migration history. I'm coming to think that there's no change that could be made to Django core that would magically fix this without side effects, so perhaps it should be left to the community to create and share scripts that work for each VCS? Bernie :o) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/99a6263a-f720-481e-a9b5-4714eb960019%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
