Dmitry Potapov venit, vidit, dixit 20.04.2009 15:24: > On Mon, Apr 20, 2009 at 02:07:50PM +0200, Michael J Gruber wrote: >> 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. > > When you create a new commit, it is always belong to _one_ branch and > never to two or more branches. After that you can create a child branch > that will also contain this commit, but it is so in any other VCS. There is nothing in a git commit that ties it to a specific branch; in that sense, it does not "belong" to any. A git branch is a pointer to a commit. That commit and its predecessors are contained in the branch. A commit may be contained in multiple branches, on equal footing: there is no "prime branch". > > Perhaps, the only difference with some other VCSes can be that some VCS > remember name on what branch the commit was initially created, but you > can add that information to Git commit manually if you really want. I don't want it. I want things the git way ;) I just want to emphasize that the branch concept is really different. Emphasizing that helps people who switch from other VCS to git. In other VCS, a commit always belongs to exactly one branch: the one you committed it to, which is stored in the commit. It may be contained in multiple branches, but belongs to the one only. > > But even better approach is to write the branch name only once when > it is merged to the upstream, and Git does that by default. Have you > seen a lot of merge commits like this: > > Merge branch 'bs/maint-1.6.0-tree-walk-prefix' into maint > .... > > though the name of branch does not exist in the upstream repository, > there is no problem to find all commits created on that branch. In fact, > if Git stored those names in the upstream then Git repository would > contain over 2,000 branches already and that number would be only grow. > >> >> 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.] > > I don't see it as fundamentally different. Basically, Hg has some > restriction that does not let you to remove branches that outlived their > usefulness (and thus polluting name space), but the underlying structure > is the same... The underlying structure is the directed graph, with predecessorship being the incidence relation. But what's being discussed here is the various VCS concepts going by the name "branch" (the concept overlaying the graph structure), and those are inherently different. Not being able to delete a branch (without taking all its commits down) is one consequence of a specific concept. > >> >> 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. > > IIRC, it is not. CVS uses numbers which identify each branch. The name > of branch can be changed later, but you cannot change the underlying ID. > You can even remove the name, but branch will remain, and you can follow > it if you know numbers. So, that ID is exactly equivalent to hg's branch name: stored in the commit; just like svn's branches/paths if you follow a standard layout. > Incidentally, you can always follow Git branch > in similar way by using --first-parent option... > >> >> Hg is introducing "bookmarks" now, corresponding to git branches. I >> think this name describes the nature of git branches very well. > > Honestly, the first thing that comes to my mind when I hear bookmarks > in relation to VCS is unannotated tags... The idea of self advancing > bookmarks is really weird... ... but exactly what git's branches are, and what makes them so useful ;) Michael -- 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