Re: git stash deletes/drops changes of

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@inf.ethz.ch> writes:

>> 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).

That is doubly wrong, then ;-)

How would we want to proceed from here?  The obvious first step
would be to fix the documentation, but then what is next?

Thinking aloud, ignoring that "Which is wrong, really" part in your
message and assuming that we do want to support --ignore-changes....

Can the way we handle "--ignore-changes" files be a strict superset
(or is it subset?) of what we currently do for "--assume-unchanged"?
That is, if we "fix"^Wchange the behaviour of "--assume-unchanged"
to be less aggressive in assuming that the user kept his promise,
can we get "--ignore-changes" without losing much of the performance
benefit of "--assume-unchanged" the people who originally wanted to
have that feature have enjoyed for all these years?

If you are working on a project with a large working tree, by
marking paths in one directory you do not care about (and do not
use) with the --assume-unchanged bit, checking out another branch
can be done without inspecting if there are uncommitted changes in
the part of the working tree that may be clobbered with the
different version of the file in the other branch.  That has to go
for "--ignore-changes", for example.  Are there others that need to
suffer?

If so, these two have to be done as totally independent options, but
if -ignore-changes can be just a slightly less agressive
-assume-unchanged, we could "fix" "--assume-unchanged", introduce
"--ignore-changes" as a synonym and be done with it.  I highly doubt
that is doable.

The only sensible way forward, it seems to me, is introduce a proper
"--ignore-changes" that is independent from "--assume-unchanged".
What does "--ignore-changes" really mean?

The end user does not want to see changes to a config file when he
runs "git status" and "git diff".  I think "git commit -a" would
ignore the local changes to the configuration file as a natural
consequence if we teach "git status" to ignore paths marked with the
"--ignore-changes" bit.  But the same "git diff" (between the index
and the working tree) logic is internally used to decide if a path
has local changes when running "git checkout" to check out another
branch, "git rebase" to see if there are local changes, etc. and the
user do want to view the paths as modified.

I am not so sure if there is a clear semantics other than
an unactionable blanket statement "ignore local changes".