How to prevent library to keep rebuilding itself with external version control?

All seems very reasonable, but unpractical. I don't think we can implement any of those tricks into our procedures. The whole point of using a versioning system is so we don't have to manually handle it all, as you're suggesting. Because it's so much work to do without it, that we just don't do it. Have you worked in a big project and applied any of those hints? Despite it all, it is the best answer so far ( out of 2 :P ) with some good insights on how it works (though I haven't tested). I think it still doesn't answer the question at all, tho.

Keep in mind Unity was created before distributed VCS became really popular. Unity assumes you're not going to locally commit and uncommit and recommit your changes. Unity thinks that when you change a file, you're gonna change it once. Until recently, rebase-like operations were rare and usually done by hand.

If you use version control for simple operations, Unity will not do unnecessary reimports. Want to fix the root of the problem for you and everybody else? Patch Git so it stores timestamps before a rebase and restores the timestamps afterwards if the file is the same as the old version (if the operation involved undoing/redoing changes).

And I do use the tricks I mentioned. It's not convenient, but it's not slow or overly confusing, given that I understand the issues at work. Furthermore, I consider it utterly necessary, given that a full reimport would waste at least half my work day. A less complex trick: don't use git svn, git rebase, or git reset.

I'm not asking how it works or why it doesn't work. I just want to "prevent library to keep rebuilding itself with external version control".

I would try and patch git so it would store timestamps, if it can be done (no idea if you mean using some trick or actually getting the git source code and hacking into it) and if it would really solve the issue.

As for you're really using those tricks, I may not be reading it right. How big (in bytes) is your project? Are you using mostly git? In what situation you do those manual backups? How many people involved? I really can't see how going through all this problem would be any advantage to waiting the library to rebuild.

The problem isn't only about wasting half the work day. This can easily sum up to a whole work day or weeks. And how much extra work we do trying to avoid that - so it's already taking a lot of time anyway!

The serious and simple answer is to not rewrite history. Don't use Git as an svn frontend, and don't use its history-rewriting features. I use these tricks and more complex ones, but my coworkers don't. I'm helping one other programmer back up his working copy with scripts, but I think for the others, it's more trouble than it's worth. And the repo is SVN (>4GB), but I'm using git-svn as a frontend.

You should add that as your main point on your answer. I agree. Simple and only true unfortunate answer so far is indeed "do not rewrite history". Because Unity can't really handle it. Be it for timestamps or external renames, it's really poor at it, as you said.

For reference, we are using only git (no svn hassle) and just the working dir is already at 12gb. 45gb if you count .git folder.