On Mon, Apr 20, 2009 at 03:52:59PM +0200, Michael J Gruber wrote: > 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. Let's take a look at definition of "branch" in different sources: "Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) so that modifications can happen in parallel along both branches." Source: http://en.wikipedia.org/wiki/Branching_(software) "This is the basic concept of a branch—namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history." Source: http://svnbook.red-bean.com/en/1.1/ch04.html#svn-ch-4-sect-1 "When we need to be precise, we will use the word "branch" to mean a line of development, and "branch head" (or just "head") to mean a reference to the most recent commit on a branch." Source: http://www.kernel.org/pub/software/scm/git/docs/v1.6.2.3/user-manual.html#what-is-a-branch It is not that Git commit is not belong to any, but it may appear as being to many branches in shared history. Yet, I don't see anything in definition of branch that would preclude this. > > 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". This is not accurate description. The aforementioned pointer is called "branch head". Branch (in strictly sense) is a line of development, which is defined by its head. A usual commit has one parent; a merge commit can have more than one parent, the first parent defines the branch line while other parents point to branches merged to it. > > 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. I am not sure that it is the case, but actually it depends how you define terms "belong", "contained", "branch", etc... Anyway, no commonly used definition of "branch" implies any idea of exclusiveness ownership of some commit. > >> > >> 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. I think you confuse two different things branch and its name. It is not exactly same things in most VCSes, though you usually use branch name to refer to any branch. In Git (as in CVS and SVN), you can delete branch name without deleting commits. > > 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. No, ID is just ID. You have commit ID in Git too, and you cannot remove it without removing commits, and if you have commit ID of the branch head, you can follow the whole branch line even if it does not have any name. > > > 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 ;) No, Git branches are branches, anyway "bookmarks" is clearly a wrong term. If you do not like "branch", there are many other terms that can be used instead, for example: streams, codelines. > That's because you're thinking of browser bookmarks instead of a real > bookmark. A bookmark in a book would be rather pointless if I couldn't > advance it as I read pages. :-D You can advance them or move backward, but bookmarks do not move on its own. They always point to the place where you put them. That's why this term remembers me more unannotated tags. 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