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. 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. 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... > > 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. 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... 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