Phil Hord <hordp@xxxxxxxxx> writes: > I'm not sure this function belongs in transport.c anymore, but > I left it here to minimize conflicts. I think a better home would > be path.c, but maybe not. If someone has a preference, > please let me know. I would think either transport.c or setup.c is more appropriate than path.c; the last one is more of "pathname manipulation utility bag of functions" and does not have much to do with the "Git"-ness of the path they deal with. I am not sure if is_gitfile() is a good name for a global function, though. Also I think the interface to the function should be updated so that the caller can choose to receive the target path when the function returns with positive answer, making "read_gitfile()" unnecessary for such a caller. As a matter of fact, couldn't we somehow unify these two slightly different implementations around the same theme, making is_gitfile() function unnecessary? As far as I can tell, the only difference between these functions is how they fail when given a non-gitfile, and many callers just call read_gitfile() without first asking if it is a gitfile. -- 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