Junio C Hamano <gitster@xxxxxxxxx> writes:
> Thomas Rast <trast@xxxxxxxxxxx> 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.
I gather -- from #git -- that it's mostly used for config files, which
have an annoying habit of being different from the repository.
Which is wrong, really. But we still claim that --assume-unchanged is a
solution to it in git-update-index(1).
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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