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 -- 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
