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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]