{"thread":{"id":"4182","subject":"[RFD] Git glossary: 'branch' and 'head' description","startedAt":"2006-05-17T11:37:19Z","lastAt":"2006-05-21T08:30:23Z","messageCount":13,"participants":["Jakub Narebski","Junio C Hamano","David Kågedal","Shawn Pearce","Daniel Barkalow","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20135","messageId":"e4f1ta$e07$1@sea.gmane.org","threadId":"4182","inReplyTo":null,"subject":"[RFD] Git glossary: 'branch' and 'head' description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-17T11:37:19Z","receivedAt":"2006-05-17T11:37:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"In #git channel somebody asked about 'branches' and 'heads' and was referred\nto the glossary. I had taken then a look at appropriate glossary entries.\n\nIn 'Documentation/glossary.txt' we have:\n----  \nbranch::\n        A non-cyclical graph of revisions, i.e. the complete history of\n        a particular revision, which is called the branch head. The\n        branch heads are stored in `$GIT_DIR/refs/heads/`.\n\nhead::\n        The top of a branch. It contains a ref to the corresponding\n        commit object.\n\nhead ref::\n        A ref pointing to a head. Often, this is abbreviated to \"head\".\n        Head refs are stored in `$GIT_DIR/refs/heads/`.\n\nrevision::\n        A particular state of files and directories which was stored in\n        the object database. It is referenced by a commit object.\n---- \n\nIt is just me or the glossary entry for `branch` is unnecessary \ncomplicated? \n\nLet's take a look at other definitions:\n\n  In software engineering, 'branch' is a separate line of development, which \n  among others allows development on a project to diverge in two directions, \n  such as a stable and a development version. (WikiPedia:Branch)\n\n  In the CVS team development environment, a separate line of development \n  where changes can be isolated. When a programmer changes files on \n  a branch, those changes do not appear on the main trunk \n  or other branches. (cvs.info)\n\nSo from the user's point of view, 'branch' is simply _named line of\ndevelopment_. Refer to topic and tracking branches.\n\n>From the point of view of commit, current branch (or rather branch\nhead/branch tip) is the place where we attach current development line\n(current commit has current head as parent, and head is advanced to the\ncurrent commit), something akin to 'top' pointer for stack implemented as\nlinked list.\n\nONLY from the point of view of HISTORY, branch define \"non-cyclical graph of\nrevisions, i.e. the complete history of a particular revision, which is\ncalled the branch head.\" Merges somewhat obscure the branches (as history),\nunless for example we assume that first parent is on the same branch, or\nuse note header to mark appropriate parent/commit. Also git does not record\nwhere branch started... New branch commit logging proposal, and per-branch\nconfiguration should help with these issues.\n\n\nNo concrete proposal for git glossary update...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20160","messageId":"7viro4ecao.fsf@assigned-by-dhcp.cox.net","threadId":"4182","inReplyTo":"e4f1ta$e07$1@sea.gmane.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T18:28:15Z","receivedAt":"2006-05-17T18:28:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> In #git channel somebody asked about 'branches' and 'heads' and was referred\n> to the glossary. I had taken then a look at appropriate glossary entries.\n>\n> In 'Documentation/glossary.txt' we have:\n> ----  \n> branch::\n>         A non-cyclical graph of revisions, i.e. the complete history of\n>         a particular revision, which is called the branch head. The\n>         branch heads are stored in `$GIT_DIR/refs/heads/`.\n>\n> head::\n>         The top of a branch. It contains a ref to the corresponding\n>         commit object.\n>\n> head ref::\n>         A ref pointing to a head. Often, this is abbreviated to \"head\".\n>         Head refs are stored in `$GIT_DIR/refs/heads/`.\n>\n> revision::\n>         A particular state of files and directories which was stored in\n>         the object database. It is referenced by a commit object.\n> ---- \n>\n> It is just me or the glossary entry for `branch` is unnecessary \n> complicated? \n\nWhile technically it might be correct, the above description for\n\"branch\" completely misses the point in the context of other\nentries.  I do not recall when this entry was first written, but\nI suspect it probably predates other entries that talk about the\nsame thing.\n\nAs you point out it talks primarily about the mesh of all\npossible histories (i.e commit DAG), without talking much about\nwhat \"branch\" means and what role \"branch\" plays.\n\nI cannot easily do a glossary entry to describe that specific\nterm, but maybe somebody else can split the following up and\nparaphrase.\n\n        A project history is born by recording a particular\n        state (\"revision\") as a root commit, and built up by\n        recording subsequent states (\"revisions\") on top of the\n        previous commits.  Thus, a group of commits connected by\n        their parent fields form a directed acyclic graph\n        (\"DAG\").  Often this linkage between commits by their\n        parent fields is called \"ancestry chain\", and a commit\n        that has another commit in its \"parent\" field is called\n        a \"child commit\" of the latter.\n\n        There can be multiple root commits in the history of a\n        project.  In other words, projects born independently\n        can later be glued together to become a single project.\n\n        The history is grown by building on top of previous\n        commits, and by the nature of distributed development,\n        many lineages of histories are grown simultaneously.\n        Each lineage is called a \"branch\".\n\n        A commit that can be reached by following the ancestry\n        chain from a commit that is \"on the branch\" is also \"on\n        the branch\", and a commit that cannot be reached by\n        following the ancestry chain from any commit that is \"on\n        the branch\" is not \"on the branch\".  The commit that\n        bootstraps this recursive definition of \"on the branch\"\n        is called its \"branch head\", the \"tip of the branch\", or\n        the \"top commit\".  In other words, it is topologically\n        the latest commit on the branch.\n\n\tThe above does not mean the top commit of a branch does\n\tnot have any child commit in the global project\n\thistories.  It just means that these children are not on\n\tthe branch; they may be on some other branches, forked\n\tfrom it.  To create a branch whose \"on the branch\"\n\tcommits are strict superset of \"on the branch\" commits\n\tof another branch is called \"forking\" the branch.\n"},{"id":"20170","messageId":"e4fsla$oth$1@sea.gmane.org","threadId":"4182","inReplyTo":"7viro4ecao.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-17T19:13:51Z","receivedAt":"2006-05-17T19:13:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n\n>> In 'Documentation/glossary.txt' we have:\n>> ----  \n>> branch::\n>>         A non-cyclical graph of revisions, i.e. the complete history of\n>>         a particular revision, which is called the branch head. The\n>>         branch heads are stored in `$GIT_DIR/refs/heads/`.\n>> ---- \n> \n> While technically it might be correct, the above description for\n> \"branch\" completely misses the point in the context of other\n> entries.  I do not recall when this entry was first written, but\n> I suspect it probably predates other entries that talk about the\n> same thing.\n\n[cut long description]\n\nThe description you gave is nice, but it belongs in Tutorial rather than in\nGlossary. Additionally it mainly deals with branches fron the 'revision\nhistory' point of view, although the 'commit' point of view can also be\nseen.\n\nGlossary entry should be short, up to the point, and encompass al three\npoints of view: \n\n a.) conceptual point of view, i.e. \"branch is separate line of\ndevelopment\" (be it stable or development direction, introducing new\nfeature aka. 'topic', or following aka. 'tracking' changes in other\nrepository),\n\n b) revision history point of view, i.e. \"on branch means, roughly,\nreachable from branch head aka. tip\", or \"branch is lineage of history of\nproject\" (somewhat mudded by merges[*1*], fork points[*2*] and multiple\nroots). This is what current glossary entry tries to present,\n\n c) commit point of view, i.e. \"branch tip is where we do commit\nchanges\" (branch tip is [one of] parent(s) of current commit, and branch\ntip is advanced to new commit).\n\n\n[*1*] Problem with merges:\n   \n   ---.---.---A-\\--.---.---.---B-- branch1\n                 \\\n   ---.---.---C---*D---.---.---E-- branch2   \n   \nDoes A belong to branch2? It is one of parents of commit D. We can assume\nthat only first parent in merges continues branch. But what if we have the\nfollowing history:\n\n   ---.---.---A-\\  <---- there was branch1 here\n                 \\\n   ---.---.---C---*D---.---.---E-- branch2 \n\nTo which branch belongs A then?\n\n\n[*2*] Problem with fork point\n\n           /--1---2---3-- maintenance/stable/fixes branch  \n          /\n  ---A---B----C---D---E-- master/development branch\n\nFollowing the ancestry chain we get that commit A is on branch 'maint' (it\nis also on branch 'master'); git does not record fork points. Perhaps the\nbranch logging and/or per branch configuration could be used to resolve\nthis issue.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20179","messageId":"7v8xp0ctlf.fsf@assigned-by-dhcp.cox.net","threadId":"4182","inReplyTo":"e4fsla$oth$1@sea.gmane.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-17T19:57:32Z","receivedAt":"2006-05-17T19:57:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> [cut long description]\n>\n> The description you gave is nice, but it belongs in Tutorial rather than in\n> Glossary.\n\nI suspect I was not clear enough for you when I said:\n\n        I cannot easily do a glossary entry to describe that specific\n        term, but maybe somebody else can split the following up and\n        paraphrase.\n"},{"id":"20180","messageId":"e4fvnu$4ar$1@sea.gmane.org","threadId":"4182","inReplyTo":"7v8xp0ctlf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-17T20:06:28Z","receivedAt":"2006-05-17T20:06:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n>> [cut long description]\n>>\n>> The description you gave is nice, but it belongs in Tutorial rather than \n>> in the Glossary.\n> \n> I suspect I was not clear enough for you when I said:\n> \n>         I cannot easily do a glossary entry to describe that specific\n>         term, but maybe somebody else can split the following up and\n>         paraphrase.\n\nMaybe I should say that the description you gave is a nice source for\neventual glossary entry, but I feel that as the whole is worth preserving\nin some tutorial text.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20277","messageId":"87y7wyv72m.fsf@morpheus.hq.vtech","threadId":"4182","inReplyTo":"e4f1ta$e07$1@sea.gmane.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2006-05-19T06:53:37Z","receivedAt":"2006-05-19T06:53:37Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> In #git channel somebody asked about 'branches' and 'heads' and was referred\n> to the glossary. I had taken then a look at appropriate glossary entries.\n>\n> In 'Documentation/glossary.txt' we have:\n> ----  \n> branch::\n>         A non-cyclical graph of revisions, i.e. the complete history of\n>         a particular revision, which is called the branch head. The\n>         branch heads are stored in `$GIT_DIR/refs/heads/`.\n\n[...]\n\n> It is just me or the glossary entry for `branch` is unnecessary \n> complicated? \n>\n> Let's take a look at other definitions:\n>\n>   In software engineering, 'branch' is a separate line of development, which \n>   among others allows development on a project to diverge in two directions, \n>   such as a stable and a development version. (WikiPedia:Branch)\n>\n>   In the CVS team development environment, a separate line of development \n>   where changes can be isolated. When a programmer changes files on \n>   a branch, those changes do not appear on the main trunk \n>   or other branches. (cvs.info)\n>\n> So from the user's point of view, 'branch' is simply _named line of\n> development_. Refer to topic and tracking branches.\n\nBut the definition of 'branch' in git is quite different from the\ndefinition in CVS or many other systems.  It CVS, each revision\n(commit) belongs to a branch, and the branch is a linear sequence of\nrevisions, not a full DAG.  In git, a commit doesn't really \"belong\"\nin any specific branch.\n\nSo, while it makes sense to describe branches as \"lines of\ndevelopment\" in general terms, it is also important to note the\nspecific meaning of 'branch' in the context of git; i.e. as the\nhistory of a single head commit.\n\nI noticed that some of this seems to be changing slightly with the\nintroduction of branch logs, but I don't know how those are supposed\nto be used yet.\n\n-- \nDavid Kågedal\n"},{"id":"20286","messageId":"20060519092136.GN22257@spearce.org","threadId":"4182","inReplyTo":"87y7wyv72m.fsf@morpheus.hq.vtech","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-19T09:21:36Z","receivedAt":"2006-05-19T09:21:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David K?gedal <davidk@lysator.liu.se> wrote:\n> I noticed that some of this seems to be changing slightly with the\n> introduction of branch logs, but I don't know how those are supposed\n> to be used yet.\n\n\t$ git commit -a\n\t$ git pull . some/other-tag\n\t# go to lunch\n\t$ git pull . some/bad-stuff\n\t$ git commit -a\n\t# go home\n\t$ test...\n\t# realize this is all bad\n\t$ git reset --hard \"master@{yesterday}\"\n\n:-)\n\nIts really only useful for recording the history of your ref's state,\nso you can 'undo' a bad merge that you might have done a few days\nago but not realized was bad until now.\n\n-- \nShawn.\n"},{"id":"20311","messageId":"Pine.LNX.4.64.0605192006400.6713@iabervon.org","threadId":"4182","inReplyTo":"20060519092136.GN22257@spearce.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-05-20T00:28:22Z","receivedAt":"2006-05-20T00:28:22Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 19 May 2006, Shawn Pearce wrote:\n\n> David K?gedal <davidk@lysator.liu.se> wrote:\n> > I noticed that some of this seems to be changing slightly with the\n> > introduction of branch logs, but I don't know how those are supposed\n> > to be used yet.\n> \n> \t$ git commit -a\n> \t$ git pull . some/other-tag\n> \t# go to lunch\n> \t$ git pull . some/bad-stuff\n> \t$ git commit -a\n> \t# go home\n> \t$ test...\n> \t# realize this is all bad\n> \t$ git reset --hard \"master@{yesterday}\"\n> \n> :-)\n> \n> Its really only useful for recording the history of your ref's state,\n> so you can 'undo' a bad merge that you might have done a few days\n> ago but not realized was bad until now.\n\nI still think it's useful for presenting a local view of how things have \nchanged. I.e.:\n\n$ git pull . stuff\n# Notice that the diffstat is exciting\n# What did I just get?\n$ git log master@{5 minutes ago}..master\n\nThis is about the only easy way to find out that the fast-forward you just \ndid included merging a line which contains a commit from several weeks \nago. (Because the \"before\" state isn't easily accessible for a \nfast-forward, and the date of the old commit puts it way back in a \ndate-ordered log.)\n\nI still think that a local changelog, which groups the additions due to \neach logged value, would be a useful way of viewing the history in a way \nthat's meaningful to the particular user, and I think it would fit user \nexpectations of gitweb (i.e., when looking at Linus's tree's summary, \nthings would be ordered by when they hit Linus's tree, not when they were \noriginally committed, so between the listing of the merge at 23:48:54 \ntoday and the one 7 minutes before would be those things which weren't in \nLinus's tree during those 7 minutes).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"20312","messageId":"7vy7wxfs7v.fsf@assigned-by-dhcp.cox.net","threadId":"4182","inReplyTo":"Pine.LNX.4.64.0605192006400.6713@iabervon.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-20T00:35:48Z","receivedAt":"2006-05-20T00:35:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> $ git pull . stuff\n> # Notice that the diffstat is exciting\n> # What did I just get?\n> $ git log master@{5 minutes ago}..master\n>\n> This is about the only easy way to find out that the fast-forward you just \n> did included merging a line which contains a commit from several weeks \n> ago. (Because the \"before\" state isn't easily accessible for a \n> fast-forward, and the date of the old commit puts it way back in a \n> date-ordered log.)\n\nDid you forget about \"git log ORIG_HEAD..\"?\n"},{"id":"20313","messageId":"Pine.LNX.4.64.0605192116360.6713@iabervon.org","threadId":"4182","inReplyTo":"7vy7wxfs7v.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-05-20T01:36:47Z","receivedAt":"2006-05-20T01:36:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 19 May 2006, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > $ git pull . stuff\n> > # Notice that the diffstat is exciting\n> > # What did I just get?\n> > $ git log master@{5 minutes ago}..master\n> >\n> > This is about the only easy way to find out that the fast-forward you just \n> > did included merging a line which contains a commit from several weeks \n> > ago. (Because the \"before\" state isn't easily accessible for a \n> > fast-forward, and the date of the old commit puts it way back in a \n> > date-ordered log.)\n> \n> Did you forget about \"git log ORIG_HEAD..\"?\n\nI guess I did forget that it sticks around. So you have to be doing \nsomething somewhat more complicated, like fetching the latest versions of \nmultiple topic branches.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"20314","messageId":"Pine.LNX.4.64.0605191853570.10823@g5.osdl.org","threadId":"4182","inReplyTo":"Pine.LNX.4.64.0605192116360.6713@iabervon.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-20T02:06:46Z","receivedAt":"2006-05-20T02:06:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 19 May 2006, Daniel Barkalow wrote:\n> \n> I guess I did forget that it sticks around. So you have to be doing \n> something somewhat more complicated, like fetching the latest versions of \n> multiple topic branches.\n\nI actually don't think it's at all unlikely that I'd start using this.\n\nI tend to work in \"spurts\", where I do one thing for a while, and then \nmerge several pull requests in fairly short order. So while I use \nORIG_HEAD a lot, I can certainly imagine myself using the \"since 2 hours \nago\" format too.\n\nI'm not entirely sure about the syntax, though. It ends up being pretty \ncommand-line-unfriendly. The \"gitk ORIG_HEAD..\" thing is fairly easy to \ntype, but typing\n\n\tgitk 'master@{2 hours ago}'..\n\non a Finnish keyboard (yeah, that's what I still use) is \"interesting\", \nsince all of '@', '{' and '}' are complex characters (AltGr + '2', AltGr + \n'7' and AltGr + '0' respectively), and you have to remember the quoting.\n\nNot that I see any obvious better syntax. Although allowing a shorthand \nlike \"@2.hours.ago\" for \"current branch, at given date\" might help a \nbit, at least that wouldn't need quoting:\n\n\tgitk @2.hours.ago..\n\n\t\t\tLinus\n"},{"id":"20359","messageId":"20060521010129.GB7179@spearce.org","threadId":"4182","inReplyTo":"Pine.LNX.4.64.0605191853570.10823@g5.osdl.org","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-21T01:01:29Z","receivedAt":"2006-05-21T01:01:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> wrote:\n> \n> On Fri, 19 May 2006, Daniel Barkalow wrote:\n> > \n> > I guess I did forget that it sticks around. So you have to be doing \n> > something somewhat more complicated, like fetching the latest versions of \n> > multiple topic branches.\n> \n> I actually don't think it's at all unlikely that I'd start using this.\n\nHey, if its useful.  :-) If its not then I'm doing something\nwrong here...\n \n[snip]\n> I'm not entirely sure about the syntax, though. It ends up being pretty \n> command-line-unfriendly. The \"gitk ORIG_HEAD..\" thing is fairly easy to \n> type, but typing\n> \n> \tgitk 'master@{2 hours ago}'..\n> \n> on a Finnish keyboard (yeah, that's what I still use) is \"interesting\", \n> since all of '@', '{' and '}' are complex characters (AltGr + '2', AltGr + \n> '7' and AltGr + '0' respectively), and you have to remember the quoting.\n\nWow.  So what you are saying is writing any sort of C code must be\nrather painful.  :-)\n\nI received a suggestion of using ' (single quote) rather than {\nas the quoting character.  I didn't make the quoting character\noptional as I realized users were likely to forget they needed it\non date specs which contain ':', so I just made them required to\nkeep things consistent at all times.  Further {} won out over ''\nas {} is also used with the ^ operator (e.g. v1.3.3^{tree}).\n\n> Not that I see any obvious better syntax. Although allowing a shorthand \n> like \"@2.hours.ago\" for \"current branch, at given date\" might help a \n> bit, at least that wouldn't need quoting:\n> \n> \tgitk @2.hours.ago..\n\nThe empty prefix for `HEAD` is simple.  The '.' part would need to\nbe fixed in approxidate() (and thus --since would also benefit).\nOmitting the {} might be OK but see above...\n\n-- \nShawn.\n"},{"id":"20382","messageId":"e4p8e8$uqt$2@sea.gmane.org","threadId":"4182","inReplyTo":"87y7wyv72m.fsf@morpheus.hq.vtech","subject":"Re: [RFD] Git glossary: 'branch' and 'head' description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-21T08:30:23Z","receivedAt":"2006-05-21T08:30:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Kågedal wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n[...]\n>> So from the user's point of view, 'branch' is simply _named line of\n>> development_. Refer to topic and tracking branches.\n> \n> But the definition of 'branch' in git is quite different from the\n> definition in CVS or many other systems.  It CVS, each revision\n> (commit) belongs to a branch, and the branch is a linear sequence of\n> revisions, not a full DAG.  In git, a commit doesn't really \"belong\"\n> in any specific branch.\n> \n> So, while it makes sense to describe branches as \"lines of\n> development\" in general terms, it is also important to note the\n> specific meaning of 'branch' in the context of git; i.e. as the\n> history of a single head commit.\n\nWe can always say that branch is 1-st parent linear history of head branch,\nup to unmarked but computable branching/fork/creation point, i.e.\n\n  {i = 0..N: branch-head~i}\n\nwhere N is the length of the branch.\n\nBTW. HEAD~0 == HEAD, isn't it?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"}]}