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

Junio C Hamano writes: > The change to t0023 is merely an example that shows that existing > tests assume the convert_to_git() way of defining the dirtyness of > the working tree. It used to be OK to have core.autocrlf set to true, > have LF terminated file on the working

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

Clemens Buchacher writes: > On Mon, Feb 01, 2016 at 10:17:24AM -0800, Junio C Hamano wrote: >> >> Your proposal is to redefine "is the working tree dirty?"; it would >> check if "git checkout -f" would change what is in the working tree. > > I like this definition. Sounds

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

On Mon, Feb 01, 2016 at 10:17:24AM -0800, Junio C Hamano wrote: > > Your proposal is to redefine "is the working tree dirty?"; it would > check if "git checkout -f" would change what is in the working tree. I like this definition. Sounds obviously right. > > Regarding performance impact: We

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

On 2016-02-01 19.17, Junio C Hamano wrote: > Clemens Buchacher writes: [] > > IIRC, autocrlf=true would strip CR at the end of line in to-git > conversion, and would add CR in to-worktree conversion. So some eol > conversion may only act in to-git, but some others do affect both,

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

Clemens Buchacher writes: > 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. You may not, but many existing scripts people have do. > But I know that I did not make > any modifications to the worktree, because I

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

On Thu, Jan 28, 2016 at 01:32:30PM -0800, Junio C Hamano wrote: > Clemens Buchacher 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

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

Clemens Buchacher writes: > On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote: >> Junio C Hamano 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

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

On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote: > Junio C Hamano 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

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

Clemens Buchacher writes: > Coming back to "[PATCH] optionally disable gitattributes": The topics > are related, because they both deal with the situation where the work > tree has files which are not normalized according to gitattributes. But > my patch is more about saying: ok,

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

Junio C Hamano writes: > One way to solve (1) I can think of is to change the definition of > ce_compare_data(), which is called by the code that does not trust > the cached stat data (including but not limited to the Racy Git > codepath). The current semantics of that

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

I think Junio pointed me to this thread from "[PATCH] optionally disable gitattributes". Since I am not sure I am following everything correctly in this thread, allow me to recapitulate what I understood so far. Firstly, I think the racy'ness of t0025 is understood. It is due to the

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

On 01/24, Junio C Hamano wrote: > Junio C Hamano writes: > > > Sorry, but I am confused by all of the above. > > > > We write the thing out with write_entry(), possibly applying smudge > > filters and eol conversion to the "git" representation to create the > > "working tree"

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

Thomas Gummerer writes: > On 01/24, Junio C Hamano wrote: >> To put it differently, if a blob stored at path has CRLF line >> endings and .gitattributes is changed after the fact to say that it >> must have LF line endings, we should treat it as a broken transitory >>

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

Junio C Hamano writes: > I am not saying that we shouldn't have support for users to fix > their repository and get out of this transititory broken state. A > recent work by Torsten Bögershausen to have ls-files report the end > of line convention used in the blob in the

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

On 01/25, Junio C Hamano wrote: > Thomas Gummerer writes: > > > On 01/24, Junio C Hamano wrote: > >> To put it differently, if a blob stored at path has CRLF line > >> endings and .gitattributes is changed after the fact to say that it > >> must have LF line endings, we

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

On 01/22, Jeff King wrote: > On Fri, Jan 22, 2016 at 12:52:55AM -0500, Jeff King wrote: > > > I get a few of the threads failing (in test 4) after 2-3 minutes. The > > "-v" output is pretty unenlightening, though. I don't see anything > > racy-looking in the test unless it is something with

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

Thomas Gummerer writes: > My analysis is in the commit message below. > > --->8--- > Subject: [PATCH] entry: fix up to date marking > > write_entry always marks cache entries up to date when > state->refresh_cache is set. This is however not always accurate, > if

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

Junio C Hamano writes: > Sorry, but I am confused by all of the above. > > We write the thing out with write_entry(), possibly applying smudge > filters and eol conversion to the "git" representation to create the > "working tree" representation in this codepath, right? The

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

On Wed, Jan 20, 2016 at 10:22:16AM +0100, Lars Schneider wrote: > I tested different settings and found that running prove with "-j5" seems to > be > the fastest option for the Travis CI machines. However, I also noticed that > I got more test failures with higher parallelism (Dscho reported

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

On Fri, Jan 22, 2016 at 12:52:55AM -0500, Jeff King wrote: > I get a few of the threads failing (in test 4) after 2-3 minutes. The > "-v" output is pretty unenlightening, though. I don't see anything > racy-looking in the test unless it is something with "read-tree" and > stat mtimes. And

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

Lars Schneider writes: > On 19 Jan 2016, at 21:00, Junio C Hamano wrote: > >> IOW, I am confused by the beginning of the log message that says >> this is taking advantage of "the Travis-CI cache feature". This >> improvement looks to me like using