Thomas Rast <tr...@inf.ethz.ch> writes: > So maybe it would be time to first make up our minds as to what > --assume-unchanged should actually mean: > > * Ignore changes to a tracked file, but treat them as valuable. In > this case we'd have to make sure that failures like git-stash's are > handled properly. > > * Ignore changes to a tracked file, as in "who cares if it was changed". > > * A very specific optimization for users who know what they are doing.
It has always been a promise the user makes to Git that the working tree files that are marked as such will be kept identical to what is in the index (hence there is no need for Git to check if they were modified). And by extension, Git is now free to choose reading from the working tree file when asked to read from blob object recorded in the index for that path, or vice versa, because of that promise. It is not --ignore-changes bit, and has never been. What are the workflows that are helped if we had such a bit? If we need to support them, I think you need a real --ignore-changes bit, not an abuse of --assume-unchanged. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
