Re: Interaction between clean/smudge and git status

[Sergio Callegari <sergio.callegari@gmail.com>]

Sergio Callegari <scallegari <at> arces.unibo.it> writes:

> 
> Junio C Hamano <gitster <at> pobox.com> writes:
> 
> 
> > Are you recreating the .zip file in the filter in such a way that a file
> > with the same contents results in byte-to-byte identical .zip file?
> > Otherwise as far as git is concerned you have changed the file in the work
> > tree.
> 
> And here you are right!!!
> I thought that re-zip script was repeatable in behaviour, but it is not
> (probably because things like file dates change when files are unpacked in the
> temporary dir and dates get stored).
> 
> I absolutely overlooked that.
> 

OK, here is a testcase too...

mkdir TEST
git init
# create zip file x.zip
git add x.zip
git commit

In this git commit the clean filter runs.

rm x.zip

git checkout x.zip

or 

git reset --hard

In this checkout the smudge filter runs

git status

It says that x.zip is changed

And yes, in some sense it is changed, because it is a different file than the
one I had before the check in. But no, in some other sense it is not changed,
because it is the file that I have just checked out (it has not been touched
after the checkout).

Not that if I had only the clean filter and not the smudge one, then the same
would have happened. 


So I think that I see your point: if the clean/smudge filters always provide the
same output independently from when they are run, then I get the message about
the changed file at most once, when I check in for the first time the "cleaned"
file.  

And this behaviour makes sense: to say that nothing has changed, git wants
things to be identical.  However it is a bit counterintuitive, because one would
think that something that has just been freshly checked out should not be
considered as changed anyway.

I wonder if this comes from the fact that when git status is run, git compares
the workdir file with the index and the index contains information on the file
as it was before the last checkin.  When filters exist, wouldn't it make sense
to have the index hold information on the files as they are after the checkout?

Sergio