On Mon, Feb 6, 2012 at 10:40 PM, Joey Hess <joey@xxxxxxxxxxx> wrote: >> Someone on HN suggested making assume-unchanged files read-only to >> avoid 90% accidentally changing a file without telling git. When >> assume-unchanged bit is cleared, the file is made read-write again. > > That made me think about using assume-unchanged with git-annex since it > already has read-only files. > > But, here's what seems a misfeature... because, well.. assume-unchanged was designed to avoid stat() and nothing else. We are basing a new feature on top of it. > If an assume-unstaged file has > modifications and I git add it, nothing happens. To stage a change, I > have to explicitly git update-index --no-assume-unchanged and only then > git add, and then I need to remember to reset the assume-unstaged bit > when I'm done working on that file for now. Compare with running git mv > on the same file, which does stage the move despite assume-unstaged. (So > does git rm.) This is normal in the lock-based "checkout/edit/checkin" model. mv/rm operates on directory content, which is not "locked - no edit allowed" (in our case --assume-unchanged) in git. But lock-based model does not map really well to git anyway. It does not have the index (which may make things more complicated). Also at index level, git does not really understand directories. I think we could add a protection layer to index, where any changes (including removal) to an index entry are only allowed if the entry is "unlocked" (i.e no assume-unchanged bit). Locked entries are read-only and have assume-unchanged bit set. "git (un)lock" are introduced as new UI. Does that make assume-unchanged friendlier? -- Duy -- 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