Re: [PATCH v2 00/15] Towards a more awesome git branch

[Ramkumar Ramachandra <artagnon@gmail.com>]

[-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.