I’ve performed some behavior testing on assume-unchanged and skip-worktree flags and here are the findings:
I haven’t looked into the performance boost yet.
ANALYSIS
It looks like skip-worktree is trying very hard to preserve your local data. But it doesn’t prevent you to get upstream changes if it is safe. Plus git doesn’t reset the flag on pull. But ignoring the ‘reset --hard’ command could become a nasty surprise for a developer.
Assume-unchanged flag could be lost on the pull operation and the local changes inside such files doesn’t seem to be important to git.
Both of the statements above are in correspondence with git mail archive:
http://thread.gmane.org/gmane.comp.version-control.git/146082 - Junio’s (current git maintainer) comment regarding intent of assume-unchanged.
http://osdir.com/ml/git/2009-12/msg01123.html - difference between assume-unchanged and skip-worktree as discussed in git mailing list upon addition of skip-worktree patch.
Actually neither of the flags is intuitive enough. Assume-unchanged assumes that a developer shouldn’t change a file. If a file was changed – than that change is not important. This flag is meant for improving performance for not-changing folders like SDKs. But if the promise is broken and a file is actually changed, git reverts the flag to reflect the reality. Probably it’s ok to have some inconsistent flags in generally not-meant-to-be-changed folders. On the other hand skip-worktree is useful when you instruct git not to touch a specific file ever. That is useful for an already tracked config file. Upstream main repository hosts some production-ready config but you would like to change some settings in the config to be able to do some local testing. And you don’t want to accidentally check the changes in such file to affect the production config. In that case skip-worktree makes perfect scene.
