Thomas Gummerer writes:
> On 08/30, Junio C Hamano wrote:
>> Martin Ågren writes:
>> ...
>> > The above makes me think that once this new function is in good shape,
>> > the commit introducing it could sell it as "this is hard to get right --
>> > let's implement it correctly once and for all".
On 08/30, Junio C Hamano wrote:
> Martin Ågren writes:
>
> > There's a difference in behavior that I'm not sure about: We used
> > to ignore the return value of `refresh_cache()`, i.e. we didn't care
> > whether it had any errors. I have no idea whether that's safe to do --
> > especially as we g
Martin Ågren writes:
> There's a difference in behavior that I'm not sure about: We used
> to ignore the return value of `refresh_cache()`, i.e. we didn't care
> whether it had any errors. I have no idea whether that's safe to do --
> especially as we go on to write the index. So I don't know whe
On Thu, 29 Aug 2019 at 20:28, Thomas Gummerer wrote:
> +int repo_refresh_and_write_index(struct repository *repo,
> +unsigned int refresh_flags,
> +unsigned int write_flags,
> +const struct pathspec *p
Getting the lock for the index, refreshing it and then writing it is a
pattern that happens more than once throughout the codebase. Factor
out the refresh_and_write_cache function from builtin/am.c to
read-cache.c, so it can be re-used in other places in a subsequent
commit.
Note that we return d
5 matches
Mail list logo
