Re: Weirdness with git change detection

From: Jeff King <peff@peff.net>
Date: Jul 11, 2017, 07:06 UTC
Message-ID: <20170711070618.dq52o67ixvjudafg@sigill.intra.peff.net>
In-Reply-To: <d047a884-b698-c25b-59e9-3a2704f79fb3@web.de>

On Tue, Jul 11, 2017 at 06:15:17AM +0200, Torsten Bögershausen wrote:

Show 17 quoted lines

> On 11/07/17 01:45, Peter Eckersley wrote:
> > I have a local git repo that's in some weird state where changes
> > appear to be detected by "git diff" and prevent operations like "git
> > checkout" from switching branches, but those changes are not removed
> > by a "git reset --hard" or "git stash".
> > 
> > Here's an example of the behaviour, with "git reset --hard" failing to
> > clear a diff in the index:
> > 
> > https://paste.debian.net/975811/
> > 
> > Happy to collect additional debugging information if it's useful.
> > 
> If possible, we need to clone the repo and debug ourselfs - in other
> words, the problem must be reproducible for others.
> 
> It the repo public ?

It looks like https://github.com/AI-metrics/AI-metrics.

I notice it has a .gitattributes file with:

  *.ipynb filter=clean_ipynb

There's a config snippet in the repo with:

  [filter "clean_ipynb"]
    clean = ipynb_drop_output
    smudge = cat

and the drop_output script is included. From the paste we can see that Peter was at commit c464aaa. Checking out that commit and running the script shows that it produces the differences that Git is showing.

The problem is that the currently committed contents do not match the output of the clean filter. So even when "git reset --hard" puts the content from the repository back into the working tree (putting it through the smudge filter, which is a noop), running the clean filter on the result will always have a difference. Either the filter needs to be disabled, or the cleaned contents committed.

-Peff