Re: [PATCH v2 0/3] Towards a useable git-branch

From: Duy Nguyen <pclouds@gmail.com>
Date: May 29, 2013, 03:22 UTC
Message-ID: <CACsJy8CyocXvjqM5BYgdnhYJPB8wyZ2+qcM9_7EU-WDmw+F5Qw@mail.gmail.com>
In-Reply-To: <CALkWK0k=2NZsbSnxS50w+bux8q9mZh7GZzpCqhTP=2jqyHnBSg@mail.gmail.com>

On Tue, May 28, 2013 at 9:01 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 6 quoted lines

> Also, a couple of minor annoyances:
>
> 1. When f-e-r is invoked with refs/tags, we get stray output.  Atleast
> it doesn't segfault, thanks to your ignore-commit patch.  Maybe
> printing stray output is the right thing to do, as opposed to erroring
> out.

What format did you use?

> 2. %>(*) only works with f-e-r atoms, not with pretty-format atoms.
> This is ofcourse obvious from the implementation, but isn't it a
> little consistent?

It is not. I think it's documented as well as a known implementation limitation. It's not hard to be fixed (we could call format_commit_message again for all entries, this time with a single placeholder, to collect the best width). If anybody does need %>(*)%H to work, we could do it. BTW, the way I implement get_atom_width() is not really optimal. For n lines, we call print_value() in get_atom_width n^2 times. We could cache the calculated width instead and reduce that to n times.

> Should we start off a new pretty-ref-formats document, where we
> explicitly exclude things like %ae (because of the hex overriding
> thing)?  I don't think it's a problem if documented properly.

And this one is doucmented as well, I think. I'd really like to introduce a new --pretty option (or something) that does not accept %xx as a hex notion, so %ae and friends won't be hidden. It's also a good thing for compatibility because currently %H in --format produces %H. After this, %H produces something else. It's unlikely that anybody has done that. But it's even better if we avoid that possibility entirely with a new option. -- Duy