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
> 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
stat/lstat related optimizations. I'll check next week if nobody beats
me to it.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html