On Sun, Apr 19, 2009 at 05:17:52PM +0200, Johannes Schindelin wrote: > > But it is important to keep in mind that our concept of branches is not > intuitive: > > http://longair.net/blog/2009/04/16/git-fetch-and-merge/ I don't see how our concept of branches is any different from what other version control systems have; but I see why it is so confusing for many people. We define a branch as a line of development (I'm still think it is a pretty good and widely accepted definition of branch), yet when a newcomer runs gitk, what he or she sees is not a line but a graph. Thus anyone looking at a gitk image may ask you: "Where is this line that represents the master branch?" Indeed, it is nearly impossible to see it, but it does not mean this line does not exist. If you run: gitk --first-parent master you can see it. Unfortunately, this line is far from being one straight line drawn in a single color. Thus, not surprisingly that this line cannot be seen in the graph, and here is where the mental image that a new user has about branches (based on different books and diagrams) clashes with the image presented by gitk. No one will ever draw the mainline like this: -o--o--o o--o--o \ / o--o--o but it is not uncommon for gitk to display it in this way, and when this line is intervene with many other branches that forking from and merging to this mainline, all what you can see a complex graph and nothing more. There is one more thing. In Git, all branches are equal and that is a really good feature from the implementation point of view as it makes design simpler and more powerful. But the user point of view, branches are never equal -- there is a _big_ difference between the master and any feature branch. All diagrams explaining branching and merging will show the mainline as a thick straight line running through all history (like a tree trunk) while feature branches fork and merge back to it. That is the mental image that a new user has, and that image clashes with what he or she sees in gitk. BTW, when I started to use Git, I strongly preferred qgit over gitk. Admittedly, gitk displays branches much better when you have a really bushy tree, but straight lines displayed by qgit were much easier to understand and to follow. So, I don't think that we have any conceptual problem here. It may be a visualization problem, but if you have a really complex tree, it may be impossible to present it as nice and simple as artificial diagrams in textbooks. Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html