Thread (18 messages) flat view 18 messages, 2 authors, 2016-06-15

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

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:57:40

[-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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help