On Tue, Jul 07, 2009 at 01:36:08PM -0400, Daniel Barkalow wrote:
> > # I realize that switching is ill-advised, but I'm
> > # trying to track down a possibly related problem...
> > git config core.autocrlf true
> >
> > # This sometimes produces output and sometimes it doesn't.
> > # Either way rerunning just git-diff always gives the same result
> > # as the first run in this repo.
> > git diff
>
> If git knows the file hasn't been modified, it doesn't produce a diff.
>
> If it doesn't know the file hasn't been modified, it looks at the actual
> contents and it find that the result of reading the disk applying autocrlf
> now doesn't match the contents of the index.
Yes, that was my analysis upon reading the original mail, as well (and I
have been bitten by this before while testing crlf stuff). The same
thing can happen with clean/smudge, I think.
When you set up config that changes how we view worktree files (like
crlf or clean/smudge) and there is already cached stat information in
the index, you really need to invalidate the matching stat information
in the index to get sane results[1]. It might be nice for "git config"
to do this for you, but:
1. You could just as easily be hand-editing the config.
2. It feels wrong from a modularity standpoint. Right now "git
config" doesn't actually care about the semantics of config,
just the syntax. Which makes it exactly equivalent to
hand-editing.
3. It doesn't cover every situation. Files can also be "changed" in
this way by editing .gitattributes, which can be changed manually
or by any number of git commands (like checkout, reset, etc).
So I think automatically detecting this situation would require flags in
the index to say "this stat information is valid only over these
particular settings". And you would want it per-file to avoid having to
re-hash every file when you change the .gitattributes for one file. The
command using the index would check it. But even that might have holes,
I'm afraid -- we don't always look at all of the config in every
command, though perhaps we do for such core functionality.
-Peff
[1] Is there an easy way to do this with update-index? I didn't see one,
and had to resort to "git read-tree HEAD".
--
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