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