Re: [PATCH 0/6] Improved infrastructure for refname normalization

Michael Haggerty [off-list ref] writes:

The library could do the normalization, but

1. It would probably cost a lot of redundant checks as reference names
pass in and out of the library and back in again

2. Normalization requires copying or overwriting the incoming string, so
each time a refname crosses the library perimeter there might have to be
an extra memory allocation with the associated headaches of dealing with
the ownership of the memory.

3. The library doesn't encapsulate all uses of reference names; for
example, for_each_ref() invokes a callback function with the refname as
an argument.  The callback function is free to do a strcmp() of the
refname (normalized by the library) with some arbitrary string that it
got from the command line.  Either the caller has to do the
normalization itself (i.e., outside of the library) or the library has
to learn how to do every possible filtering operation with refnames.

4. The caller needs to be corrected to pay attention to the normalization
the library did for it. Your code may use a string as a ref and then
create something based on the refname; illustrating with a fictitious
example:

	ref = make_branch_ref("refs/heads/%s", branch_name);
        update_ref(ref, sha1);
        write_log("created branch '%s'", branch_name);

Even though make_branch_ref() may have removed duplicated slashes from the
name in "branch_name" when it computed "ref", the log still will record
unnormalized name.

I think the callers need to be aware of the normalization in practice
anyway for this reason, and a good way forward is to give the callers a
library interface to do so. It might even make sense to make the other
parts of the API _reject_ unnormalized input to catch offending callers.

By the way, does this series introduce new infrastructure features that
can be reused in different areas, such as Hui's "alt_odb path
normalization" patch?

On 09/09/2011 07:57 PM, Junio C Hamano wrote:

By the way, does this series introduce new infrastructure features that
can be reused in different areas, such as Hui's "alt_odb path
normalization" patch?

That code is for normalizing filesystem paths, right?

The rules for normalizing filesystem paths are similar to those for
refnames (except maybe for stripping the leading "/").  But the validity
checks are different, and should be kept separate in case some of the
rules need to be tweaked.  Since I put the code for validity checks and
normalization of refnames in a single function, I don't think it makes
sense to share code.

It would be possible to separate the validity checks from the
normalization, but that would require two scans of the refname.  And I
think it should be considered rather an accident that filesystem names
and refnames have similar conventions (even though there is a strong
historical reason for the similarity); they could some day diverge if,
say, we started adding support for Windows-native paths.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/