{"thread":{"id":"15928","subject":"Working with remotes; cloning remote references","startedAt":"2008-10-16T18:17:19Z","lastAt":"2008-10-28T16:27:50Z","messageCount":24,"participants":["Marc Branchaud","Peter Harris","Michael J Gruber","Björn Steinbrink","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93221","messageId":"48F7852F.109@xiplink.com","threadId":"15928","inReplyTo":null,"subject":"Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-16T18:17:19Z","receivedAt":"2008-10-16T18:17:19Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Hi all,\n\nWe're a Subversion shop moving to git, and our git-fu is still pretty \nweak.  So I'd appreciate feedback on the setup I'm going to describe, in \naddition to the specific issue I'm going to raise.\n\nOur products involve extensive customization of various \nexternally-maintained code bases (mainly in FreeBSD, but also in a few \nother projects too).  We'd like to track the various external \nrepositories, to be able to bring their updates into our code base.  We \ndon't normally push our own customizations back upstream (yes, not The \nWay Things Should Be, please turn down the flamethrowers).\n\nSo we want our main code tree to be composed of our own code and an \nassortment of modified external code:\n\nmain/\n   external1/\n   external2/\n   ourstuffA/\n   ourstuffB/\n\nOur general approach for supporting this (remember, git novices here) is \nto keep a local git mirror of each external code repository (say, with \ngit-svn for the FreeBSD tree).  Then we incorporate the local mirrors \ninto our main repo, each under its own directory.\n\nI've looked at two ways to do this: submodules and subtree merges, and \nthe latter looks better to me.  The main complication with submodules is \nbranching and tagging.  We need to branch or tag the entire main code \ntree, including all the external code bases.  With submodules that seems \nlike it would involve several steps to touch all the external mirror \nrepos as well as the main repo.  Another complication is that we do a \nlot of our work (50% or more) in the external code trees, and having to \nupdate the main repo's submodule references as that code changes seems \nrather fragile.\n\nOTOH, a subtree merge nicely puts the external code into a specific spot \nin our main tree, lets that spot get updated with a single command (git \npull -s subtree External2 master), and still let us branch and tag with \nsingle commands in the main repo.  Also, the changes we make to \nexternally-based code are plain old git pushes to the main repo.  Clean \nand simple.  (BTW, what does braid add beyond just doing subtree merges \ndirectly?)\n\nSo, first the general question: Anything braindead about the above?  Any \nbetter ways to do this?\n\nNow for the specific issue, which has to do with managing the remotes \ndefined in the main repository.  The subtree-merge approach calls for \nthe mirrored external repos to be \"git remote add\"-ed to the main repo. \n  But clones of that repo don't include the remote references (using git \n1.5.4.3 for my testing here).\n\nI think that makes sense in most cases:  Usually a developer will only \nwant to clone the main repo and work with what's in there, ad not want \nto bother with the external references.  But when it comes time to pull \nin updates from the external mirror repos the only place where that can \nbe done is on the main repo where the original \"git remote add\" commands \nwere issued.\n\nThat means merge work has to be done on the main repository's shared \nhost (not good) and that testing merged code has to involve committing \nchanges on the main shared repo (also not good, even in a branch) and \ntesting them on a different host (still no goodness here).\n\n From this point of view (and please correct me if I'm wrong), it would \nbe good if \"git clone\" had an option to include a repo's remote \nreferences in the clone.  The clone's origin reference would point to \nthe original repo as usual, but all the other remotes would be in the clone.\n\nPushing and pulling would then also update (non-origin) the remote \nreferences.\n\nDoes this make sense?  Am I missing something here?  (And thanks for \nreading this far!)\n\n\t\tMarc\n"},{"id":"93223","messageId":"eaa105840810161220k26eebd48q8de606597f2be055@mail.gmail.com","threadId":"15928","inReplyTo":"48F7852F.109@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2008-10-16T19:20:41Z","receivedAt":"2008-10-16T19:20:41Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Thu, Oct 16, 2008 at 2:17 PM, Marc Branchaud wrote:\n> From this point of view (and please correct me if I'm wrong), it would be\n> good if \"git clone\" had an option to include a repo's remote references in\n> the clone.  The clone's origin reference would point to the original repo as\n> usual, but all the other remotes would be in the clone.\n\n\"git clone\" doesn't have this option, but you can turn it on\nimmediately after with something similar to:\ngit config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*\n(which I use for fanning-out my git-svn repos)\n\nSee \"git help fetch\" for further documentation.\n\nPeter Harris\n"},{"id":"93237","messageId":"48F7A42E.70200@xiplink.com","threadId":"15928","inReplyTo":"eaa105840810161220k26eebd48q8de606597f2be055@mail.gmail.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-16T20:29:34Z","receivedAt":"2008-10-16T20:29:34Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Peter Harris wrote:\n> \n> \"git clone\" doesn't have this option, but you can turn it on\n> immediately after with something similar to:\n> git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*\n> (which I use for fanning-out my git-svn repos)\n\nThanks for the pointer (and the quick reply).\n\nThat doesn't seem to be what I'm looking for, though -- perhaps I'm \nmissing something?  The above puts the remotes in the .git/refs/remotes \ndirectory, but the .git/config file doesn't have them.\n\nMore specifically, if I clone the main repository and run the above and \nthen fetch, then AFAICT I'm still not linked to the external mirrors in \nthe clone.  In particular, I can't refer to an external project in the \nsubtree pull:\n\n\t$ git pull -s subtree external2 master\n\tfatal: 'external2': unable to chdir or not a git archive\n\n(Where 'external2' is the name of the remote in the main repo.)  Also, \nthe only remote in the config file is still just the origin.\n\n(As an aside, the above \"git config --add\" incantation causes problems \nif run inside a clone of a clone:\n\t$ git clone main clone-of-main\n\t$ git clone clone-of-main clone-of-clone-of-main\n\t$ cd clone-of-clone-of-main\n\t$ git config --add remote.origin.fetch \\\n\t\t+refs/remotes/*:refs/remotes/*\n\t$ git pull\n\tfatal: refs/remotes/origin/master tracks both \nrefs/remotes/origin/master and refs/heads/master\n)\n\nYou did say \"something similar\" in your reply -- am I not seeing \nsomething obvious?\n\n\t\tMarc\n"},{"id":"93242","messageId":"eaa105840810161345r69c9f05j66bb850085f561e7@mail.gmail.com","threadId":"15928","inReplyTo":"48F7A42E.70200@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2008-10-16T20:45:08Z","receivedAt":"2008-10-16T20:45:08Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Thu, Oct 16, 2008 at 4:29 PM, Marc Branchaud wrote:\n> Peter Harris wrote:\n>>\n>> \"git clone\" doesn't have this option, but you can turn it on\n>> immediately after with something similar to:\n>> git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*\n>> (which I use for fanning-out my git-svn repos)\n>\n> Thanks for the pointer (and the quick reply).\n>\n> That doesn't seem to be what I'm looking for, though -- perhaps I'm missing\n> something?  The above puts the remotes in the .git/refs/remotes directory,\n> but the .git/config file doesn't have them.\n\nAh. I believe I misunderstood what you wanted. Perhaps you want \"git\nremote add\", then? Unfortunately, you have to know what your remotes\nare outside of git for this. Perhaps a script in the root of your\nrepository you can run to set this up after the initial clone?\n\nI seem to recall some discussion of allowing a .gitconfig to be in\nrepositories (similar to .gitignore), but the idea was shot down for\nsecurity reasons.\n\n> (As an aside, the above \"git config --add\" incantation causes problems if\n> run inside a clone of a clone:\n>\n> You did say \"something similar\" in your reply -- am I not seeing something\n> obvious?\n\nI said \"something similar\" because you probably actually want\ngit config --add remote.$remote.fetch +refs/remotes/*:refs/remotes/$remote/*\n(or other names of your own choosing) so that multiple remote remotes\ndon't stomp on each other.\n\nUnless you want to be able to address the remotes by name, in which\ncase you want \"git remote add\" instead (see above).\n\nPeter Harris\n"},{"id":"93247","messageId":"48F7BBAC.2090907@xiplink.com","threadId":"15928","inReplyTo":"eaa105840810161345r69c9f05j66bb850085f561e7@mail.gmail.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-16T22:09:48Z","receivedAt":"2008-10-16T22:09:48Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Peter Harris wrote:\n> \n> Ah. I believe I misunderstood what you wanted. Perhaps you want \"git\n> remote add\", then? Unfortunately, you have to know what your remotes\n> are outside of git for this. Perhaps a script in the root of your\n> repository you can run to set this up after the initial clone?\n\nI think we're converging onto the same track.\n\nYes, I do want to use \"git remote add\".  My point is basically that, \nhaving done various git-remote-adds in the main repository, I'd like to \navoid having to redo them in a clone of that repository.\n\nA script would work, sure, but to me this seems like something git \nshould handle for me.  If I have to re-establish my connections to the \nremotes whenever I want to pull in updates, then I don't see much point \nin keeping the remotes defined in any git repo.\n\n> I seem to recall some discussion of allowing a .gitconfig to be in\n> repositories (similar to .gitignore), but the idea was shot down for\n> security reasons.\n\nI think I can understand why that would be undesirable, but I don't know \nif something like that would be necessary for what I'm talking about.\n\n\t\tMarc\n"},{"id":"93273","messageId":"48F83FD0.90606@drmicha.warpmail.net","threadId":"15928","inReplyTo":"48F7BBAC.2090907@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-17T07:33:36Z","receivedAt":"2008-10-17T07:33:36Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Branchaud venit, vidit, dixit 17.10.2008 00:09:\n> Peter Harris wrote:\n>> Ah. I believe I misunderstood what you wanted. Perhaps you want \"git\n>> remote add\", then? Unfortunately, you have to know what your remotes\n>> are outside of git for this. Perhaps a script in the root of your\n>> repository you can run to set this up after the initial clone?\n> \n> I think we're converging onto the same track.\n> \n> Yes, I do want to use \"git remote add\".  My point is basically that, \n> having done various git-remote-adds in the main repository, I'd like to \n> avoid having to redo them in a clone of that repository.\n> \n> A script would work, sure, but to me this seems like something git \n> should handle for me.  If I have to re-establish my connections to the \n> remotes whenever I want to pull in updates, then I don't see much point \n> in keeping the remotes defined in any git repo.\n> \n>> I seem to recall some discussion of allowing a .gitconfig to be in\n>> repositories (similar to .gitignore), but the idea was shot down for\n>> security reasons.\n> \n> I think I can understand why that would be undesirable, but I don't know \n> if something like that would be necessary for what I'm talking about.\n\nI don't think there is a direct gittish way for transferring the remote\nconfig from one repo to a clone (other than copying what git submodule\ndoes with .gitmodules etc.).\n\nWould it be sufficient for you if a clone could trigger the main repo to\nupdate its remotes (i.e. git remote update)?\n\nMichael\n"},{"id":"93297","messageId":"48F8A4E8.8070008@xiplink.com","threadId":"15928","inReplyTo":"48F83FD0.90606@drmicha.warpmail.net","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-17T14:44:56Z","receivedAt":"2008-10-17T14:44:56Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Thanks for joining the thread, Michael!\n\nMichael J Gruber wrote:\n> \n> I don't think there is a direct gittish way for transferring the remote\n> config from one repo to a clone (other than copying what git submodule\n> does with .gitmodules etc.).\n\nThat's my impression, too, so I'm suggesting that the clone/push/pull \ncommands get an option to work with remotes in config.\n\n> Would it be sufficient for you if a clone could trigger the main repo to\n> update its remotes (i.e. git remote update)?\n\nHmmm, I'm not sure...  How would the overall \nmerge-in-changes-from-upstream process work in that case?\n\nSay the main repo has the code for \"ThingOne\" merged under a top-level \nthing-one/ directory:\n\nmain/$ git remote add -f ThingOne git://thing/ThingOne.git\nmain/$ git merge -s ours --no-commit ThingOne/master\nmain/$ git read-tree --prefix=thing-one/ -i ThingOne/master\nmain/$ git commit -m \"Merged ThingOne into /thing-one/\"\n\nThen the ThingOne folks update their code, so we want to incorporate \ntheir changes into our version of their code.  I think you're suggesting \nthat we might make a clone of the main repo then trigger a \"git remote \nupdate\" in the clone's origin:\n\nclone/$ make-origin-do-git-remote-update\n\nWhat's not clear to me is how to proceed from here.  At this point I'm \nhoping there's some way I could do some work in the clone to merge the \nchanges the ThingOne folks did into our code.  I'm too new to git to \nknow if there is a way forward -- is there?\n\n(With the subtree merge pattern I'd run \"git pull -s subtree ThingOne \nmaster\" in the main repo -- is there an equivalent achievable in the \nclone if the main has done a \"git remote update\"?)\n\nThanks,\n\n\t\tMarc\n"},{"id":"93299","messageId":"48F8AA5E.6090908@drmicha.warpmail.net","threadId":"15928","inReplyTo":"48F8A4E8.8070008@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-17T15:08:14Z","receivedAt":"2008-10-17T15:08:14Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Branchaud venit, vidit, dixit 17.10.2008 16:44:\n> Thanks for joining the thread, Michael!\n\nSure, there's no need to mention it.\n\nWell, maybe there is, given the recent discussion: Everyone can\ncontribute (with or without C/perl/whatever fu) and thus \"pay back\" for\nfree software, even by \"only\" trying to answer questions. But it\nrequires participation, combining efforts, rather than splitting off and\nnot returning... Uh, sorry, your question:\n\n> Michael J Gruber wrote:\n>> Would it be sufficient for you if a clone could trigger the main repo to\n>> update its remotes (i.e. git remote update)?\n> \n> Hmmm, I'm not sure...  How would the overall \n> merge-in-changes-from-upstream process work in that case?\n\nI thought your problem was \"transporting\" the remote branches from main\n(which tracks external) to clone, without having the remote config for\nexternal on the clones. In that case being able to trigger \"remote\nupdate\" on main from the clones would help.\n\n> Say the main repo has the code for \"ThingOne\" merged under a top-level \n> thing-one/ directory:\n> \n> main/$ git remote add -f ThingOne git://thing/ThingOne.git\n> main/$ git merge -s ours --no-commit ThingOne/master\n> main/$ git read-tree --prefix=thing-one/ -i ThingOne/master\n> main/$ git commit -m \"Merged ThingOne into /thing-one/\"\n> \n> Then the ThingOne folks update their code, so we want to incorporate \n> their changes into our version of their code.  I think you're suggesting \n> that we might make a clone of the main repo then trigger a \"git remote \n> update\" in the clone's origin:\n> \n> clone/$ make-origin-do-git-remote-update\n> \n> What's not clear to me is how to proceed from here.  At this point I'm \n> hoping there's some way I could do some work in the clone to merge the \n> changes the ThingOne folks did into our code.  I'm too new to git to \n> know if there is a way forward -- is there?\n> \n> (With the subtree merge pattern I'd run \"git pull -s subtree ThingOne \n> master\" in the main repo -- is there an equivalent achievable in the \n> clone if the main has done a \"git remote update\"?)\n\n\"pull -s strategy repo master\" does a fetch followed by \"merge -s\nstrategy repomaster\", where repomaster is the ref for master on repo.\nSo, if you got that branch (repomaster=ThingOne/master) by cloning from\nmain you can do the merge (subtree or other) on your clone, even without\nthe remote repo config for ThingOne on clone.\n\nI guess you want to do those merges on several clones, and main, and\npush everything back to main. I don't know how well that mixes, but I\ndon't expect problems, only unexpected ones ;)\n\nCheers,\nMichael\n"},{"id":"93309","messageId":"48F8ECA2.3040208@xiplink.com","threadId":"15928","inReplyTo":"48F8AA5E.6090908@drmicha.warpmail.net","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-17T19:50:58Z","receivedAt":"2008-10-17T19:50:58Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nMichael J Gruber wrote:\n> \n> \"pull -s strategy repo master\" does a fetch followed by \"merge -s\n> strategy repomaster\", where repomaster is the ref for master on repo.\n> So, if you got that branch (repomaster=ThingOne/master) by cloning from\n> main you can do the merge (subtree or other) on your clone, even without\n> the remote repo config for ThingOne on clone.\n\nI'm afraid I'm having trouble translating what you're saying into actual \ngit commands (or are you proposing some new git functionality?).  How \nwould I get the ThingOne/master branch into the clone?\n\n\nAfter some more thought I realized that the clone can just pull directly \nfrom the ThingOne repository:\n\nclone/$ git pull -s subtree git://thing/ThingOne.git master\n\n(I'm still getting used to git's ability to match commit IDs from \nanywhere -- it's magic! :) )\n\nThis goes a long way to where we want to be, in that we don't have to do \nour merging work in the original main repository.\n\nIt would be nice, though, if the clone were able to use the main \nrepository's definition of the ThingOne remote.  I can think of some \nplausible scenarios where a person could get confused about which \nrepo/branch they're supposed to pull.  It's easy to recover from that \nkind of mistake, but there'd be less chance of a mistake if one could \ntell git to \"pull from X as defined in the origin repository\".\n\nAnd actually, git's remote functionality feels a bit crippled if clones \ncan't make some use of the origin's remotes.  Is there a reason for \nkeeping remote definitions out of a clone?\n\n\t\tMarc\n"},{"id":"93502","messageId":"48FC8624.9090807@fastmail.fm","threadId":"15928","inReplyTo":"48F8ECA2.3040208@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-10-20T13:22:44Z","receivedAt":"2008-10-20T13:22:44Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Branchaud venit, vidit, dixit 17.10.2008 21:50:\n> Michael J Gruber wrote:\n>> \"pull -s strategy repo master\" does a fetch followed by \"merge -s\n>> strategy repomaster\", where repomaster is the ref for master on repo.\n>> So, if you got that branch (repomaster=ThingOne/master) by cloning from\n>> main you can do the merge (subtree or other) on your clone, even without\n>> the remote repo config for ThingOne on clone.\n> \n> I'm afraid I'm having trouble translating what you're saying into actual \n> git commands (or are you proposing some new git functionality?).  How \n> would I get the ThingOne/master branch into the clone?\n\nSorry for being cryptic. What I meant was: The clones don't need the\nfull remote config of main in order to get main's remote branches for\nthe ThingOne remote. Say, main stores the remote tracking branches for\nThingOne in \"refs/remotes/ThingOne\", using an appropriate remote config.\nThen a clone could use the refspec\n\"refs/remotes/ThingOne/*:refs/remotes/ThingOne/*\" (when fetching from\nmain) in order to fetch those branches, without having a remote config\nfor ThingOne on the clone. Concretely:\n\ngit config remote.main.fetch\n'+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'\n\non a clone which has a remote config \"main\" for the main repo.\n\n> After some more thought I realized that the clone can just pull directly \n> from the ThingOne repository:\n> \n> clone/$ git pull -s subtree git://thing/ThingOne.git master\n\nI thought that's what you were trying to avoid...\n\n> (I'm still getting used to git's ability to match commit IDs from \n> anywhere -- it's magic! :) )\n\n... but this explains everything ;)\n\n> This goes a long way to where we want to be, in that we don't have to do \n> our merging work in the original main repository.\n> \n> It would be nice, though, if the clone were able to use the main \n> repository's definition of the ThingOne remote.  I can think of some \n> plausible scenarios where a person could get confused about which \n> repo/branch they're supposed to pull.  It's easy to recover from that \n> kind of mistake, but there'd be less chance of a mistake if one could \n> tell git to \"pull from X as defined in the origin repository\".\n\nI think the approach I outlined above could solve this: main prepares\neverything to be pulled under refs/remotes/ThingOne, and clones (i.e.\nclone users) are told to fetch with a refspec like above. This way they\nget a copy of main's remote tracking branches for ThingOne. (Maybe you\nuse one branch only, then the refspec is even simpler.)\n\n> And actually, git's remote functionality feels a bit crippled if clones \n> can't make some use of the origin's remotes.  Is there a reason for \n> keeping remote definitions out of a clone?\n\nSay A and B are working on a project C. Then, typically, A is interested\nin B's work on C, i.e. some of B's local branches, but not on B's remote\n tracking branches: A tracks a \"central\" C already, just like B does,\nand remote tracking branches don't carry any \"value adding\" by the\ncloner, they're just a local unmodified copy of the remote.\n\nBut you can always add a refspec like above.\n\nMichael\n"},{"id":"93529","messageId":"48FCB6B8.6090708@xiplink.com","threadId":"15928","inReplyTo":"48FC8624.9090807@fastmail.fm","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-20T16:50:00Z","receivedAt":"2008-10-20T16:50:00Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Thanks for the explicit instructions, but I think I'm still missing \nsomething.  Here's exactly what I'm trying, just to make sure I'm not \ndoing something odd.\n\nFirst I set up the remote in the main repo:\n\nmain/$ git remote add -f ThingOne git://thing/ThingOne.git\nmain/$ git merge -s ours --no-commit ThingOne/master\nmain/$ git read-tree --prefix=thing-one/ -u ThingOne/master\nmain/$ git commit -m \"Adding ThingOne\"\n\nThen I make a clone, fetch main's refs to ThingOne, and try to pull in \nchanges from ThingOne by using those refs:\n\n$ git clone /path/to/main clone\n$ cd clone\nclone/$ git config remote.origin.fetch \\\n         '+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*' \n\nclone/$ git fetch\n From /path/to/main/\n  * [new branch]      ThingOne/master -> ThingOne/master \n\nclone/$ git pull -s subtree git://thing/ThingOne.git ThingOne/master\nfatal: Couldn't find remote ref ThingOne/master\n\nThe config & fetch commands indeed add a \n.git/refs/remotes/ThingOne/master file to the clone, but I'm missing the \nmagic words for how to use that ref.\n\n\nAlso:\n\nMichael J Gruber wrote:\n> \n>> And actually, git's remote functionality feels a bit crippled if clones \n>> can't make some use of the origin's remotes.  Is there a reason for \n>> keeping remote definitions out of a clone?\n> \n> Say A and B are working on a project C. Then, typically, A is interested\n> in B's work on C, i.e. some of B's local branches, but not on B's remote\n>  tracking branches: A tracks a \"central\" C already, just like B does,\n> and remote tracking branches don't carry any \"value adding\" by the\n> cloner, they're just a local unmodified copy of the remote.\n\nI can appreciate that, but the approach leads to two consequences that I \nsuggest should be avoidable:\n\n1. A and B both have to set up the references to C themselves.  A can't \njust piggyback on whatever B has already set up.  (This is the impetus \nfor my original message.)\n\n2. Suppose B is just a repository that's being shared between A and D -- \ni.e. there's no B entity doing any work directly in B.  In this case if \nA (or D) wants to change B's reference to C (say, to track a new branch \nin C), they can't: B has to be changed directly, and nothing can be done \nin a clone to accomplish this.\n\nI admit I'm picking at nits here -- obviously someone is able to access \nthe B repo and do whatever needs doing.  I just feel that there are some \nsituations where you want the origin's remotes in your clone, and some \nwhere you don't, and git should let you decide.\n\n\t\tMarc\n"},{"id":"93585","messageId":"48FDA5A0.8030506@drmicha.warpmail.net","threadId":"15928","inReplyTo":"48FCB6B8.6090708@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-21T09:49:20Z","receivedAt":"2008-10-21T09:49:20Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Branchaud venit, vidit, dixit 10/20/08 18:50:\n> Thanks for the explicit instructions, but I think I'm still missing \n> something.  Here's exactly what I'm trying, just to make sure I'm not \n> doing something odd.\n> \n> First I set up the remote in the main repo:\n> \n> main/$ git remote add -f ThingOne git://thing/ThingOne.git\n> main/$ git merge -s ours --no-commit ThingOne/master\n> main/$ git read-tree --prefix=thing-one/ -u ThingOne/master\n> main/$ git commit -m \"Adding ThingOne\"\n> \n> Then I make a clone, fetch main's refs to ThingOne, and try to pull in \n> changes from ThingOne by using those refs:\n> \n> $ git clone /path/to/main clone\n> $ cd clone\n> clone/$ git config remote.origin.fetch \\\n>          '+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'\n\nIf you want to fetch main's local branches also, use option \"--add\" here\nso that you don't override the default fetch refspec (forgot last time,\nsorry).\n\n> clone/$ git fetch\n>  From /path/to/main/\n>   * [new branch]      ThingOne/master -> ThingOne/master \n> \n> clone/$ git pull -s subtree git://thing/ThingOne.git ThingOne/master\n> fatal: Couldn't find remote ref ThingOne/master\n\nbecause on ThingOne there is no such ref.\n\n> The config & fetch commands indeed add a \n> .git/refs/remotes/ThingOne/master file to the clone, but I'm missing the \n> magic words for how to use that ref.\n\nI thought you wanted to avoid pulling directly from ThingOne to clone?\nIf you pull directly you might as well set up the same remote config as\non main: for the correct pull line you need to know the same info as for\nthe correct remote config.\n\ngit fetch\ngit merge -s subtree remotes/ThingOne/master\n\nshould do the trick. If that works you can set up things so that pulling\nfrom origin (pulling when you're in your integration branch) does that\nmerge automatically, using branch.integrationbranch.remote=origin,\nbranch.integrationbranch.merge=remotes/ThingOne/master (untested ;) ).\n\nTo be clear: The idea here is that main decides which ThingOne branch to\nstore in remotes/ThingOne/master and where to get it from; clones always\npull that one.\n\n> Also:\n> \n> Michael J Gruber wrote:\n>>> And actually, git's remote functionality feels a bit crippled if clones \n>>> can't make some use of the origin's remotes.  Is there a reason for \n>>> keeping remote definitions out of a clone?\n>> Say A and B are working on a project C. Then, typically, A is interested\n>> in B's work on C, i.e. some of B's local branches, but not on B's remote\n>>  tracking branches: A tracks a \"central\" C already, just like B does,\n>> and remote tracking branches don't carry any \"value adding\" by the\n>> cloner, they're just a local unmodified copy of the remote.\n> \n> I can appreciate that, but the approach leads to two consequences that I \n> suggest should be avoidable:\n> \n> 1. A and B both have to set up the references to C themselves.  A can't \n> just piggyback on whatever B has already set up.  (This is the impetus \n> for my original message.)\n> \n> 2. Suppose B is just a repository that's being shared between A and D -- \n> i.e. there's no B entity doing any work directly in B.  In this case if \n> A (or D) wants to change B's reference to C (say, to track a new branch \n> in C), they can't: B has to be changed directly, and nothing can be done \n> in a clone to accomplish this.\n> \n> I admit I'm picking at nits here -- obviously someone is able to access \n> the B repo and do whatever needs doing.  I just feel that there are some \n> situations where you want the origin's remotes in your clone, and some \n> where you don't, and git should let you decide.\n\nWell, it let's you decide: It tracks local branches by default, and\nusing additional \"git config\" you can track remotes as well. You can\nalso use the \"--mirror\" option to \"git clone\" or \"git remote add\", but\nthat has other side effects.\n\nCheers,\nMichael\n"},{"id":"93608","messageId":"48FDF28A.9060606@xiplink.com","threadId":"15928","inReplyTo":"48FDA5A0.8030506@drmicha.warpmail.net","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-21T15:17:30Z","receivedAt":"2008-10-21T15:17:30Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Michael J Gruber wrote:\n>\n>> clone/$ git config remote.origin.fetch \\\n>>          '+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'\n> \n> If you want to fetch main's local branches also, use option \"--add\" here\n> so that you don't override the default fetch refspec (forgot last time,\n> sorry).\n\nOkay, got it.\n\n> I thought you wanted to avoid pulling directly from ThingOne to clone?\n\nAh, I see (part of) our disconnect here -- sorry for not explaining it\nclearly before!\n\nYes, indeed, I do want to pull directly from ThingOne into the clone.\n\nThe scenario is that there's a bunch of us sharing the main repo, and\nwhen some upstream changes happen in ThingOne I'd like for one of us to\nbe able to clone the main repo, pull the changes from ThingOne into the \nclone (fixing any conflicts; remember that we have our own changes in \nThingOne's code), then push the merged changes back to main for everyone \nelse to grab.\n\n> If you pull directly you might as well set up the same remote config as\n> on main: for the correct pull line you need to know the same info as for\n> the correct remote config.\n\nYes, I see that -- it's why I'm basically satisfied with being able to do\n\n\tclone/$ git pull -s subtree /path/to/ThingOne master\n\nfrom the clone, and all I'm doing now is kvetching about having to \nremember the location and branch of ThingOne when that was already \nconfigured in main (and thanks for being patient with my kvetching!).\n\n> git fetch\n> git merge -s subtree remotes/ThingOne/master\n> \n> should do the trick.\n\nAFAICT that only refers to the clone's local branch for the ThingOne \nrepo.  The above git-config command doesn't add the ThingOne repo's URL \nto the clone, so I'm still stuck having to use that URL directly to pull \nchanges from ThingOne into the clone.  (And when I use the URL directly, \nI have to use a branch name that's defined in the ThingOne repo.  I'd \nlike to also be able to use whatever branch name got set up in main when \n\"git remote add\" was run.)\n\n> If that works you can set up things so that pulling\n> from origin (pulling when you're in your integration branch) does that\n> merge automatically, using branch.integrationbranch.remote=origin,\n> branch.integrationbranch.merge=remotes/ThingOne/master (untested ;) ).\n> \n> To be clear: The idea here is that main decides which ThingOne branch to\n> store in remotes/ThingOne/master and where to get it from; clones always\n> pull that one.\n\nI think that \"where to get it from\" part is what I'm going on about. \nThere doesn't seem to be a way for the main repo to tell the clone where \nthe ThingOne repo is, so that the clone can pull in ThingOne changes \ndirectly.\n\n>> I just feel that there are some \n>> situations where you want the origin's remotes in your clone, and some \n>> where you don't, and git should let you decide.\n> \n> Well, it let's you decide: It tracks local branches by default, and\n> using additional \"git config\" you can track remotes as well. You can\n> also use the \"--mirror\" option to \"git clone\" or \"git remote add\", but\n> that has other side effects.\n\nI think we're mis-communicating, mainly because I'm not yet able to \nexpress things well in git-speak.  Let me give it another stab...\n\nI believe git lets you track the origin's _branches_ not the origin's \n_remotes_.  I don't think --mirror does what I'm looking for, because \n(side effects aside) it only deals with branches, not remotes.\n\nI find myself getting confused, and I think it's because the files in \n.git/refs/remotes/ are indeed tracking branches on remote repositories. \n  So I think our conversation gets a bit circular because our ideas of a \n\"remote\" differ.\n\n\"git remote add\" does two things (maybe more?): It adds a [remote] \nsection to the .git/config file, and it adds a branch reference in \n.git/refs/remotes/.  I think what I'd like is for the clone to be able \nto obtain both these things from the origin.  The reason I think it's \nuseful is that it would let the clone pull directly from the origin's \nremote repositories, without having to directly specify the remote \nrepository's URL and branch name.\n\nFundamentally, I'm looking to do exactly\n\n\tclone/$ git pull -s subtree /path/to/ThingOne master\n\ni.e. pull stuff from one of main's remotes directly into the clone.  But \nI want to replace the \"/path/to/ThingOne master\" part with something \nthat means \"use whatever URL and branch name was defined in the origin \nfor this remote\".\n\nMy questions are:  Am I right in thinking this is desirable?  Is there \nalready some way to do this?  If not, is it something worth \nimplementing?  (I'm happy to roll up my own sleeves here...)\n\nI hope that clarifies things.  Sorry for taking so long to get here!\n\n\t\tMarc\n"},{"id":"93691","messageId":"48FF3FEE.8020209@drmicha.warpmail.net","threadId":"15928","inReplyTo":"48FDF28A.9060606@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-22T14:59:58Z","receivedAt":"2008-10-22T14:59:58Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Branchaud venit, vidit, dixit 10/21/08 17:17:\n> I believe git lets you track the origin's _branches_ not the origin's \n> _remotes_.  I don't think --mirror does what I'm looking for, because \n> (side effects aside) it only deals with branches, not remotes.\n> \n> I find myself getting confused, and I think it's because the files in \n> .git/refs/remotes/ are indeed tracking branches on remote repositories. \n>   So I think our conversation gets a bit circular because our ideas of a \n> \"remote\" differ.\n\nYes, I think there are multiple uses:\n\n- a remote repository (referenced to by an URL)\n- a remote config (as created by git remote add)\n- a remote branch (a branch in your local repo which is a copy of a\nbranch in a remote repo; stored under refs/remotes, never to be modified\nlocally)\n- a (remote) tracking branch (a local branch which is set up to pull\nfrom a remote branch by default)\n\nOnly the first of these 4 is something resides \"remotely\". Of course,\n\"remote URL\" could be a path on the local file system or even \".\".\n\n> \"git remote add\" does two things (maybe more?): It adds a [remote] \n> section to the .git/config file, and it adds a branch reference in \n> .git/refs/remotes/. \n\nYes.\n\n> I think what I'd like is for the clone to be able \n> to obtain both these things from the origin.  The reason I think it's \n> useful is that it would let the clone pull directly from the origin's \n> remote repositories, without having to directly specify the remote \n> repository's URL and branch name.\n> \n> Fundamentally, I'm looking to do exactly\n> \n> \tclone/$ git pull -s subtree /path/to/ThingOne master\n> \n> i.e. pull stuff from one of main's remotes directly into the clone.  But \n> I want to replace the \"/path/to/ThingOne master\" part with something \n> that means \"use whatever URL and branch name was defined in the origin \n> for this remote\".\n> \n> My questions are:  Am I right in thinking this is desirable? \n\nI've got the strong impression you desire it...\n\nSeriously, it seems desirable in cases where the remote URL changes\nfrequently; say, because the upstream maintainer (maintainer of\nThingOne) gets hit by a bus frequently, or walks the wrong streets in LA\nat the wrong time of the day. (I guess my seriousness ended with the\n\";\".) Clones would follow those changes transparently then (if that\nfeature existed).\n\n> Is there \n> already some way to do this? \n\nNone that I know of.\n\n> If not, is it something worth \n> implementing?  (I'm happy to roll up my own sleeves here...)\n\nFirst you should decide whether it is worth for you. Comments on the\nlist tend to kick in once people see a proposed implementation. A viable\nstrategy could be, mimicking git submodule behaviour in part:\n\n- Implement \"git remote export reponame\" which takes an existing remote\nconfig from .git/config, writes it to .gitremotes and checks in (or\nbetter: stages for commit) the file .gitremotes [you would use this on main]\n\n- Implement \"git remote import\" which reads the file .gitremotes and\nadds remote config to .git/config. [you would use this on clones]\n\n- Change \"git remote update\" to take updates to .gitremotes into account\nbefore doing its usual routine (perhaps based on a config with default\noff, or a command line option, or better both)\n\nDownside is that .gitremotes is tracked would show up as a file in the\nrepo, but I can't come up with a better way which is as simple as the\nabove. .gitremotes could be stored in a specially named branch, though.\n\n> I hope that clarifies things.  Sorry for taking so long to get here!\n\nDon't worry. I take partial blame ;)\nAnd thanks for trying to match up your workflow with git.\n\nCheers,\nMichael\n"},{"id":"93699","messageId":"20081022161302.GC16946@atjola.homenet","threadId":"15928","inReplyTo":"48FF3FEE.8020209@drmicha.warpmail.net","subject":"Terminology question: \"tracking\" branches","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-10-22T16:13:02Z","receivedAt":"2008-10-22T16:13:02Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.10.22 16:59:58 +0200, Michael J Gruber wrote:\n> - a remote branch (a branch in your local repo which is a copy of a\n> branch in a remote repo; stored under refs/remotes, never to be modified\n> locally)\n> - a (remote) tracking branch (a local branch which is set up to pull\n> from a remote branch by default)\n\n(Remote) tracking branches are actually what you called remote branches,\nat least according to the git glossary. But I wonder, what is the right\nterm for a branch that has the --track setup for pull?\n\nOn #git I usually fall back to some variation of \"a branch that is\nconfigured for 'git pull'\" or something similarly verbose (and maybe\nthat's even partially wrong/inaccurate/incomplete?). And I always try to\nstick to saying \"remote tracking branch\" and not just \"tracking branch\"\n(as the glossary does) to avoid confusion as best as I can. But that\nfeels quite suboptimal.\n\nSo, is there some term that describes a local branch that has been\nconfigured for \"git pull\"?\n\nThanks,\nBjörn\n"},{"id":"93763","messageId":"490030AB.8090207@drmicha.warpmail.net","threadId":"15928","inReplyTo":"20081022161302.GC16946@atjola.homenet","subject":"Re: Terminology question: \"tracking\" branches","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-23T08:07:07Z","receivedAt":"2008-10-23T08:07:07Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Björn Steinbrink venit, vidit, dixit 22.10.2008 18:13:\n> On 2008.10.22 16:59:58 +0200, Michael J Gruber wrote:\n>> - a remote branch (a branch in your local repo which is a copy of a\n>> branch in a remote repo; stored under refs/remotes, never to be modified\n>> locally)\n>> - a (remote) tracking branch (a local branch which is set up to pull\n>> from a remote branch by default)\n> \n> (Remote) tracking branches are actually what you called remote branches,\n> at least according to the git glossary. But I wonder, what is the right\n> term for a branch that has the --track setup for pull?\n\nOoops, I'm sorry. I went by the name of the \"--track\" option and was\nsure that that \"git help branch\" used the name \"tracking branch\" for the\nbranches created with \"--track\", but I was wrong. So:\n\n\"(remote) tracking branch\" is a local branch stored under refs/remotes/\nwhich is a \"copy\" of a branch on a remote repository.\n\nThat leaves open:\n\n- What does \"remote branch\" mean, if it means anything at all? It could\nbe used for a branch in a remote repository, i.e. the other side of\nfetch/push refspec (remote branch:tracking branch).\n\n- How to name a local branch created with --track off of a (remote)\ntracking branch? Local tracking branch? Downstream/work/modification branch?\n\nI think that linguistically, the confusion comes from using the noun as\nwell as the adjective \"remote\". As an adjective: \"remote something\"\ncleary is something residing remotely. As a noun it's the config added\nby \"git remote add\".\n\nNote that the glossary doesn't define remote at all. I'd volunteer\nchanging that once the discussion reaches a consensus.\n\nMy suggestion would be:\n\nremote (noun): A configuration as created by \"git remote add\" which\npoints to a remote repository (using a URL) and sets up refspecs for\nfetching and/or pulling. Note that the URL may point to a local\nfilesystem or even \".\". See also remote (adjective).\n\nremote (adjective): Anything residing in another repository. See also\nremote (noun).\n\nlocal: Sometimes used to emphasize things residing \"locally\", i.e. in\nthe repository at hand, as opposed to \"remotely\".\n\ntracking branch: A branch tracking a (remote) branch on a remote\nrepository, i.e. a local branch stored under refs/remotes/ which is a\n\"copy\" of a branch on a remote repository; typically created by \"git\nclone\" or \"git remote add/update\".\n\nremote tracking branch: Synonymous with tracking branch. [remote is a\nnoun, an object for track here]\n\n[adjective to be found] branch: A local branch which is set up to pull\nor rebase automatically from a tracking branch. Used for local\nmodifications to remote branches. [I'm tempted to use local tracking\nbranch here, but that would just add to the confusion.]\n\nCome to think of it: \"Off-track\" branch would be the ideal name for a\nlocal branch created off of a (remote) tracking branch, using --track to\nspecify the track where things go off. But I'm not sure everyone would\nlike the implied pun...\n\nCheers,\nMichael\n"},{"id":"94056","messageId":"4905E1B0.8040601@xiplink.com","threadId":"15928","inReplyTo":"490030AB.8090207@drmicha.warpmail.net","subject":"Re: Terminology question: \"tracking\" branches","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-27T15:43:44Z","receivedAt":"2008-10-27T15:43:44Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Michael J Gruber wrote:\n> \n> remote tracking branch: Synonymous with tracking branch. [remote is a\n> noun, an object for track here]\n\nEr, \"remote\" is an adjective there...  :)\n\n> [adjective to be found] branch: A local branch which is set up to pull\n> or rebase automatically from a tracking branch. Used for local\n> modifications to remote branches. [I'm tempted to use local tracking\n> branch here, but that would just add to the confusion.]\n\nI say there's no need for an adjective here, as this is just a plain old \nbranch that git-branch creates by default (right?).\n\nWhat's needed is an adjective for when git-branch is given the \n--no-track option (or when branch.automergesetup is false). \n\"Non-tracking branch\" perhaps?\n\n\t\tMarc\n"},{"id":"94057","messageId":"20081027161736.GJ3612@atjola.homenet","threadId":"15928","inReplyTo":"4905E1B0.8040601@xiplink.com","subject":"Re: Terminology question: \"tracking\" branches","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-10-27T16:17:36Z","receivedAt":"2008-10-27T16:17:36Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.10.27 11:43:44 -0400, Marc Branchaud wrote:\n> Michael J Gruber wrote:\n>>\n>> remote tracking branch: Synonymous with tracking branch. [remote is a\n>> noun, an object for track here]\n>\n> Er, \"remote\" is an adjective there...  :)\n\nHm? It's a \"branch that tracks (a branch of) a remote\". Looks like a\nnoun to me.\n\n>> [adjective to be found] branch: A local branch which is set up to pull\n>> or rebase automatically from a tracking branch. Used for local\n>> modifications to remote branches. [I'm tempted to use local tracking\n>> branch here, but that would just add to the confusion.]\n>\n> I say there's no need for an adjective here, as this is just a plain old  \n> branch that git-branch creates by default (right?).\n\nBy default, no. It depends on the branch.automergesetup configuration\nand whether you create the branch from a remote tracking branch, a local\nbranch or some other committish.\n\nautosetupmerge = false\n----\ngit branch foo origin/foo   --> --no-track\ngit branch foo master       --> --no-track\ngit branch foo origin/foo^0 --> --no-track\n\nautosetupmerge = true\n----\ngit branch foo origin/foo   --> --track\ngit branch foo master       --> --no-track\ngit branch foo origin/foo^0 --> --no-track\n\nautosetupmerge = always\n----\ngit branch foo origin/foo   --> --track\ngit branch foo master       --> --track\ngit branch foo origin/foo^0 --> --no-track\n\n> What's needed is an adjective for when git-branch is given the  \n> --no-track option (or when branch.automergesetup is false).  \n> \"Non-tracking branch\" perhaps?\n\nIsn't that easily confused with \"[remote] tracking branch\"? Especially\nsince the \"remote\" is optional...\n\nBjörn\n"},{"id":"94058","messageId":"20081027162840.GK3612@atjola.homenet","threadId":"15928","inReplyTo":"490030AB.8090207@drmicha.warpmail.net","subject":"Re: Terminology question: \"tracking\" branches","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-10-27T16:28:40Z","receivedAt":"2008-10-27T16:28:40Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.10.23 10:07:07 +0200, Michael J Gruber wrote:\n> That leaves open:\n> \n> - What does \"remote branch\" mean, if it means anything at all? It could\n> be used for a branch in a remote repository, i.e. the other side of\n> fetch/push refspec (remote branch:tracking branch).\n\nI prefer to say \"the branch on the remote\" there, but that's just to\navoid confusion with \"remote tracking branch\".\n\n> - How to name a local branch created with --track off of a (remote)\n> tracking branch? Local tracking branch? Downstream/work/modification branch?\n\nYou can also have a local branch that \"--track\"s another local branch,\nso those names look a bit suboptimal to me, but I don't have any better\nideas either :-/ For a second I thought about \"pulling branch\" but that\ndoesn't really describe it either, I guess...\n\n> I think that linguistically, the confusion comes from using the noun as\n> well as the adjective \"remote\". As an adjective: \"remote something\"\n> cleary is something residing remotely. As a noun it's the config added\n> by \"git remote add\".\n> \n> Note that the glossary doesn't define remote at all. I'd volunteer\n> changing that once the discussion reaches a consensus.\n> \n> My suggestion would be:\n> \n> remote (noun): A configuration as created by \"git remote add\" which\n> points to a remote repository (using a URL) and sets up refspecs for\n> fetching and/or pulling. Note that the URL may point to a local\n> filesystem or even \".\". See also remote (adjective).\n> \n> remote (adjective): Anything residing in another repository. See also\n> remote (noun).\n> \n> local: Sometimes used to emphasize things residing \"locally\", i.e. in\n> the repository at hand, as opposed to \"remotely\".\n> \n> tracking branch: A branch tracking a (remote) branch on a remote\n> repository, i.e. a local branch stored under refs/remotes/ which is a\n> \"copy\" of a branch on a remote repository; typically created by \"git\n> clone\" or \"git remote add/update\".\n> \n> remote tracking branch: Synonymous with tracking branch. [remote is a\n> noun, an object for track here]\n\nThose look good, to me at least.\n\n> [adjective to be found] branch: A local branch which is set up to pull\n> or rebase automatically from a tracking branch.\n\n\"merge or rebase\", and instead of \"tracking\" it should be \"another\" I\nthink. Again, because you can also --track a local branch.\n\n> Used for local modifications to remote branches. [I'm tempted to use\n> local tracking branch here, but that would just add to the confusion.]\n\nSame here, it doesn't apply to \"remote branches\" only.\n\n> Come to think of it: \"Off-track\" branch would be the ideal name for a\n> local branch created off of a (remote) tracking branch, using --track to\n> specify the track where things go off. But I'm not sure everyone would\n> like the implied pun...\n\nHaha :-)\n\nthanks,\nBjörn\n"},{"id":"94064","messageId":"alpine.DEB.1.00.0810271654530.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15928","inReplyTo":"4905E1B0.8040601@xiplink.com","subject":"Re: Terminology question: \"tracking\" branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-27T18:44:34Z","receivedAt":"2008-10-27T18:44:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 27 Oct 2008, Marc Branchaud wrote:\n\n> Michael J Gruber wrote:\n> > \n> > [adjective to be found] branch: A local branch which is set up to pull \n> > or rebase automatically from a tracking branch. Used for local \n> > modifications to remote branches. [I'm tempted to use local tracking \n> > branch here, but that would just add to the confusion.]\n> \n> I say there's no need for an adjective here, as this is just a plain old\n> branch that git-branch creates by default (right?).\n\nI agree; I do not think that you need an adjective here.\n\nI'd also recommend thinking about the branches as \"local\" and \"remote\".  \nNot anything with \"tracking\" or \"trailing\" or somesuch.  When you really \nlook at it from the non-technical view point, even the branches you have \nin refs/remotes/*/ are the remote branches; the fact that you have a local \ncached version of them is just a minor implementation detail.\n\nAnd as to the \"--track\" thing?  I'd not make that big a deal out of it.  \nAt most, I'd say that a certain local branch happens to follow a certain \nremote branch, but that can change over time, right?  (Just change \nbranch.<name>.merge...)\n\nCiao,\nDscho\n"},{"id":"94074","messageId":"49061C6D.2070407@xiplink.com","threadId":"15928","inReplyTo":"48FF3FEE.8020209@drmicha.warpmail.net","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-27T19:54:21Z","receivedAt":"2008-10-27T19:54:21Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Michael J Gruber wrote:\n> \n> First you should decide whether it is worth for you.\n\nI'm still trying to figure that out...\n\n> Comments on the\n> list tend to kick in once people see a proposed implementation. A viable\n> strategy could be, mimicking git submodule behaviour in part:\n> \n> - Implement \"git remote export reponame\" which takes an existing remote\n> config from .git/config, writes it to .gitremotes and checks in (or\n> better: stages for commit) the file .gitremotes [you would use this on main]\n> \n> - Implement \"git remote import\" which reads the file .gitremotes and\n> adds remote config to .git/config. [you would use this on clones]\n> \n> - Change \"git remote update\" to take updates to .gitremotes into account\n> before doing its usual routine (perhaps based on a config with default\n> off, or a command line option, or better both)\n> \n> Downside is that .gitremotes is tracked would show up as a file in the\n> repo, but I can't come up with a better way which is as simple as the\n> above. .gitremotes could be stored in a specially named branch, though.\n\nThat downside is a bit disappointing.  I might as well just make \"git \nremote export\" simply generate a script of \"git remote add\" commands \nbased on the contents of .git/config, and check that script in.  Then I \ncould run the script in a clone to recreate the origin's remotes.\n\nIt also seems awkward to have an export step in the origin repository. \nI don't really see a need for an export step (except as an artifact of \nthe above implementation).\n\nIt seems to me that this would be more natural if our hypothetical \"git \nremote import <X>\" could just grab the remotes from repository <X> (or \nthe origin, if <X> is unspecified).  I assume that would involve \nlower-level changes than what you described, but to me it seems like the \nmore usable approach.  (But then I know nothing of Git's internals, so \nmaybe this kind of change would be too much work?)\n\n\t\tMarc\n"},{"id":"94095","messageId":"20081028080102.GL3612@atjola.homenet","threadId":"15928","inReplyTo":"20081027162840.GK3612@atjola.homenet","subject":"Re: Terminology question: \"tracking\" branches","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-10-28T08:01:02Z","receivedAt":"2008-10-28T08:01:02Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.10.27 17:28:40 +0100, Björn Steinbrink wrote:\n> On 2008.10.23 10:07:07 +0200, Michael J Gruber wrote:\n> > That leaves open:\n> > \n> > - What does \"remote branch\" mean, if it means anything at all? It could\n> > be used for a branch in a remote repository, i.e. the other side of\n> > fetch/push refspec (remote branch:tracking branch).\n> \n> I prefer to say \"the branch on the remote\" there, but that's just to\n> avoid confusion with \"remote tracking branch\".\n\nSo I just happened to use \"git remote show origin\" and that uses \"remote\nbranch\" as you described it:\n\n* remote origin\n  URL: git://git.kernel.org/pub/scm/git/git.git\n  Remote branch merged with 'git pull' while on branch master\n    master\n  Tracked remote branches\n    html\n    maint\n    ...\n\nJFYI\nBjörn\n"},{"id":"94096","messageId":"4906C957.9010304@drmicha.warpmail.net","threadId":"15928","inReplyTo":"49061C6D.2070407@xiplink.com","subject":"Re: Working with remotes; cloning remote references","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-28T08:12:07Z","receivedAt":"2008-10-28T08:12:07Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Branchaud venit, vidit, dixit 27.10.2008 20:54:\n> Michael J Gruber wrote:\n>> Downside is that .gitremotes is tracked would show up as a file in the\n>> repo, but I can't come up with a better way which is as simple as the\n>> above. .gitremotes could be stored in a specially named branch, though.\n> \n> That downside is a bit disappointing.  I might as well just make \"git \n> remote export\" simply generate a script of \"git remote add\" commands \n> based on the contents of .git/config, and check that script in.  Then I \n> could run the script in a clone to recreate the origin's remotes.\n\nYes, if you feel okay about running a script repeatedly which may change\ndue to being versioned; rather than running a script/command which uses\nversioned input.\n\n> It also seems awkward to have an export step in the origin repository. \n> I don't really see a need for an export step (except as an artifact of \n> the above implementation).\n\nI had the impression that you want to configure as much as possible on\nthe \"central\", and have clones follow automatically. It's very likely\nthat you want your clones to see only a subset of central's remotes.\nBoth (individually) imply that there has to be a step on central which\ndetermines which (if any) central remotes appear in clones automatically.\n\n> It seems to me that this would be more natural if our hypothetical \"git \n> remote import <X>\" could just grab the remotes from repository <X> (or \n> the origin, if <X> is unspecified).  I assume that would involve \n> lower-level changes than what you described, but to me it seems like the \n> more usable approach.  (But then I know nothing of Git's internals, so \n> maybe this kind of change would be too much work?)\n\nFeel free to hack the protocol and remote commands... Implementing\nanything which exposes \"server's\" .git/config on the client without\ninteraction on the server side will most probably be rejected, though.\nMy suggestions were meant to be a minimal effort attempt within and\nfollowing (see submodules) current infrastructure. I guess now it's up\nto you to pick the approach you deem most appropriate in your scenario\nand follow through with it.\n\nMichael\n"},{"id":"94119","messageId":"49073D86.40507@xiplink.com","threadId":"15928","inReplyTo":"4906C957.9010304@drmicha.warpmail.net","subject":"Re: Working with remotes; cloning remote references","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2008-10-28T16:27:50Z","receivedAt":"2008-10-28T16:27:50Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Michael J Gruber wrote:\n>\n>> That downside is a bit disappointing.  I might as well just make \"git \n>> remote export\" simply generate a script of \"git remote add\" commands \n>> based on the contents of .git/config, and check that script in.  Then I \n>> could run the script in a clone to recreate the origin's remotes.\n> \n> Yes, if you feel okay about running a script repeatedly which may change\n> due to being versioned; rather than running a script/command which uses\n> versioned input.\n\nEither way it's a two-step process: \"git pull; git remote import\" vs. \n\"git pull; ./import-remotes.sh\".\n\n>> It also seems awkward to have an export step in the origin repository. \n>> I don't really see a need for an export step (except as an artifact of \n>> the above implementation).\n> \n> I had the impression that you want to configure as much as possible on\n> the \"central\", and have clones follow automatically. It's very likely\n> that you want your clones to see only a subset of central's remotes.\n> Both (individually) imply that there has to be a step on central which\n> determines which (if any) central remotes appear in clones automatically.\n\nI actually don't care to limit what the clones can see.  I understand \nthe reasoning behind such control, but in my case it just doesn't apply.\n\n>> It seems to me that this would be more natural if our hypothetical \"git \n>> remote import <X>\" could just grab the remotes from repository <X> (or \n>> the origin, if <X> is unspecified).  I assume that would involve \n>> lower-level changes than what you described, but to me it seems like the \n>> more usable approach.  (But then I know nothing of Git's internals, so \n>> maybe this kind of change would be too much work?)\n> \n> Feel free to hack the protocol and remote commands... Implementing\n> anything which exposes \"server's\" .git/config on the client without\n> interaction on the server side will most probably be rejected, though.\n\nPoint taken, but I think I will start with no origin-side controls, \nsince I have no need for them anyway.  If/when I cobble together a patch \nhopefully at that point we'll be able to have a wider discussion about \nsuch controls.\n\n> My suggestions were meant to be a minimal effort attempt within and\n> following (see submodules) current infrastructure. I guess now it's up\n> to you to pick the approach you deem most appropriate in your scenario\n> and follow through with it.\n\nMany thanks for taking the time to discuss this.  Now I've got to roll \nup my sleeves!\n\n(BTW, any pointers to descriptions or overviews of git's code base?)\n\n\t\tMarc\n"}]}