On Fri, 29 Feb 2008, Paul Mackerras wrote: > > Well, it does, except for --merge, which is perhaps a special case. Well, clearly --merge is a special case, but it probably really shouldn't be. If you want to parse revisions, then --merge should do that. But --merge is really special in that it expands into *both* a revision range *and* a set of files, so it doesn't really work wonderfully well for the trivial kind of parsing that git-rev-parse does. So we certainly *could* just add "--merge" to the list of magic flags that is known about by is_rev_argument(), since that's a trivial one-liner. But that's really only ok for the case where we are supposed to output both revisions *and* flags, and even then it should also suppress the default HEAD generation (although it won't actually hurt, since the revision output from --merge will include HEAD in teh "HEAD...MERGE_HEAD" logic anyway, so with --default always being HEAD in practice..) So yeah, I think git-rev-list has trouble handling --merge sanely the way it is currently written. Linus -- 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
