[-CC: Duy, since he has left the community] Junio: since Duy is no longer around to guide us, I will rely on your guidance. Duy Nguyen wrote: > I'm starting to think this is a half-baked solution. It hides > problems, for example commit placeholders should produce empty string, > not the literal placeholders. Why should they produce empty strings? Aren't they equivalent to invalid placeholders? > Doing that from a callback is really > ugly. Why is the callback ugly? I thought it was a great way to extend pretty-formats, without teaching pretty.c about every possible format that callers could ever want. > There's also the problem with sorting and quoting (both only > work with for-each-ref atoms only). Why would I want to sort by reflog-identity-name (or something) in for-each-ref? The sensible fields for sorting in for-each-ref are all for-each-ref atoms. On quoting, I agree. We must move the quoting to pretty.c eventually, but I don't think it is urgent. > A better solution may be improving > pretty.c to the point where it can more or less replace f-e-r's > --format. Why would you want to stuff everything into pretty.c? If any callers wants to implement one specialized format, the only way to do it is to stuff it into the One True pretty-formats? > Even more, I think pretty engine should be easily added to > cat-file (especially --batch), as a generic way to extract > information. Cute theoretical exercise. As usual, I'm not interested: this topic is about making git-branch more awesome, not playing with pretty-formats. -- 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