Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > The scenario is this: the repository contains a file that users are > supposed to change, but not commit to (only the super-intelligent inventor > of this scenario is allowed to). As this repository is originally a > subversion one, there is no problem: people just do not switch branches. > > But this guy uses git-svn, so he does switch branches, and to avoid > committing the file by mistake, he marked it assume-unchanged. Only that > a branch switch overwrites the local changes. If it is a problem that a branch switch overwrites the local changes in assume-unchanged file, perhaps that is what this person needs to change? Let's step back a bit and think. Local changes in git do not belong to any particular branch. They belong to the work tree and the index. Hence you (1) can switch from branch A to branch B iff the branches do not have difference in the path with local changes, and (2) have to stash save, switch branches and then stash pop if you have local changes to paths that are different between branches you are switching between. How should assume-unchanged play with this philosophy? I'd say that assume-unchanged is a promise you make git that you won't change these paths, and in return to the promise git will give you faster response by not running lstat on them. Having changes in such paths is your problem and you deserve these chanegs to be lost. At least, that is the interpretation according to the original assume-unchanged semantics. If some paths should not be committed, I'd say it should be handled by a pre commit hook, and not assume-unchanged. Is checking with "diff --cached" on the paths and either erroring out (or better yet resetting the problematic paths in the index) an option? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html