On Sun, Feb 05, 2012 at 10:25:23PM -0800, Junio C Hamano wrote: >Tom Grennan <tmgrennan@xxxxxxxxx> writes: > >>>I wonder if defaulting to HEAD even makes sense for --points-at. When you >>>are chasing a bug and checked out an old version that originally had >>>problem, "git tag --contains" that defaults to HEAD does have a value. It >>>tells us what releases are potentially contaminated with the buggy commit. >>> >>>But does a similar use case support points-at that defaults to HEAD? >> >> Yes, the usage, "--points-at <object>..." implies that there is no >> default. So, I suppose that NULL more appropriate than "HEAD". > >That's a circular logic. > >The usage could very well say "--points-at <object>" and forbid missing ><object>. I think that would make a lot _more_ sense, because I did not >think of offhand any good reason that --points-at should default to HEAD >to support some common usage, and you also seem to be unable to. Sorry for the miss-communication. I agreed with you - at least I thought I did. So, "--points-at <object>" should forbid a missing <object>. I think I can do so by using defval = (intptr_t)NULL instead of "HEAD", right? -- TomG -- 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