Re: Weirdness with git change detection

From: Jeff King <peff@peff.net>
Date: Aug 18, 2017, 11:57 UTC
Message-ID: <20170818115749.vgfcaa44az5upm2s@sigill.intra.peff.net>
In-Reply-To: <fa4b367d-a984-6f42-a2bd-6bfcabed7c2a@grubix.eu>

On Fri, Aug 18, 2017 at 08:56:03AM +0200, Michael J Gruber wrote:

Show 13 quoted lines

> > The idea being that users could run "git lint" if they suspect something
> > funny is going on. I dunno. It may be a dead-end. Most such
> > oddities are better detected and handled during actual git operations if
> > we can. So this would really just be for things that are too expensive
> > to detect in normal operations.
> 
> Typically, that problem arises when you turn a filter on or off at some
> point in your history. Since "attributes" can come from various sources,
> especially the versioned ".gitattributes" file, unversioned per-repo
> .git/info/attributes, and global attributes, "git diff" may apply
> different attributes depending on what you diff (versioned blob, workdir
> file, out-of-tree file).
> [...]

Yeah, I agree that we cannot catch every problematic case (for all the reason you give here). It does seem like a large number of problems people report have to do with checkout of in-tree .gitattributes, though. So my thinking was if we could cover that case, it might help people (even if we leave many problems unnoticed).

But...

Show 5 quoted lines

> I've found that when I decide to use a filter like that, the best
> approach is to either apply it retroactively (filter-branch,
> unversionsed attributes, that is clean all stored blobs) or make a
> commit where I specifically note the switch (versioned .gitattributes
> plus affected blob changes) and what config should go along with it.

One problem is that people need to know to run the lint command. And if they know enough that this is a problem worthy of checking via a linter, then they could perhaps just as easily do the in-tree blob changes.

I say "perhaps" because I don't think it's as easy as running a single "git fix-my-stale-blobs". I wonder if rather than a linter, we ought to just have an option to "git checkout" or something to ignore stat data and re-checkout any entries for which convert_to_working_tree() isn't a noop.

That serves both as a repair tool and as a linter (since running "git diff" on the result would show you what needs to be fixed). It wouldn't solve the user-education problem, but at least it would give a simple solution that could be passed along to users.

I dunno. I don't do line ending conversion, so I don't really run into this issue myself.

-Peff