When I do the pull, under Update result, I get a DIRTYTREE error on a .pyc file..
There are no .pyc files under the path you gave us. But I'm willing to bet you're actually pulling the entire repo, not some random subdirectory underneath it, despite what you say in the question, because that repo does have .pyc files in it.
The problem is that any time you import a .py file, it can rewrite the .pyc file, causing you to get ahead of the master. Once you get ahead of the master in some way that isn't tracked, you will need to merge, rebase, or otherwise clean things up if you want to pull or push. A good git tutorial will explain this.
But the right way to solve this is to just not check in .pyc files. There is almost never a good reason to do so, and plenty of good reasons not to.
There's a great collection of .gitignore
files at https://github.com/github/gitignore (and the appropriate one will even be applied automatically if you use the Github website or client to create a new project). You'll notice that the Python one starts with .py[cod]
. You should do the same.
If you don't want to use a .gitignore
, this just means you can't use the -a
flag anywhere; you'll have to manually manage which files are and are not checked in, and don't manually add the .pyc files.
If you have a good reason to check in the .pyc files, you probably want to prevent Python from updating them except when you choose to do so explicitly. In other words, during normal development, always run with the -B flag or PYTHONDONTWRITEBYTECODE
env variable; then, when you're ready to push, delete the .pyc files and make Python generate them manually.
If you actually want to manage your .pyc files the way you're doing, and it's not an accident, and you just want to know how to manually merge your way out of an unexpected conflict: you do it the same way as with any other conflicting files. For example, stash
, pull
, unstash
will give you the chance to manually pick one .pyc version or the other without screwing up anything else. (You have to know which one you want… but if you don't know that, you don't have a good reason to be managing your .pyc files this way.)