On Tue, Jul 03, 2012 at 01:21:36PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > What happens if I set multiple flags? One or more of them will be > > ignored (you _could_ try to establish a hierarchy, for example that > > TREEISH is a superset of COMMITISH, but that could not handle the *_only > > cases, which really are mutually exclusive). IOW, I think these are not > > really flags but rather enum elements. > > Yes, I was aware of that. I counted five useful ones (see the new > ones near the tip of 'pu') but there may be others, so you cannot > fit in 2 bits and would need 3 bits. I am not worried about the bits, only that adding a new 'enum disambiguation_type' parameter would be a pain, as most places would just be passing 0. But it would enforce the mutual exclusion at compile time. > I actually am thinking to move these bit assignments backto > sha1_name.c and make them private, as get_sha1_tree() and friends > are easier to understand public interface functions than > get_sha1_typish(... I_WANT_COMMIT|I_WANT_COMMITTISH|...). Yeah, I think that might be sane. If you really wanted to be flexible anyway, you would let the caller pass a custom disambiguation function (which I suspect describe would want for handling the "must come at this point in the history" rule). -Peff -- 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