I did try to test that hypothesis by editing the filter to be a no-op, but it's possible I go that wrong. My apologies for bugging the list!
On 11 July 2017 at 00:06, Jeff King <p...@peff.net> wrote: > On Tue, Jul 11, 2017 at 06:15:17AM +0200, Torsten Bögershausen wrote: > >> 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 -- Peter
