tag:blogger.com,1999:blog-3669809752172683097.post2731731820320775769..comments2024-02-08T04:04:28.385-08:00Comments on Cyclopedia Square: Git Branches Are Not BranchesBryanhttp://www.blogger.com/profile/11394436715172971234noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-3669809752172683097.post-17952906867642816652013-07-03T03:31:49.492-07:002013-07-03T03:31:49.492-07:00I work on "development topics", or a &qu...I work on "development topics", or a "main line". If there wasn't a VCS to begin with, I wouldn't even talk about branches at all.<br />You coined the more natural term "development path", too. Many other VCS actually used these terms instead of "branch". There was not only CVS and SVN out there.<br /><br />I also think that git branches are entirely <b>not</b> consistent with all the other systems, because a branch in git (or better yet: the consistent meaning of a branch - compared to other systems - for a set of commits belonging to that branch) will not go away even when the branch pointer is deleted. You can't distinguish branches anymore once the pointer got deleted, though. Sometimes you can't even do it with the pointers at all. Other systems don't do this, and wouldn't understand it as branch to begin with.<br /><br />It is arguable if this new workflow is good or not, but it is definitely not consistent with other systems, and certainly not with the meaning of the term "branch" in traditional systems. Everybody believing this will soon get hit by the internals and wonder why it behaves the way it does.<br /><br />So in light of this, the term "bookmark" is simply better. Or to put it more into another beloved git (culture) term: <b>superior</b>.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-79612958589661944072013-07-02T22:16:22.573-07:002013-07-02T22:16:22.573-07:00The implementation details are certainly interesti...The implementation details are certainly interesting and useful to know, but when it comes to the terminology itself, Git's use of the term "branch" <b>is</b> entirely consistent with all the VCS systems I've used -- branching is a way of working on divergent development paths, so that developers can work on multiple different independent versions of the code base, which may or may not be subsequently merged back together.<br /><br />The fact that git doesn't require you to clone the entire repository to create a branch, or that in some instances a merge can be simplified using the "fast-forward" behaviour (which is optional) doesn't seem entirely relevant here? The approaches taken by Git vs Subversion may be worlds apart in detail, but they're both providing a solution to the same problem, which they call by the same name.<br /><br />So while the word "branch" might not be the best description of what is happening inside git, it's a very reasonable way to describe the standard purpose to which these mechanisms are put. I certainly work on development "branches" not development "bookmarks", so I'm not convinced that the terminology is bad.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-70739393813705123172013-07-01T17:08:31.490-07:002013-07-01T17:08:31.490-07:00Peter, you say deleting a branch does delete the d...Peter, you say deleting a branch does delete the data (eventually). If I create a branch, make some commits, merge the branch, and then "delete" it, do the commits that are on the branch (in the DAG sense of the word) get garbage collected?<br /><br />They don't right? They can't, because the merge commit is based on both those parent commits. I know, it's the same with hard links in a filesystem, right? Because the commits still have something referring to them (the merge commit) they won't get deleted, just like a file that still has hard links to it won't get deleted.<br /><br />So tell me, how often do people use hard links? How often do people use git branches?<br /><br />P.S. Thanks for pointing out the filesystem similarities, that is a very interesting insight into why git works the way it does.Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-887844936873826052013-07-01T16:41:35.379-07:002013-07-01T16:41:35.379-07:00Peter: indeed; "automatically moving bookmark...Peter: indeed; "automatically moving bookmarks" is precisely what a branch is in git. Each 'branch' is just a HEAD commit reference, stored in a file under .git/refs/heads (containing the hash for the relevant 'bookmark' commit). When the branch is modified, that file is updated. (And of course a Tag is a 'bookmark' which will never change.)<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-83568891196140867162013-07-01T14:06:31.500-07:002013-07-01T14:06:31.500-07:00Somehow the file abstraction in UNIX works a lot b...Somehow the file abstraction in UNIX works a lot better than the branch abstraction in git. Much less leaky. A version control tool's data structure stores and conveys a lot more meaning than a filesystem's data structure.Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-72906652720123067832013-07-01T13:57:00.868-07:002013-07-01T13:57:00.868-07:00Git comes from a Unix file system background (argu...Git comes from a Unix file system background (arguably). If you look at file systems in the way you propose, a file on a Unix system isn't really a file, it's just a "bookmark" to an inode. That's not wrong, but it's just not a practical terminology.<br /><br />Also, removing a branch in Git does remove the data. Not immediately, just like removing a "file" doesn't remove the file's data. But it will be cleaned up if it's not reachable from any other "bookmark".<br /><br />I would also consider that Git branches are kind of automatically moving bookmarks. A better analogy for a bookmark is a tag.Anonymoushttps://www.blogger.com/profile/02849480732923051923noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-56799714425630859662013-07-01T08:55:37.474-07:002013-07-01T08:55:37.474-07:00I might have toned down the rhetoric a little, but...I might have toned down the rhetoric a little, but you make a good point about fast-forward merges. :-)<br /><br />That was another point of confusion for me. Why do people say "merge" when the history is all linear? Ah, because it's not actually a merge, it's just moving those labels around.Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-52147396918628676232013-07-01T01:08:29.672-07:002013-07-01T01:08:29.672-07:00Only that they do not have to be branches at all.
...Only that they do not have to be branches at all.<br /><br />o-o-master-o-mywork<br /><br />Where is the branch here? Topologically, there is none. "master" is just a bookmark on a certain commit in my perfectly linear history. If I switch "branches" here, I actually switch between 2 versions in the same linear ancestry.<br /><br />With Git, it gets even more complicated. You have to "merge" mywork into master in order to get the changes pushed to the remote. Just all that the "merge" is doing is "fast-forwarding" the master pointer to mywork.<br /><br />Linus (and later Junio) invented many terms like that just for the heck of it. And often did so deliberately in total contrast to established terminology, because they "looked at what CVS did and made the exact opposite". Engineering by arrogance, that is. And the current UI catastrophe of Git is a direct result of that.<br /><br />It is just funny how many DVCS proponents of the early days called SVN fans "brain-damaged", when a similar Stockholm-syndrome is clearly observable with Git fans these days.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-20918913078481743902013-06-30T13:07:46.375-07:002013-06-30T13:07:46.375-07:00I see why you would say git branch == bookmark, bu...I see why you would say git branch == bookmark, but really, what they are most used for is swapping the working tree among different branches.aaphttps://www.blogger.com/profile/01316081883197172654noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-60435887610219938682013-06-29T09:21:40.428-07:002013-06-29T09:21:40.428-07:00Being more familiar with Mercurial I hadn't th...Being more familiar with Mercurial I hadn't thought about it as much, but you are correct, "branch" in mercurial is an overloaded term as well. I usually substitute "named branch" in my head when I read "branch" in a mercurial context (color doesn't work for me).<br /><br />So, to summaryize:<br /><br />git branch == bookmark<br /><br />mecurial branch == named-branch<br /><br />Mercurial did get one thing right (a somewhat recent addition):<br /><br />mercurial bookmark == bookmarkBryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-12983323723489432122013-06-29T04:30:32.872-07:002013-06-29T04:30:32.872-07:00Actually Mercurial also messed up the branch termi...Actually Mercurial also messed up the branch terminology.<br /><br />If you use the command "hg branch", it will just mark your working copy with a stamp, or better yet: a color. A commit of this working copy will then have the color. That's all.<br /><br />Many confusions of why a Mercurial named-branch can have many heads, could be discontinous, has global namespace, etc. come from that technological background: named-branches are just node-colors, nothing more.<br /><br />IMHO, DVCS should not talk about commands creating or deleting/moving branches at all, because a branch in the usual meaning is just a commit with 2 or more children. And this happens implicitly in both Mercurial and Git.<br /><br />Bookmark is the best term for what Git branches are, and colors is the best for what Mercurial branches are. But it is unlikely to see these mistakes fixed (and evangelists will of course vigorously debate whether it is a mistake or not), because of backwards compatibility.<br /><br />Perhaps the next generation of version control tools will get it right...Anonymousnoreply@blogger.com