git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason Pyeron" <jpyeron@pdinc.us>
To: <git@vger.kernel.org>
Cc: "'Philippe Blain'" <levraiphilippeblain@gmail.com>,
	"'Kyle Marek'" <kmarek@pdinc.us>,
	"'Junio C Hamano'" <gitster@pobox.com>
Subject: RE: [PATCH 1/2] revision: Denote root commits with '#'
Date: Sat, 23 Jan 2021 19:02:13 -0500	[thread overview]
Message-ID: <00a801d6f1e4$2b693140$823b93c0$@pdinc.us> (raw)
In-Reply-To: <xmqq7do32p6q.fsf@gitster.c.googlers.com>

> From: Junio C Hamano
> Sent: Saturday, January 23, 2021 6:45 PM
> 
> "Jason Pyeron" writes:
> 
> > One and the same issue. Placing an * directly above another * is the issue.
> 
> OK, I re-read the messages in the thread, and it appears that this
> part from Kyle
> 

Added more of the context below.

> >>>   While root commits are not a special case in the sense that --graph 
> >>>   makes ancestor implications for more than just root commits, root 
> >>>   commits are a special case when we think about interpreting the presence 
> >>>   of hidden lineage in --graph output.
> >>>   
> >>>   Considering one of your examples:
> >>>
> >>>             C
> >>>            /
> >>>           O---A---B
> >>>                    \
> >>>             X---Y---Z
> >>>
> >>>   When graphing C..Z, git produces output like:
> >>>
> >>>   *   0fbb0dc (HEAD -> z) Z
> >>>   |\
> >>>   | * 11be529 (master) B
> >>>   | * 8dd1b85 A
> >>>   * 851a915 Y
> >>>   * 27d3ed0 (x) X
> >>>
> >>>   We cannot tell from the above graph alone that X is a root and A is not.

This was a side track down the left right issue. I personally feel that using the left right features is a buyer beware situation.

> 
> was the only thing that argued that A and X (if the graph drawing
> happend to place an unrelated commit immediately below it) should be
> drawn differently so that you can tell X (root) and A (non root)
> apart.
> 
> And you are saying (and it seems that you have consistently been
> saying) that it is OK to draw A and X (again if other unrelated

I am neither saying or not saying that - partial graph issues are outside of my concerns. Kyle was attempting to reconcile comments on this list about partial graph rendering when his patch was submitted.

> commits were immediately drawn below them) the same way.  So I guess
> all is well.  We do not have to use more 6 different symbols ("{#}"
> to show commit above boundary, three more to show roots) but need to
> introduce only three, if we were to go with the Solution #1 route.

Honestly, I do not care about the <>{}. Whatever makes sense.

> 
> It seems to me that Solution #2 is a special case of Solution #3 ;-)
> They are both direct answers to the "graph drawn incorrectly can
> imply ancestry that does not exist" problem.
> 
> Adding the "--decorate-roots" option that annotates the root commits
> in the "git log" output can still be done, but that is an orthogonal
> issue.  It does solve, together with any one of three options you
> presented, the issue Kyle brought up, I would think.
> 

Yes, adding --decorate-roots to add more wide descriptive text before the message would do it, but it is the worst solution #4.

> Thanks.


  reply	other threads:[~2021-01-24  0:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 18:30 add a blank line when a commit has no parent in log output? Jason Pyeron
2021-01-14 19:29 ` Philippe Blain
2021-01-14 20:44   ` Jason Pyeron
2021-01-17 11:03     ` [PATCH 0/2] Option to modify revision mark for root commits Kyle Marek
2021-01-17 11:03       ` [PATCH 1/2] revision: Denote root commits with '#' Kyle Marek
2021-01-17 21:10         ` Junio C Hamano
2021-01-18  7:56           ` Kyle Marek
2021-01-18 19:15             ` Junio C Hamano
2021-01-18 20:33               ` Junio C Hamano
2021-01-19  7:43                 ` Kyle Marek
2021-01-19 22:10                   ` Junio C Hamano
2021-01-20  3:25                     ` Kyle Marek
2021-01-20  6:47                       ` Junio C Hamano
2021-01-20 15:11                         ` Jason Pyeron
2021-01-20 21:52                           ` Junio C Hamano
2021-01-20 23:01                             ` Jason Pyeron
2021-01-23 18:07                               ` Junio C Hamano
2021-01-23 23:02                                 ` Jason Pyeron
2021-01-23 23:45                                   ` Junio C Hamano
2021-01-24  0:02                                     ` Jason Pyeron [this message]
2021-01-25  7:00                                       ` Junio C Hamano
2021-01-17 22:44         ` Junio C Hamano
2021-01-17 11:03       ` [PATCH 2/2] revision: implement --show-linear-break for --graph Kyle Marek
2021-01-17 22:56         ` Junio C Hamano
2021-01-18  2:09           ` Junio C Hamano
2021-01-18  7:56             ` Kyle Marek
2021-01-18 21:01               ` Junio C Hamano
2021-01-19  7:44                 ` Kyle Marek
2021-01-15  1:12 ` add a blank line when a commit has no parent in log output? 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='00a801d6f1e4$2b693140$823b93c0$@pdinc.us' \
    --to=jpyeron@pdinc.us \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kmarek@pdinc.us \
    --cc=levraiphilippeblain@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).