threads / discuss / 41046

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

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

## tl;dr

3 messages between Dec 20, 2015 and Dec 22, 2015.

replies: 2people: 3as markdown or json

Elliott Cable· Dec 20, 2015, 16:41 UTC · lore

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>

Duy Nguyen· Dec 22, 2015, 11:33 UTC · re: Elliott Cable · lore

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

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

Show 47 quoted lines

> 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

Junio C Hamano· Dec 22, 2015, 16:08 UTC · re: Duy Nguyen · lore

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

Duy Nguyen <pclouds@gmail.com> writes:

Show 6 quoted lines

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