Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 28, 2016, 21:32 UTC
Message-ID: <xmqqk2mtmlu9.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160128070959.GA6815@ecki.hitronhub.home>

Clemens Buchacher <drizzd@aon.at> writes:

Show 11 quoted lines

> On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > I wonder what would break if we ask this question instead:
>> >
>> >     We do not know if the working tree file and the indexed data
>> >     match.  Let's see if "git checkout" of that path would leave the
>> >     same data as what currently is in the working tree file.
>
> If we do this, then git diff should show the diff between
> convert_to_worktree(index state) and the worktree state.

I agree with you that, when ce_compare_data(), i.e. "does the index match the working tree?", says "they match", "git diff" (show me the change to go from the index to the worknig tree) should show empty to be consistent, and for that to happen under the above definition of ce_compare_data(), "git diff" needs to be comparing the data in the index after converting it to the working tree representation with the data in the working tree.

And that unfortunately is a very good reason why this approach should not be taken. "git diff" (show me the change to go from the index to the working tree) is a preview of what we would see in "git diff --cached" (show me the change to go from HEAD to the index) if we did "git add", and it is a preview of what we would see in "git show" (show me the change of what the last commit did) if we did "git commit -a". It is crazy for these latter comparisons to happen in the working tree (aka "smudged") representation of the data, IOW, these two must compare the "clean" representation. It also is crazy for "git diff" to be using different representation from these two. This alone makes the above idea a non-starter X-<.

Besides, I do not think the above approach really solves the issue, either. After "git reset --hard" to have the contents in the index dumped to the working tree, if your core.autocrlf is flipped, "git checkout" of the same path would result in a working tree representation of the data that is different from what you have in the working tree, so we would declare that the working tree is not clean, even though nobody actually touched them in the meantime. This is less of an issue than having data in the index that is inconsistent with the convert_to_git() setting (i.e. eol and clean filter conversion that happens when you "git add"), but it still is fundamentally the same issue.

Oh, bummer, I thought it was a nice approach.