Johannes Schindelin <johannes.schinde...@gmx.de> writes:

> +       ret = add_cache_entry(ce, options);
> +       if (refresh) {
>
> Should we really refresh, even if ret < 0?

As we stopped calling make_cache_entry() with REFRESH flag on, we
can change this not to refresh if we want to, and I think we can
skip refresh without compromising correctness.  But I'd prefer to
see that change as a separate "optimization" step---after all, the
original before this change unconditionally refreshed before even
calling add_cache_entry() and knowing the result of it.

> +               struct cache_entry *nce;
> +
> +               nce = refresh_cache_entry(ce, CE_MATCH_REFRESH | 
> CE_MATCH_IGNORE_MISSING);
>
> This line is overly long, but there is a *lot* of precedent for that in
> merge-recursive.c, unfortunately. So this is just a remark, not an
> objection.

Yes, I had the same objection to the original codebase while I was
touching it.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to