> -----Original Message----- > From: Junio C Hamano > Sent: Wednesday, January 20, 2021 1:48 AM > > Kyle Marek writes: > > > 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. > > I actually do not see that as a problem. In the past several years, > I've never needed to see "log --graph" output that goes all the way I respect your needs, but they conflict with others' needs, while this enhancement to resolve an ambiguity does not impede your needs and solves others' needs. Please do not impose your exclusive use cases upon everyone. > down to the roots, unless I was playing with a toy repository in I brought this issue up because several repositories in use have this issue. Two repositories immediately at hand have 35k+ and 2500+ commits each. These are repositories used by professionals and contain actual source code. ( I know your "toy repository" tone was not meant as an insult because I read your emails daily, Kyle may not have ) > order to tweak and/or develop a feature in Git that draws the graph. > > Besides, such root commtis in real life projects would not say "X", > but something along the lines of "my very initial commit", which Here is where a fundamental (feature) issue of git rears its ugly head. You cannot fix the commit meta data (e.g. message) after the fact. Humans write the message, and it does not always write a message the is easily recognizable as such, no less easy to search. > would be much more "/<search>" friendly to pagers than "#". Here are some messages: bug 2252 test case (e.g. for tomcat 9 with unpackWARs=false) Add migrate-from-blackfat.sql Initial commit from Create React App parrent pom initial commit Base applet intial Initial commit initial import prod import prod sql import prod import coop/dev import prod CMIS.zip Here we have commits without the word initial, initial misspelled, or in different case. Let's not bike shed this issue. The left/right issues are a great catch from a peer review point of view. I'll ask the following questions, besides the left right and test case issues: What quality issues exists with the patch (e.g. bugs, strategy, etc)? How can the proposed additional features be captured for future implementation? Do we want to continue discussion on option naming? Are there other questions to discuss? Respectfully, Jason Pyeron
