From: Junio C Hamano <gitster@pobox.com>
To: Milton Soares Filho <milton.soares.filho@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] graph.c: visual difference on subsequent series
Date: Fri, 25 Oct 2013 10:13:20 -0700 [thread overview]
Message-ID: <xmqqeh79jmtr.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1382717268-21884-1-git-send-email-milton.soares.filho@gmail.com> (Milton Soares Filho's message of "Fri, 25 Oct 2013 14:07:48 -0200")
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?
> /*
> + * Out-stand parentless commits to enforce non-continuity on subsequent
> + * but separate series
> + */
> + if (graph->commit->parents == NULL) {
> + strbuf_addch(sb, 'x');
> + return;
> + }
> +
> + /*
> * get_revision_mark() handles all other cases without assert()
> */
> strbuf_addstr(sb, get_revision_mark(graph->revs, graph->commit));
It is unclear why the update goes to this function. At the first
glance, I feel that it would be more sensible to add the equivalent
code to get_revision_mark()---we do not have to worry about what
else, other than calling get_revision_mark() and adding it to sb,
would be skipped by the added "return" when we later have to update
this function and add more code after the existing strbuf_addstr().
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.
Thanks.
[Footnote]
*1* Note that I am not saying "the change the patch introduces is
not sufficient and you have to paint the commits in different
colors" here. I myself think it would be a lot more work to do so,
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.
next prev parent reply other threads:[~2013-10-25 17:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 16:07 [PATCH] graph.c: visual difference on subsequent series Milton Soares Filho
2013-10-25 17:13 ` Junio C Hamano [this message]
2013-10-25 20:49 ` Milton Soares Filho
2013-10-26 2:37 ` Keshav Kini
2013-10-28 15:41 ` Junio C Hamano
2013-10-28 16:59 ` Keshav Kini
2013-10-28 17:18 ` Milton Soares Filho
2013-10-28 17:39 ` Junio C Hamano
2013-12-20 20:22 ` [RFH/PATCH] graph: give an extra gap after showing root commit Junio C Hamano
2013-12-20 22:03 ` Junio C Hamano
2014-01-03 20:16 ` Thomas Rast
-- strict thread matches above, loose matches on Subject: below --
2013-10-25 20:51 [PATCH] graph.c: visual difference on subsequent series Milton Soares Filho
2014-11-10 13:33 Antoine Beaupré
2015-07-27 19:37 ` Antoine Beaupré
2015-07-27 20:17 ` Junio C Hamano
2015-09-03 8:04 ` Michael J Gruber
2015-09-03 17:13 ` Junio C Hamano
2015-09-04 14:07 ` Michael J Gruber
2015-09-04 16:08 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqeh79jmtr.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=milton.soares.filho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.