mhagger@xxxxxxxxxxxx writes: > From: Michael Haggerty <mhagger@xxxxxxxxxxxx> > > This is the next installment of the ref-api saga. The main result of > this patch series is to teach git to read loose references one > directory at a time, only when they are needed. > > The first nine commits are not very interesting; they convert > get_ref_dir() and do_for_each_reflog() to use strbufs and to tighten > up their specifications. The search_for_subdir() function extracted > in patch 5 will be useful later. Patch 6 slightly reduces the amount > of work needed to read loose refs from disk, and also changes the > function's API in a way that will be needed later when directories are > read one at a time. > > Patches 10 - 25 mostly switch a lot of code from using ref_dir > pointers to using ref_entry pointers as arguments and return values. > This is important, because ... The earlier parts looked sane, but the ref_dir set of patches looked like merely working around the fact that "struct ref_dir" does not have the name field and you had to upcast it to ref_entry to access the full name. All the places that used to take ref_dir never wanted to get an entry that represents a leaf node (i.e. ref_value kind of ref_entry), but now because you made everybody to take ref_entry, the resulting code is much more error prone and the static type checking done by the compiler helps us much less when updating the code. It can already be seen that you had to sprinkle a lot of assert(flag & REF_DIR), but at runtime in non-debug build that will become no-op and it is not a substitute for the static type checking we used to have. Can't we approach this differently so that we can keep the type safety? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html