Thomas Rast <> 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
More majordomo info at

Reply via email to