Dmitry Potapov venit, vidit, dixit 20.04.2009 13:32: > 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 It is very different, and for a good reason, indeed. git's branches really are moving tags. As such, there is no single branch that a commit would be tied to. A commit does not belong to a specific branch; you commit on a branch (usually), and it may be contained in 1 or more branches, of course. Which branch (name) may actually depend on the repository: branch names are not stored in commits, only (backward) relations between commits. This is fundamentally different from what is named "branch" in hg, e.g. There, a commit stores the branch name, which is why you can't delete branches easily. [For me, this is also why hg branches are useless, but I don't want to start flames here - for me they are useless, for others they may still be perfect.] Branches in cvs etc. are much like the latter: You commit on a specific branch, *and* you can't change that later. The branch name at time of creating a commit is stored in the commit. Hg is introducing "bookmarks" now, corresponding to git branches. I think this name describes the nature of git branches very well. > 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