All of lore.kernel.org
 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 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.