Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

Michael Haggerty writes: > I pushed the fixed commit to branch `submodule-hash` in my fork [1]. If > you'd like me to send it to the mailing list again, please let me know. I was tempted to ask you to send it again, because fetching, comparing and then cherry-picking is a lot more work than just

Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

On 02/10/2017 08:22 PM, Junio C Hamano wrote: > Michael Haggerty writes: >> [...] > > OK, but one thing puzzles me... > >> @@ -1390,27 +1390,6 @@ static struct ref_store *main_ref_store; >> static struct hashmap submodule_ref_stores; >> >> /* >> - * Return the ref_store instance for the spec

Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

Michael Haggerty writes: > There is no need to call read_ref_full() or resolve_gitlink_ref() from > read_loose_refs(), because we already have a ref_store object in hand. > So we can call resolve_ref_recursively() ourselves. Happily, this > unifies the code for the submodule vs. non-submodule cas

[PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

There is no need to call read_ref_full() or resolve_gitlink_ref() from read_loose_refs(), because we already have a ref_store object in hand. So we can call resolve_ref_recursively() ourselves. Happily, this unifies the code for the submodule vs. non-submodule cases. This requires resolve_ref_recu