Duy Nguyen writes:
> "read-tree -m" does not invoke diff, does it? If I went with my
> previous approach (modifying unpack-trees to ignore i-t-a entries)
> then this could be a problem, but because unpack-trees is untouched,
> merge operations should not be impacted by this patch.
Theoretically
On Thu, Mar 19, 2015 at 1:00 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ah, wait.
>>
>> I suspect that it all cancels out.
>> ...
>> Now, as you mentioned, there _may_ be codepaths that uses the same
>> definition of "what's in the index" as what diff-cache used to take
>> before you
Junio C Hamano writes:
> Ah, wait.
>
> I suspect that it all cancels out.
> ...
> OK, so I think I can see how the result could work without
> invalidating the cache-tree entry that contains i-t-a entries.
>
> It might be even the right thing to do in general. We can view that
> invalidation a w
Junio C Hamano writes:
> Ah, wait.
>
> I suspect that it all cancels out.
> ...
> Now, as you mentioned, there _may_ be codepaths that uses the same
> definition of "what's in the index" as what diff-cache used to take
> before your patches, and they may be broken by removing the
> invalidation.
Duy Nguyen writes:
> Right. I missed this but I think this is a less important test
> because I added a new test to make sure "diff --cached" ("git
> status" to be exact) outputs the right thing when i-t-a entries
> are present.
OK.
>> If on the other hand the tests show the same result from th
On Wed, Mar 18, 2015 at 12:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Mon, Mar 16, 2015 at 09:05:45AM -0700, Junio C Hamano wrote:
>>> The offending one came from eec3e7e4 (cache-tree: invalidate i-t-a
>>> paths after generating trees, 2012-12-16), which was a fix to an
>>> earlier
Duy Nguyen writes:
> On Mon, Mar 16, 2015 at 09:05:45AM -0700, Junio C Hamano wrote:
>> The offending one came from eec3e7e4 (cache-tree: invalidate i-t-a
>> paths after generating trees, 2012-12-16), which was a fix to an
>> earlier bug where a cache-tree written out of an index with i-t-a
>> en
On Mon, Mar 16, 2015 at 09:05:45AM -0700, Junio C Hamano wrote:
> The offending one came from eec3e7e4 (cache-tree: invalidate i-t-a
> paths after generating trees, 2012-12-16), which was a fix to an
> earlier bug where a cache-tree written out of an index with i-t-a
> entries had incorrect informa
Michael J Gruber writes:
> Nguyễn Thái Ngọc Duy venit, vidit, dixit 16.03.2015 14:56:
>
>> The test "cache-tree invalidates i-t-a paths" is marked failure
>> because I don't think removing "--cached" from "git diff" is the right
>> fix. This test relies on "diff --cached" behavior but the behavio
Nguyễn Thái Ngọc Duy venit, vidit, dixit 16.03.2015 14:56:
> Entries added by "git add -N" are reminder for the user so that they
> don't forget to add them before committing. These entries appear in
> the index even though they are not real. Their presence in the index
> leads to a confusing "git
Entries added by "git add -N" are reminder for the user so that they
don't forget to add them before committing. These entries appear in
the index even though they are not real. Their presence in the index
leads to a confusing "git status" like this:
On branch master
Changes to be committe
11 matches
Mail list logo
