Re: git stash deletes/drops changes of
- From
Thomas Rast <trast@inf.ethz.ch>
- Date
- May 23, 2013, 22:56 UTC
- Message-ID
- <87obc15mq5.fsf@linux-k42r.v.cablecom.net>
- In-Reply-To
- <7vd2shcnx7.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 24 quoted lines
> Thomas Rast <trast@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.
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