On Fri, Sep 14, 2012, at 05:39 PM, Johannes Sixt wrote: > Am 9/14/2012 17:27, schrieb Mestnik, Michael J - Eagan, MN - Contractor: > > > >> -----Original Message----- From: Johannes Sixt > >> If EOL conversion or a clean filter was applied during 'git add > >> file', is the version in the worktree suddenly wrong? Of course, > >> not. > >> > >> I would place $Id$ treatment in the same ball park and declare it as > >> a mistake of the editor that it did not remove the now "wrong" SHA1 > >> from $Id:$. > > > > I think the difference here is that git does not *currently change the > > OS's LEF. In this case each commit alters the Id and git is the one > > altering the Id. > > Maybe you misunderstood $Id$? The value you get there is the blob's SHA1, > not the commit's. That is, it does not change on every commit, but only > when the file changes. > > You are right that the value itself is something that is dictated by > git's > database model, but the change logically happens when the editor modifies > the file. Exactly, but the problem is that neither $Id$ nor $Id: deadbeef$ in the work-tree copy of the file are updated with $Id: abacbeef$ after the file's content has changed and has been committed, i.e. after the blob's sha1 has changed. What's worse, even a "git checkout file" does not correct this (because git sees that there's no change to the file compared to the index), you need to "rm file && git checkout file"). If the user has to update $Id$ to match the current sha1 (by remembering to do a more forceful checkout than checkout -f) then one half of that feature is useless. > (My contribution to this thread should be regarded as food for thought. > Personally, I don't mind whether or not and when $Id$ is updated.) > > -- Hannes I think at least we should do a commit.renormalize akin to merge.renormalize if we can't do more for hysterical raisins. But maybe the behavior even has changed during some stat/lstat related optimizations. I'll check next week if nobody beats me to it. Cheers, Michael -- 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