git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] graph.c: visual difference on subsequent series

From
Milton Soares Filho <milton.soares.filho@gmail.com>
Date
Oct 25, 2013, 20:49 UTC
Message-ID
<CAPNngRMP29s9gZg9R987yRd2qJ=UuaMWnFphtQdGDRgG_SCxsQ@mail.gmail.com>
In-Reply-To
<xmqqeh79jmtr.fsf@gitster.dls.corp.google.com>
On 25 October 2013 15:13, Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> Milton Soares Filho <milton.soares.filho@gmail.com> writes:
>
>>     git log --graph --oneline
>>     * a1
>>     * a2
>>     x a3
>>     * b1
>>     * b2
>>     x b3
>
> I agree that the problem you are trying to solve is a good thing to
> tackle, and I also agree that marking a root commit differently from
> other commits is one way to solve it, but I am not sure if that is
> the best way.  If the stretches of a's and b's in your history are
> very long, wouldn't it be easier to spot if they are painted in
> different colours, in addition to or instead of marking the roots
> differently [*1*], for example?

Thanks for taking your time reviewing this patch, Junio. I didn't really thought it would get any attention since multiple root-commits is not a very common use-case[1]. However, if most people got excited with git-subtree new features as I did, there is a good chance that multiple root-commits are going to become a common-place in the near future ;-)

That said, I completely agree that painting with different colors would be a much better fix, however I believe that it can be done in a separate changeset by someone that understands better the impact on the rest of the system. Personally, changing only the mark is sufficient because:

a) it'll work on terminal types without coloring support and configurations
    whose explicitly disable it
b) it'll spare myself of running a separate GUI program just
    to spot where each series begin
c) it won't require any visual design skills from a developer (me)
    without a minimal sense for it :-)

By the way, is there a visual or design guideline document for building decorated log graphs? From where comes the inspiration of it?

Show 6 quoted lines
> The change implemented your way will lose other information when a
> root commit is at the boundary, marked as uninteresting, or on the
> left/right side of traversal (when --left-right is requested).  I
> think these pieces of information your patch seems to be losing are
> a lot more relevant than "have we hit the root?", especially in the
> majority of repositories where there is only one root commit.

Nice. I'll try to move the logic into get_revision_mark() and hope the priority on handling it is better suited.

Show 6 quoted lines
> [...]
> and I even suspect that it may be asking for the moon---you may not
> even know what root "a1" (and "b1") came from when you are showing
> these commits without first digging down to the roots and then
> walking the history backwards, which may not be practically
> feasible.
It'd be nice to figure out a test-case to emerge it.
[]s, milton
[1]: In git  repository itself I could find only seven of them (root-commis)
Previous: Junio C HamanoNext: Keshav Kini
Message 3 of 11 in “graph.c: visual difference on subsequent series”
  1. graph.c: visual difference on subsequent seriesMilton Soares Filho, Oct 25, 2013
  2. Junio C HamanoOct 25, 2013
  3. Milton Soares FilhoOct 25, 2013
  4. Keshav KiniOct 26, 2013
  5. Junio C HamanoOct 28, 2013
  6. Keshav KiniOct 28, 2013
  7. Milton Soares FilhoOct 28, 2013
  8. Junio C HamanoOct 28, 2013
  9. graph: give an extra gap after showing root commitJunio C Hamano, Dec 20, 2013
  10. Junio C HamanoDec 20, 2013
  11. Thomas RastJan 3, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.