Teach add_cacheinfo to optionally tolerate make_cache_entry failure when
the reason is ENOENT from lstat. Tell it to do so in the call path when
the entry from HEAD is known to be up to date.
This fixes the 'merge-recursive w/ empty work tree - ours has rename'
case in t3030-merge-recursive.
[The copy of my message to the list bounced; trying to resend...]
Hi,
Thanks for flagging this problem, providing a clear testcase, and working on it.
On Fri, Jan 24, 2014 at 7:01 AM, Brad King brad.k...@kitware.com wrote:
Teach add_cacheinfo to optionally tolerate make_cache_entry failure
Brad King brad.k...@kitware.com writes:
Teach add_cacheinfo to optionally tolerate make_cache_entry failure when
the reason is ENOENT from lstat. Tell it to do so in the call path when
the entry from HEAD is known to be up to date.
It somehow feels wrong to force callers of
On 01/24/2014 01:42 PM, Elijah Newren wrote:
While this change does work for the particular new testcase you provided,
there's a more complex case where merge-recursive is failing
I'm not surprised. The change felt much like covering a symptom.
it's just that we want the stat information
On Fri, Jan 24, 2014 at 2:50 PM, Junio C Hamano gits...@pobox.com wrote:
It somehow feels wrong to force callers of make_cache_entry() to be
so intimate with the implementation details of refresh_cache_ent()
[snip]
option bit CE_MATCH_MISSING_OK that asks it to treat a path that is
missing
5 matches
Mail list logo
