Re: git stash deletes/drops changes of

[John Keeping <john@keeping.me.uk>]

On Fri, May 24, 2013 at 03:42:37PM +0000, Jim Greenleaf wrote:
> John Keeping <john <at> keeping.me.uk> writes:
> 
> > I wonder if this would be better as a file rather than another option to
> > git-update-index.  We already have .git/info/exclude so we could add
> > .git/info/freeze or .git/info/local with the same syntax as the normal
> > .gitignore file.
> 
> .git/info/freeze would be a good solution.
> It would avoid the need to add a new class of files for git-status,
> while keeping a simple, familiar record of all frozen files in a single location.

Now I've thought about it a bit more, I'm not sure this does work.

If an entry in the freeze list means "ignore local changes in this
file", we really want to be talking about local changes relative to some
base.  Otherwise, what happens if the upstream file is radically
altered?  A user probably doesn't want to keep their file unchanged when
this happens.

So we don't just want to store the filename, we want to store the
version of the file that the user chose to ignore.  One way to do this
might be to mark the file as a conflict whenever a change to it comes in
and ignore the freeze file when there is a conflict in the index.  But
then we either need to introduce a new command to manage this state or
some way for the user to perform Git operations ignoring the freeze
file, otherwise how can the user pull down updates?

Perhaps a more user-friendly way to handle this would be to introduce
auto-stash around any operation that will modify a frozen file.  So we
stash the user's (frozen) changes and then apply them after changing the
file.  If there are conflicts then these are marked in the index and
must be resolved, then the unstaged changes in the file are ignored
again.