`format:%>` padding and `git log --graph`

`format:%>` padding and `git log --graph`

[Elliott Cable]

I'm not sure what version the `%>` / `<|` / etc padding showed up in,
but they're truly excellent for building beautiful one-line `git log`
output.

This may be a long-shot, but, unfortunately, these new formats sort of
fall flat in the presence of `git log --graph`: The ‘pad until column’
feature, which when reading the manpage, I desperately hoped
*specifically exists* to replace the normal ‘pad with spaces’ in
situations where `--graph` adds an un-known number of characters to the
start of the line ... unfortunately doesn't seem to work that way.

For instance, here's some truncated output from a basic `--graph`:

    $ git log --graph --abbrev=8 --pretty="tformat:%h %s"
    ...
    * | a4402023 + basic boilerplate for Liability / LiabilityFamily
    * |   32ed6de8 Merge branch 'queueless' into queueless+
    |\ \
    | * \   1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty
    | |\ \
    | | |/
    | | * c8c270ff (!! new doc) Add rationale for basically *all* of the

Here's what `%>|(16)%h` gives me:

    $ git log --graph --abbrev=8 --pretty="tformat:%>|(16)%h %s"
    ...
    * |         a4402023 + basic boilerplate for Liability / LiabilityFa
    * |           32ed6de8 Merge branch 'queueless' into queueless+
    |\ \
    | * \           1e53ea10 (merge misc) Bring in some `bats` fixes, an
    | |\ \
    | | |/
    | | *         c8c270ff (!! new doc) Add rationale for basically *all

Here's something like what I'd *like* to have seen:

    $ git log --graph --abbrev=8 --pretty="tformat:%>|(16)%h %s"
    ...
    * |     a4402023 + basic boilerplate for Liability / LiabilityFamily
    * |     32ed6de8 Merge branch 'queueless' into queueless+
    |\ \
    | * \   1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty
    | * \   1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty
    | |\ \
    | | |/
    | | *   c8c270ff (!! new doc) Add rationale for basically *all* of t

So: Is this nigh-unimplementable? I once [dove into the git-log
source][patch], and I recall the `--graph` code being terrifying; so if
this is difficult to support, I can see why it would be left out.

If I'm off, though, and this is just an oversight, it'd be really neat
to see somebody implement it! (=


⁓ ELLIOTTCABLE — fly safe.
  http://ell.io/tt

   [patch]: <http://article.gmane.org/gmane.comp.version-control.git/226387>

Re: `format:%>` padding and `git log --graph`

[Duy Nguyen]

On Sun, Dec 20, 2015 at 10:41:44AM -0600, Elliott Cable wrote:
> I'm not sure what version the `%>` / `<|` / etc padding showed up in,
> but they're truly excellent for building beautiful one-line `git log`
> output.

Somebody found my code useful!! :-D

> This may be a long-shot, but, unfortunately, these new formats sort of
> fall flat in the presence of `git log --graph`: The ‘pad until column’
> feature, which when reading the manpage, I desperately hoped
> *specifically exists* to replace the normal ‘pad with spaces’ in
> situations where `--graph` adds an un-known number of characters to the
> start of the line ... unfortunately doesn't seem to work that way.
> 
> For instance, here's some truncated output from a basic `--graph`:
> 
>     $ git log --graph --abbrev=8 --pretty="tformat:%h %s"
>     ...
>     * | a4402023 + basic boilerplate for Liability / LiabilityFamily
>     * |   32ed6de8 Merge branch 'queueless' into queueless+
>     |\ \
>     | * \   1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty
>     | |\ \
>     | | |/
>     | | * c8c270ff (!! new doc) Add rationale for basically *all* of the
> 
> Here's what `%>|(16)%h` gives me:
> 
>     $ git log --graph --abbrev=8 --pretty="tformat:%>|(16)%h %s"
>     ...
>     * |         a4402023 + basic boilerplate for Liability / LiabilityFa
>     * |           32ed6de8 Merge branch 'queueless' into queueless+
>     |\ \
>     | * \           1e53ea10 (merge misc) Bring in some `bats` fixes, an
>     | |\ \
>     | | |/
>     | | *         c8c270ff (!! new doc) Add rationale for basically *all
> 
> Here's something like what I'd *like* to have seen:
> 
>     $ git log --graph --abbrev=8 --pretty="tformat:%>|(16)%h %s"
>     ...
>     * |     a4402023 + basic boilerplate for Liability / LiabilityFamily
>     * |     32ed6de8 Merge branch 'queueless' into queueless+
>     |\ \
>     | * \   1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty
>     | * \   1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty
>     | |\ \
>     | | |/
>     | | *   c8c270ff (!! new doc) Add rationale for basically *all* of t
> 
> So: Is this nigh-unimplementable? I once [dove into the git-log
> source][patch], and I recall the `--graph` code being terrifying; so if
> this is difficult to support, I can see why it would be left out.

Yeah graph drawing code does not fit well with other format
specifiers. But it does not look that hard to achieve what you want,
assuming that you specify the fixed width of the first column because
calculating it dynamically can be very expensive and the first column
could fill the entire screen (in merge forests like git.git).

A starting point is something like this, which gives me something like
your output. If you can add a new option to specify the graph width,
then it may be an acceptable solution, I think.

diff --git a/graph.c b/graph.c
index c25a09a..8815984 100644
--- a/graph.c
+++ b/graph.c
@@ -430,6 +430,8 @@ static void graph_update_width(struct git_graph *graph,
 	 * Each column takes up 2 spaces
 	 */
 	graph->width = max_cols * 2;
+	if (graph->width < 20)
+		graph->width = 20;
 }
 
 static void graph_update_columns(struct git_graph *graph)

> If I'm off, though, and this is just an oversight, it'd be really neat
> to see somebody implement it! (=

Nope. Your itch. Your patch ;)
--
Duy

Re: `format:%>` padding and `git log --graph`

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Sun, Dec 20, 2015 at 10:41:44AM -0600, Elliott Cable wrote:
>> I'm not sure what version the `%>` / `<|` / etc padding showed up in,
>> but they're truly excellent for building beautiful one-line `git log`
>> output.
>
> Somebody found my code useful!! :-D

Is this related to

    http://thread.gmane.org/gmane.comp.version-control.git/277710/focus=278326

in any way?  My gut feeling is that, while the original patch itself
breaks existing uses and is not acceptable as-is, its idea is good,
and we are OK with a change like that if it added a new/different
kind of %>|(N) that makes the new behaviour available to those who
want to use it, without negatively affecting existing uses.