{"thread":{"id":"43592","subject":"Re: when is a remote a branch?","startedAt":"2006-11-12T15:50:02Z","lastAt":"2006-11-14T20:44:10Z","messageCount":7,"participants":["Jakub Narebski","Petr Baudis","Anand Kumria"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298726","messageId":"ej7fra$8ca$2@sea.gmane.org","threadId":"43592","inReplyTo":null,"subject":"when is a remote a branch?","fromName":"Anand Kumria","fromEmail":"wildfire@progsoc.org","sentAt":"2006-11-12T15:50:02Z","receivedAt":"2006-11-12T15:50:02Z","isPatch":false,"sender":{"key":"wildfire@progsoc.org","avatar":null},"body":"Hi,\n\nI generally tend to use cogito -- it does all the heavy lifting, like\nrecovering from interrupted fetchs (usually) for me. One thing I haven't\nreally gotten my head around is the difference between a branch and a\nremote.\n\ngit-branch knows of 'remotes' (via the -r parameter) and these to be\nunrelated to what cogito thinks remotes are (it seems to look for things\nin .git/refs/head/ and then a corresponding .git/branches//\nwhich it then declares a remote).\n\nYet, git-init-db creates both .git/remotes and .git/branches\n\nWhat is the difference between the two. From my (naïve) perspective the\ntwo tools (git and cogito) regarded them very differently.\n\nAny explanation, or pointer to some documentation, would be helpful.\n\nThanks,\nAnand\n"},{"id":"297990","messageId":"ej7h1n$ed8$1@sea.gmane.org","threadId":"43592","inReplyTo":"ej7fra$8ca$2@sea.gmane.org","subject":"Re: when is a remote a branch?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-12T16:11:41Z","receivedAt":"2006-11-12T16:11:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Anand Kumria wrote:\n\n> I generally tend to use cogito -- it does all the heavy lifting, like\n> recovering from interrupted fetchs (usually) for me. One thing I haven't\n> really gotten my head around is the difference between a branch and a\n> remote.\n> \n> git-branch knows of 'remotes' (via the -r parameter) and these to be\n> unrelated to what cogito thinks remotes are (it seems to look for things\n> in .git/refs/head/ and then a corresponding .git/branches//\n> which it then declares a remote).\n\nNot about 'remotes', but about 'remote [read-only] branches', i.e. refs not\nfrom .refs/heads/, but from .refs/remotes//\n\n> Yet, git-init-db creates both .git/remotes and .git/branches\n> \n> What is the difference between the two. From my (na?ve) perspective the\n> two tools (git and cogito) regarded them very differently.\n> \n> Any explanation, or pointer to some documentation, would be helpful.\n\nRead Documentation/repository-layout.txt (ot it's HTML version, either\nlocally ot at www.kernel.org).\n\n branches::\n A slightly deprecated way to store shorthands to be used\n to specify URL to `git fetch`, `git pull` and `git push`\n commands is to store a file in `branches/'name'` and\n give 'name' to these commands in place of 'repository'\n argument.\n\nYou can store only one branch to fetch per shorthand. I'm not sure about\nwhere it is stored which branch to download, and how to name this branch \nlocally.\n\n remotes::\n Stores shorthands to be used to give URL and default\n refnames to interact with remote repository to `git\n fetch`, `git pull` and `git push` commands.\n\nFrom Documentation/urls.txt\n\n In addition to the above, as a short-hand, the name of a\n file in `$GIT_DIR/remotes` directory can be given; the\n named file should be in the following format:\n\n URL: one of the above URL format\n Push: \n Pull: \n\nCurrently there is yet another way, by using config file:\n(also from Documentation/urls.txt):\n\n Or, equivalently, in the `$GIT_DIR/config` (note the use\n of `fetch` instead of `Pull:`):\n\n [remote \"\"]\n url = \n push = \n fetch = \n\nwhere is defined in Documentation/fetch-pull-param.txt\n\n ::\n The canonical format of a parameter is\n `+?:`; that is, an optional plus `+`, followed\n by the source ref, followed by a colon `:`, followed by\n the destination ref.\n\n(or, simply, in git-pull(1), which includes those files, with exception of\nrepository layout document).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297984","messageId":"20061112163624.GE7201@pasky.or.cz","threadId":"43592","inReplyTo":"ej7h1n$ed8$1@sea.gmane.org","subject":"Re: when is a remote a branch?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-12T16:36:24Z","receivedAt":"2006-11-12T16:36:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Nov 12, 2006 at 05:11:41PM CET, Jakub Narebski wrote:\n> Read Documentation/repository-layout.txt (ot it's HTML version, either\n> locally ot at www.kernel.org).\n> \n> branches::\n> A slightly deprecated way to store shorthands to be used\n> to specify URL to `git fetch`, `git pull` and `git push`\n> commands is to store a file in `branches/'name'` and\n> give 'name' to these commands in place of 'repository'\n> argument.\n> \n> You can store only one branch to fetch per shorthand. I'm not sure about\n> where it is stored which branch to download, and how to name this branch \n> locally.\n\nI think the above is quite confusing description. This really is not\nabout any \"shorthands\" at all, but just about branches (how the name\nimplies, after all).\n\nGit and Cogito share the same models of branches. These branches are\n'heads' with commit pointers stored in refs/heads/, etc. The branches/\ndirectory says that some branches do not correspond to local development\n(and should never be used for that) but instead they correspond to a\nparticular branch in some remote repository. Such branches are called\n\"REMOTE BRANCHES\".\n\nSo it's \"if branch X has corresponding .git/branch/X file, it's not a\nlocal branch but instead a REMOTE BRANCH corresponding to the URL stored\nin that file\". That simple. The URL is address of the repository plus\noptionally a '#branchname' if the branch name in the remote repository\nshould not default to remote HEAD or master.\n\nIn addition, Git (not Cogito at this point) supports a completely\ndifferent and unrelated abstraction called REMOTES. They don't have\nanything to do with branches. Instead, a REMOTE represents a repository\nURL and a set of local/remote branch pairs to handle on pulls and\npushes; it has no other obvious mapping to branches and branches can be\neven shared between various REMOTES etc. (this is changing lately with\nthe refs/remotes/ hierarchy, but I think that's still not in wide use).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On Sun, Nov 12, 2006 at 05:11:41PM CET, Jakub Narebski wrote:\n>> Read Documentation/repository-layout.txt (ot it's HTML version, either\n>> locally ot at www.kernel.org).\n>> \n>> branches::\n>> A slightly deprecated way to store shorthands to be used\n>> to specify URL to `git fetch`, `git pull` and `git push`\n>> commands is to store a file in `branches/'name'` and\n>> give 'name' to these commands in place of 'repository'\n>> argument.\n>> \n>> You can store only one branch to fetch per shorthand. I'm not sure about\n>> where it is stored which branch to download, and how to name this branch \n>> locally.\n> \n> I think the above is quite confusing description. This really is not\n> about any \"shorthands\" at all, but just about branches (how the name\n> implies, after all).\n\nWell, it is a shorthand in a way that you can just use \"git fetch\"\nor \"cg fetch\" to fetch correct branch without need for URL.\n\nBut I agree that the description (although of deprecated feature)\ncould be better.\n\n> Git and Cogito share the same models of branches. These branches are\n> 'heads' with commit pointers stored in refs/heads/, etc. \n\nNot exactly. \"Live\" branches (i.e. branches you can commit to) are head\nrefs stored in refs/heads/. But in repository cloned with git-clone\n--use-separate-remotes tracking heads (tracking branches) would be at\nrefs/remotes//. You can fetch to such a ref, but you can't\ncheckout it, nor commit to it.\n\n> The branches/ \n> directory says that some branches do not correspond to local development\n> (and should never be used for that) but instead they correspond to a\nDoes that _should_ is enforced in Cogito? Is it enforced in Git?\n\n> particular branch in some remote repository. Such branches are called\n> \"REMOTE BRANCHES\".\n\nI'd rather call them \"tracking branches\", at least in git. So if there\nis branch 'localbranch' in refs/heads/ (?), and there is corresponding\nbranches file branches/localbranch, which contains a single URL\n git://host.domain/path/to/repository#remotebranch\nit is AFAICU equivalent to having some remotes file, named e.g. 'repo',\nwith the following contents:\n URL: git://host.domain/path/to/repository\n Pull: remotebranch:localbranch\n Push: remotebranch:localbranch\nor equivalent entry in git config.\n\n> So it's \"if branch X has corresponding .git/branch/X file, it's not a\n> local branch but instead a REMOTE BRANCH corresponding to the URL stored\n> in that file\". That simple. The URL is address of the repository plus\n> optionally a '#branchname' if the branch name in the remote repository\n> should not default to remote HEAD or master.\n\nThe whole concept of branches file (and marking some branches as \"remote\"\nbranches) is IMHO from the times where there were most common to have one\nlive branch per repository, and we fetched and pushed single branches.\nThis simple picture changed with more widespread use of multiple heads,\nand with the introduction of tags (I think).\n \n> In addition, Git (not Cogito at this point) supports a completely\n> different and unrelated abstraction called REMOTES. They don't have\n> anything to do with branches. Instead, a REMOTE represents a repository\n> URL and a set of local/remote branch pairs to handle on pulls and\n> pushes; it has no other obvious mapping to branches and branches can be\n> even shared between various REMOTES etc. (this is changing lately with\n> the refs/remotes/ hierarchy, but I think that's still not in wide use).\n\nRemote is usually a repository. It is single URL (although it would be\nnice to be able to specify alternate URLs for the same repository, or\nfor different mirrors of the same repository) representing repository\nto fetch from/to push to, together with branches we want to fetch (which\nparts of DAG we want to fetch), and local names of those branches,\nfollowing fetched contents.\n\nBy the way, with introduction of branches and remotes in config file,\nyou can say:\n [branch \"localbranch\"]\n\tremote = someremote\n\n [remote \"someremote\"]\n\tfetch = remotebranch:localbranch\n\tpush = remotebranch:localbranch\n\nand that would be equivalent to example branches file from the beginning\nof this email.\n-- \nJakub Narebski\n"},{"id":"297492","messageId":"20061114202835.GJ7201@pasky.or.cz","threadId":"43592","inReplyTo":"200611121831.18851.jnareb@gmail.com","subject":"Re: when is a remote a branch?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-14T20:28:35Z","receivedAt":"2006-11-14T20:28:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Nov 12, 2006 at 06:31:18PM CET, Jakub Narebski wrote:\n> Petr \"Pasky\" Baudis wrote:\n> > Git and Cogito share the same models of branches. These branches are\n> > 'heads' with commit pointers stored in refs/heads/, etc. \n> \n> Not exactly. \"Live\" branches (i.e. branches you can commit to) are head\n> refs stored in refs/heads/. But in repository cloned with git-clone\n> --use-separate-remotes tracking heads (tracking branches) would be at\n> refs/remotes//. You can fetch to such a ref, but you can't\n> checkout it, nor commit to it.\n\nThat was meant to be the \"etc\". ;-))\n\n> > The branches/ \n> > directory says that some branches do not correspond to local development\n> > (and should never be used for that) but instead they correspond to a\n> Does that _should_ is enforced in Cogito? Is it enforced in Git?\n\nYes (you cannot switch to it). No (AFAIK).\n\n> > particular branch in some remote repository. Such branches are called\n> > \"REMOTE BRANCHES\".\n> \n> I'd rather call them \"tracking branches\", at least in git. So if there\n> is branch 'localbranch' in refs/heads/ (?), and there is corresponding\n> branches file branches/localbranch, which contains a single URL\n> git://host.domain/path/to/repository#remotebranch\n> it is AFAICU equivalent to having some remotes file, named e.g. 'repo',\n> with the following contents:\n> URL: git://host.domain/path/to/repository\n> Pull: remotebranch:localbranch\n> Push: remotebranch:localbranch\n> or equivalent entry in git config.\n\nYes, except that the remote must be named 'localbranch'.\n\n> > So it's \"if branch X has corresponding .git/branch/X file, it's not a\n> > local branch but instead a REMOTE BRANCH corresponding to the URL stored\n> > in that file\". That simple. The URL is address of the repository plus\n> > optionally a '#branchname' if the branch name in the remote repository\n> > should not default to remote HEAD or master.\n> \n> The whole concept of branches file (and marking some branches as \"remote\"\n> branches) is IMHO from the times where there were most common to have one\n> live branch per repository, and we fetched and pushed single branches.\n> This simple picture changed with more widespread use of multiple heads,\n> and with the introduction of tags (I think).\n\nI completely agree. The original remotes implementation was messy, but\nwith refs/remotes/ it's simple again. Only lack of time (or laziness) on\nmy side is why Cogito didn't move to this yet.\n\n> By the way, with introduction of branches and remotes in config file,\n> you can say:\n> [branch \"localbranch\"]\n> \tremote = someremote\n> [remote \"someremote\"]\n> \tfetch = remotebranch:localbranch\n> \tpush = remotebranch:localbranch\n> \n> and that would be equivalent to example branches file from the beginning\n> of this email.\n\nAccording to the documentation, this is not really useful since this\njust tells what should git fetch default to when on branch\n\"localbranch\". But \"localbranch\" is still just a branch representing a\nstate in a remote repository, so you should never be _on_ it in a sane\nsetup, but instead on a different branch which tracks it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On Sun, Nov 12, 2006 at 06:31:18PM CET, Jakub Narebski wrote:\n>>\n>> By the way, with introduction of branches and remotes in config file,\n>> you can say:\n>> [branch \"localbranch\"]\n>> \tremote = someremote\n>> [remote \"someremote\"]\n>> \tfetch = remotebranch:localbranch\n>> \tpush = remotebranch:localbranch\n>> \n>> and that would be equivalent to example branches file from\n>> the beginning of this email.\n> \n> According to the documentation, this is not really useful since this\n> just tells what should git fetch default to when on branch\n> \"localbranch\". But \"localbranch\" is still just a branch representing a\n> state in a remote repository, so you should never be _on_ it in a sane\n> setup, but instead on a different branch which tracks it.\n\nOh. Can you \"git fetch Localbranch\" _without_ repository named \n\"localbranch\" in above case?\n-- \nJakub Narebski\n"},{"id":"296453","messageId":"20061114204410.GK7201@pasky.or.cz","threadId":"43592","inReplyTo":"200611142136.17517.jnareb@gmail.com","subject":"Re: when is a remote a branch?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-14T20:44:10Z","receivedAt":"2006-11-14T20:44:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 14, 2006 at 09:36:16PM CET, Jakub Narebski wrote:\n> Petr \"Pasky\" Baudis wrote:\n> > On Sun, Nov 12, 2006 at 06:31:18PM CET, Jakub Narebski wrote:\n> >>\n> >> By the way, with introduction of branches and remotes in config file,\n> >> you can say:\n> >> [branch \"localbranch\"]\n> >> \tremote = someremote\n> >> [remote \"someremote\"]\n> >> \tfetch = remotebranch:localbranch\n> >> \tpush = remotebranch:localbranch\n> >> \n> >> and that would be equivalent to example branches file from\n> >> the beginning of this email.\n> > \n> > According to the documentation, this is not really useful since this\n> > just tells what should git fetch default to when on branch\n> > \"localbranch\". But \"localbranch\" is still just a branch representing a\n> > state in a remote repository, so you should never be _on_ it in a sane\n> > setup, but instead on a different branch which tracks it.\n> \n> Oh. Can you \"git fetch Localbranch\" _without_ repository named \n> \"localbranch\" in above case?\n\nSo that it would be equivalent to git fetch someremote, and also fetch\nany other branches associated with that remote?\n\nI would hope not. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i