Fix recent 'unpack_trees()'-related changes breaking 'git stash'

On Sat, 15 Mar 2008, SZEDER G?bor wrote:

Damn, this series has had more subtle issues than I ever expected.

'git stash' creates its saved working tree object with:

        # state of the working tree
        w_tree=$( (
                rm -f "$TMP-index" &&
                cp -p ${GIT_INDEX_FILE-"$GIT_DIR/index"} "$TMP-index" &&
                GIT_INDEX_FILE="$TMP-index" &&
                export GIT_INDEX_FILE &&
                git read-tree -m $i_tree &&
                git add -u &&
                git write-tree &&
                rm -f "$TMP-index"
        ) ) ||
                die "Cannot save the current worktree state"

which creates a new index file with the updates, and writes the tree from that.

We have this logic where we compare the timestamp of the index with the timestamp of the files and we then write them out "smudged" if they are the same, and it basically depends on the fact that the date on the index file is compared with the date encoded in the stat information itself.

And what is going on is:

 - we create a new index file with that "cp". We are careful to preserve 
   the timestamps by using "-p", so this one should be all ok.

 - then we *update* that index by resetting it to the tree with git 
   read-tree, but now we do *not* preserve the timestamp on this new copy 
   any more, even though we copy over all the timestamps on the files that 
   are indexed from the stat information!

Now, we always had that problem when re-writing the index, but we had this clever workaround in the writing part: if the source had racily clean entries, then when we wrote those out (and thus can't depend on the index fiel timestamp showing that they are racily clean any more!), we would smudge them when writing.

IOW, we handle this issue by having write_index() do this:

	for (i = 0; i < entries; i++) {  
		...
		if (is_racy_timestamp(istate, ce))
			ce_smudge_racily_clean_entry(ce);
		..

when writing out entries. And that all took care of it, because now when we wrote the new index, we'd change the timestamp on the index, yes, but we'd smudge the entries we wrote out, so now the resulting index would still show that file as not-up-to-date any more.

But with commit 34110cd4e394e3f92c01a4709689b384c34645d8 ("Make 'unpack_trees()' have a separate source and destination index"), this logic no longer triggers, because we now write out the "result" index, and that one never got its timestamp updated from the source index, so it had lost all that "is_racy_timestamp()" information!

This trivial patch fixes it. It looks trivial, and it's a simple fix, but boy did it take me way too much thinking and explaining to myself to explain why there was a problem in the first place!

The trivial fix is to just copy the index timestamp from the source index into the result index. But we only do this if we *have* a source index, of course, and if we will even bother to use the result.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
 unpack-trees.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)