'git log --graph'或'hg graphlog'如何工作? [英] How does 'git log --graph' or 'hg graphlog' work?

问题描述

我知道Git中的历史记录存储在称为DAG的数据结构中.我听说过DFS，并且知道它有些相关.

I know that the history in Git is stored in a data structure called a DAG. I've heard about DFS and know it's somewhat related.

我很好奇，例如git log --graph或hg graphlog的程序如何绘制历史记录?我一直认为，以这种不错的方式绘制车道和所有东西非常复杂.

I'm curious, how do programs such as git log --graph or hg graphlog draw the history? I always thought it's quite complicated to draw the lanes and everything in such a nice way.

有人可以写一些伪代码演示它吗?

Could someone write some pseudo code that demonstrates it?

注意:我尝试查看Git或hg的代码，但是很难遵循并大致了解正在发生的事情.

note: I tried looking around Git or hg's code but it's very hard to follow and get a general idea of what's going on.

推荐答案

首先，获得一个提交列表(与git rev-list一样)，以及每个提交的父级.内存中保存有列保留列表".

First, one obtains a list of commits (as with git rev-list), and parents of each commit. A "column reservation list" is kept in memory.

然后对于每个提交:

• 如果提交没有为其保留的列，请将其分配给空闲列.分支头就是这样开始的.
• 先根据列保留列表打印树形图形，然后再提交提交消息
• 使用当前提交的第一个父级更新当前列/提交的预留列表条目，以便将父级打印在同一列中.
• 其他父母会获得一个新的免费专栏.
• 如果这是合并，则下一行将尝试将第二个父级链接到期望提交的列(这将导致循环和≡桥")

该示例显示了在aufs2-util上git-forest的输出，并带有一个以上的分支(一个分支).

Example showing output of git-forest on aufs2-util with an extra commit to have more than one branch).

借助前瞻性功能，您可以预测合并点的高度，并在两列之间挤压木材，从而获得更美观的结果.

With lookahead, one can anticipate how far down the merge point will be and squeeze the wood between two columns to give a more aesthetically pleasing result.

这篇关于'git log --graph'或'hg graphlog'如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！