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
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
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
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,
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
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
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
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
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,
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
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
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"
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
>>
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
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
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
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
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
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
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
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
21 matches
Mail list logo