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

From: Clemens Buchacher <drizzd@aon.at>
Date: Jan 30, 2016, 08:13 UTC
Message-ID: <20160130081306.GA2931@ecki.hitronhub.home>
In-Reply-To: <xmqqk2mtmlu9.fsf@gitster.mtv.corp.google.com>

On Thu, Jan 28, 2016 at 01:32:30PM -0800, Junio C Hamano wrote:

Show 7 quoted lines

> Clemens Buchacher <drizzd@aon.at> writes:
> 
> > If we do this, then git diff should show the diff between
> > convert_to_worktree(index state) and the worktree state.
> 
> And that unfortunately is a very good reason why this approach
> should not be taken.

Ok, then let's take a step back. I do not actually care if git diff and friends say the worktree is clean or not. But I know that I did not make any modifications to the worktree, because I just did git reset --hard. And now I want to use commands like cherry-pick and checkout without failure. But they can fail, because they essentially use git diff to check if there are worktree changes, and if so refuse to overwrite them.

So, if the check "Am I allowed to modify the worktree file?", would go the extra mile to also check if the worktree is clean in the sense that convert_to_worktree(index state) matches the worktree. If this is the case, then it is safe to modify the file because it is the committed state, and can be recovered.

Regarding performance impact: We only need to do this extra check if the usual check convert_to_git(work tree) against index state fails, and conversion is in effect.

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

Indeed, if the user configuration changes, then we cannot always detect this (at least if the filter is an external program, and the behavior of that changes). But the user is in control of that, and we can document this limitation.

On the other hand, a user who simply follows an upstream repository by doing git pull all the time, and who does not make changes to their configuration, can still run into this issue, because upstream could change .gitattributes. This part we could actually detect by hashing the attributes for each index entry, and if that changes we re-evaluate the file state.

This is also an issue only if a smudge filter is in place. The eol conversion which only acts in the convert_to_git direction is not affected.