gitk：古怪的历史树 [英] gitk: weird history tree

问题描述

我将一个svn repo移植到git中（使用 https：//使用svn2git www.negativetwenty.net/redmine/projects/show/svn2git ），由于svn不会跟踪合并，我需要手动编辑.git / info / grafts。为此，我启动gitk，在提交消息中搜索术语合并，验证合并提交是否有正确的祖先，并按照相应的方式填充.git / info / grafts。

我遇到的问题是gitk似乎与主分支混淆。它通常显示主从分支分叉并被合并到分支后，实际上它恰恰相反。

为什么它无法理解主人应该尽可能地线性，它应该从它分出来，而不是相反的分支？这是一个gitk问题还是git回购的历史不完整？看来git log --pretty = oneline --graph能够显示正确的行为，所以我认为它可能是一个gitk问题。

我也尝试傻笑和qgit，但都有他们的问题。我发现giggle的树很难理解（例如，合并是水平的，而在qgit和gitk中它们是倾斜的......），并且qgit似乎不显示某些提交（在svn中创建分支的提交在两者中均显示为git提交git log --pretty = oneline --graph和gitk，但不在qgit或giggle中）。

请注意，我在我的gitk --all测试。

所以我的问题是：
- 如何强制gitk将master显示为尽可能线性？理想情况下，左对齐分支从分支中分出，而不是相反。 git log --pretty = oneline --graph似乎是正确的做法，但gitk呢？

谢谢！

编辑：截图链接已死。之前说过：

我已经上传了不同工具的屏幕截图：
git log，gitk，giggle，qgit

看看git log如何显示被合并到trunk中的分支，而gitk
显示了分支中被合并的trunk。 Giggle和qgit显示正确的
合并，但他们经常放弃一些提交（创建分支），所以它的
真的很难手工编辑.git / info / grafts文件。

解决方案

在玩过不同的GUI之后，行为似乎依赖于工具。可悲的是，其中没有很多是可配置的......

我比较喜欢有一个实际发生的树视图， >

我已经解决了gitg（http://trac.novowork.com/gitg/）。看起来相对比较活跃，而且它完全符合我对历史观点的期望。师父是最左边的车道，分支从它分出，并从右边合并到它。我觉得这与我的工作流程一致。另外，我可以显示非活动车道，因此总是显示主控制器，并在最左侧（在首选项窗口中启用/禁用）。
还有一件好事是以拓扑顺序显示历史记录。选中后，gitg会尝试将提交放在一个分支上。如果未选中，它们将按时间顺序显示。

它也可以执行基本的提交和分段操作。

仅限于

缺点我能找到的就是搜索：看来我不能进入sha1sum并找到正确的提交。也许只是一个bug。

关于原始问题（可以按我想要的方式配置gitk？）我仍然不确定这是可能的。可能是一个设计决定......

I'm porting an svn repo to git (using svn2git from https://www.negativetwenty.net/redmine/projects/show/svn2git) and since svn does not track merges, I need to edit .git/info/grafts manually. For this, I launch gitk, search for the term "Merge" in commit messages, verify that the merge commits have the right ancestry and populates .git/info/grafts acordingly.

The issue I'm having is that gitk seems to be confused with the "master" branch. It often shows master being "forked" from a branch and being merged into a branch afterword, when actually it is the opposite.

Why is it unable to understand that master should be "as linear" as possible and it's the branch that should be forked from it, not the opposite? Is it a gitk issue or is the history of the git repo incomplete? It seems "git log --pretty=oneline --graph" is able to show the correct behaviour so I'm thinking it might be a gitk issue.

I also tried giggle and qgit, but both have their problem. I find giggle's tree hard to understand (merges are horizontal for example, while in qgit and gitk they are oblique...) and qgit seems to not show some commits (the commit creating the branch in svn is shown as a git commit in both "git log --pretty=oneline --graph" and gitk, but not in qgit nor giggle).

Note that I use "gitk --all" in my tests.

So my question is: -How can I force gitk to show master as linear as possible? Ideally "left justified" with branches being forked from it, not the opposite. "git log --pretty=oneline --graph" seems to be doing it the right way, but what about gitk?

Thanks!

Edit: Screenshot links are dead. Previously said:

I have uploaded screenshots of the different tools: git log, gitk, giggle, qgit

See how "git log" shows the branch being merged into trunk, while gitk shows trunk being merged in branch. Giggle and qgit shows the right merge, but they often drop some commits (creating branches) so it's really hard to manualy edit the .git/info/grafts file.

解决方案

After playing with different GUI, the behaviour really seems to be tool dependent. Saddly, not many of them are configurable...

I prefer having a tree view of what actually happened compared to an optimized view where everything fits...

I have settled for "gitg" (http://trac.novowork.com/gitg/). Seems relatively active, and it does exactly what I expect from the history view. Master is the left most "lane", branches are forked from it and merged into it from the right. I feel it is consistent with my workflow. Also, I can show "inactive lanes" so master is always shown and on the left-most side (enable/disable in preference window). A nice thing also is the "Show history in topological order". When checked, gitg will try to place commits on a branch together. When unchecked, they will appear in chronological order.

It can also do basic commits and staging.

Only drawback I can find is the search: it seems I cannot enter an sha1sum and find the right commit. Maybe just a bug.

About the original question (can gitk be configured the way I want it?) I'm still not sure it's possible. Probably a design decision...

这篇关于gitk：古怪的历史树的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！