{"thread":{"id":"2348","subject":"[PATCH] Cogito: Support for implicit remote branches in cloned repositories","startedAt":"2005-11-04T16:01:48Z","lastAt":"2005-11-08T16:46:20Z","messageCount":10,"participants":["Josef Weidendorfer","Junio C Hamano","Petr Baudis","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"11130","messageId":"200511041701.48881.Josef.Weidendorfer@gmx.de","threadId":"2348","inReplyTo":null,"subject":"[PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-04T16:01:48Z","receivedAt":"2005-11-04T16:01:48Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"This allows to specify remote branch names from the\nrepository this one was cloned from (= remote repository of\n\"origin\" branch), without explicitly adding a branch for them.\nTherefore, these remote branches are called implicit.\n\nUse them together with cg-fetch or cg-update.\nExample: Your current repository was cloned with\n\n  cg-clone git+ssh://remotehost:/path myrep\n\nIf this remote repository contains a branch \"foo\",\nyou can say inside of myrep:\n\n  cg-fetch foo\n\nThis fetches \"git+ssh://remotehost:/path#foo\" into\na local branch \"foo\" (created if not existing).\nSimilarily, a \"cg-update foo\" will fetch the remote\nbranch and merge it into your current local branch.\n\nAfter fetching from an implicit remote branch, cg-status\nwill show the corresponding local branch, but still without\nan \"R\", because that is only shown for explicit branches.\nThe implicit remote branch in the example above can be\nmade explicit with\n\n  cg-branch-add foo git+ssh://remotehost:/path#foo\n\nNote that cg-update now always tries to fetch from a\nremote repository, as every non-explicit branch\nname is supposed to be an implicit remote branch.\n\nSigned-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>\n\n---\n\nThis patch is RFC. IMHO, it simplifies the usage of Cogito\nquite a lot. One difference of cloning with GIT vs. with\nCogito is that Git always clones all remote branches. This can\nbe limiting if you want to work with multiple repositories,\nbut allows you to immediatly work with all the branches.\n\nCogito instead clones only one remote branch, and requires\nyou to explicitly add further branches with \"cg-branch-add\".\nThis is not necessary with implicit remote branches, and\nthey should cover the standard use case which works with\nbranches from the repository you clone from.\n\nThe nice thing here is that the patch is really small for\nthe added functionality. If you accept it, I will provide\nupdates for the documentation and tutorial.\n\nJosef\n\n cg-fetch  |   10 +++++++++-\n cg-update |    6 +-----\n 2 files changed, 10 insertions(+), 6 deletions(-)\n\napplies-to: 22948869bcf0ec216ed9aa14e1c5ecc22114d66b\n769aa2148fc2b583b071354e8eef3dae74e09c14\ndiff --git a/cg-fetch b/cg-fetch\nindex 759488a..5a5aeb1 100755\n--- a/cg-fetch\n+++ b/cg-fetch\n@@ -262,7 +262,15 @@ name=${ARGS[0]}\n \n [ \"$name\" ] || { [ -s \"$_git/branches/origin\" ] && name=origin; }\n [ \"$name\" ] || die \"where to fetch from?\"\n-uri=$(cat \"$_git/branches/$name\" 2>/dev/null) || die \"unknown branch: $name\"\n+uri=$(cat \"$_git/branches/$name\" 2>/dev/null) || \\\n+    { if [ -s \"$_git/branches/origin\" ]; then\n+\turi=$(cat \"$_git/branches/origin\" 2>/dev/null)\n+\turi=\"$(echo \"$uri\" | cut -d '#' -f 1)#$name\"\n+\techo Fetching implicit remote branch \"$uri\".\n+      else\n+        die \"unknown branch: $name\"\n+      fi\n+    }\n \n rembranch=\n if echo \"$uri\" | grep -q '#'; then\ndiff --git a/cg-update b/cg-update\nindex 96035c5..534bf4a 100755\n--- a/cg-update\n+++ b/cg-update\n@@ -39,11 +39,7 @@ name=${ARGS[0]}\n [ \"$name\" ] || { [ -s $_git/branches/origin ] && name=origin; }\n [ \"$name\" ] || die \"where to update from?\"\n \n-if [ -s \"$_git/branches/$name\" ]; then\n-\tcg-fetch $force $name || exit 1\n-else\n-\techo \"Updating from a local branch.\"\n-fi\n+cg-fetch $force $name || exit 1\n echo\n echo \"Applying changes...\"\n cg-merge $name\n"},{"id":"11138","messageId":"7vvez8wbpz.fsf@assigned-by-dhcp.cox.net","threadId":"2348","inReplyTo":"200511041701.48881.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-04T17:43:04Z","receivedAt":"2005-11-04T17:43:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> ... One difference of cloning with GIT vs. with\n> Cogito is that Git always clones all remote branches. This can\n> be limiting if you want to work with multiple repositories,\n> but allows you to immediatly work with all the branches.\n\nThree points, and two footnotes.\n\n. After a git clone, you can still fetch from non-origin\n  repository; you can also set up .git/remotes/somewhere-else if\n  you pull from the non-origin repository regularly, so it is\n  not really \"limiting\".  It is just being slightly less\n  convenient, in that setting up for the origin is done for you\n  by clone [*1*] while you have to arrange for non-origin\n  repository yourself afterwards.\n\n. The namespace under refs/heads is and always will be an issue.\n  It is a local matter and how remote branches are named should\n  not dictate what local branch names you can use in your\n  repository, but that essentially is what happens after\n  git-clone to users who do not rename those branches from the\n  initial cloning.\n\n  I once considered to give an option to clone to map the origin\n  heads to .git/refs/heads/origin/{master,maint,pu,...}.  In\n  hindsight that might have been cleaner.  Instead I just followed\n  what Cogito already established, and mapped remote \"master\" to\n  \"origin\".\n\n. The namespace under refs/tags theoretically also has the same\n  issue, but I suspect it would not matter too much in practice.\n  The tags people fetches from remote tend to be release-point\n  tags (e.g. v2.6.14) whose names implicitly follow an obvious\n  (to humans) naming convention; when you name your temporary\n  anchor points using lightweight tags, you can easily avoid\n  name clashes with those \"for other people\" tags [*2*].\n\n[Footnotes]\n\n*1* Actually, even the setting up for the origin is done only\nhalfway -- it only arranges 'git fetch/pull' to fetch from the\nmaster branch, and other branches are not tracked unless you\nexplicitly arrange them to be.  This is somewhat deliberate; the\nrefs/ namespace management is a local matter and you do not\nnecessarily want to keep tracking all the branches from origin.\n\n*2* This becomes somewhat problematic when the tool\nautomatically follows/fetches tags, and that is why git-core\nbarebone Porcelainish requires an explicit 'git fetch --tags'.\n"},{"id":"11141","messageId":"200511041938.34299.Josef.Weidendorfer@gmx.de","threadId":"2348","inReplyTo":"7vvez8wbpz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-04T18:38:34Z","receivedAt":"2005-11-04T18:38:34Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 04 November 2005 18:43, Junio C Hamano wrote:\n> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n> \n> > ... One difference of cloning with GIT vs. with\n> > Cogito is that Git always clones all remote branches. This can\n> > be limiting if you want to work with multiple repositories,\n> > but allows you to immediatly work with all the branches.\n> \n> Three points, and two footnotes.\n> \n> . After a git clone, you can still fetch from non-origin\n>   repository; you can also set up .git/remotes/somewhere-else if\n>   you pull from the non-origin repository regularly, so it is\n>   not really \"limiting\".\n\nWith \"limiting\" I only meant the fact that all the refs/heads names are\ncopied over, thus polluting your local namespace. Additionally, it can\nbe some transfer burden to copy all the objects instead only the objects\nneeded for one head.\n\nCogito does not have an issue with pollution of refs/heads namespace\nas it only clones one head to the special \"origin\" head [*1*].\nBut as I said, the Git way can be more convenient. I think that the\nproposed \"implicit remote branches\" are a way between: make it convenient\nfor Cogito users to fast access branches from the origin repository, but\npollute the name space only \"a little\".\n\n[*1*] Still, it would be nice to specify the name of the branch tracking\nthe origin repository via on option in cg-clone (defaulting to \"origin\"),\nand to also be able to specify the head which is branched off and you\nare put on after cloning (defaulting to \"master\"); but I do not think\nthere is much use to such flexibility.\n\n>   It is just being slightly less \n>   convenient, in that setting up for the origin is done for you\n>   by clone [*1*] while you have to arrange for non-origin\n>   repository yourself afterwards.\n\nI do not think there is much difference in editing files under\n.git/remotes, or using cg-branch-add.\n\n> . The namespace under refs/heads is and always will be an issue.\n>   It is a local matter and how remote branches are named should\n>   not dictate what local branch names you can use in your\n>   repository, but that essentially is what happens after\n>   git-clone to users who do not rename those branches from the\n>   initial cloning.\n\nYes, and that is nice about Cogito.\n\n>   I once considered to give an option to clone to map the origin\n>   heads to .git/refs/heads/origin/{master,maint,pu,...}.  In\n>   hindsight that might have been cleaner.  Instead I just followed\n>   what Cogito already established, and mapped remote \"master\" to\n>   \"origin\".\n\nThat is a nice idea. What is the exact compatiblity problem with Cogito\nhere? Either a repository is cloned with Git or with Cogito, and\nafterwards, both should be able to cope with any naming scheme.\n\nBoth Git and Cogito do setup local \"master\" for local work after cloning.\nTo still be able to track a remote \"master\", this is mapped to local\n\"origin\". Am I right here?\nWhat happens if the remote side itself has an \"origin\" head?\n\n> [Footnotes]\n> \n> *1* Actually, even the setting up for the origin is done only\n> halfway -- it only arranges 'git fetch/pull' to fetch from the\n> master branch, and other branches are not tracked unless you\n> explicitly arrange them to be.  This is somewhat deliberate; the\n> refs/ namespace management is a local matter and you do not\n> necessarily want to keep tracking all the branches from origin.\n\nYes. I do not see any problem here with explicitly specifying a\nhead you want to track in \"git fetch origin <head>\". Still, I would\nnot call this syntax 'porcelainish'.\n\nBut we have Cogito for this.\n\n> *2* This becomes somewhat problematic when the tool\n> automatically follows/fetches tags, and that is why git-core\n> barebone Porcelainish requires an explicit 'git fetch --tags'.\n\nAh, ok.\n\nJosef\n"},{"id":"11148","messageId":"20051104210820.GM1431@pasky.or.cz","threadId":"2348","inReplyTo":"7vvez8wbpz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-04T21:08:20Z","receivedAt":"2005-11-04T21:08:20Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 04, 2005 at 06:43:04PM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n>   I once considered to give an option to clone to map the origin\n>   heads to .git/refs/heads/origin/{master,maint,pu,...}.  In\n>   hindsight that might have been cleaner.  Instead I just followed\n>   what Cogito already established, and mapped remote \"master\" to\n>   \"origin\".\n\nWell, that obviously works only when you resign on the workflow where\npull means fetch + merge, since your local master would conflict with\nthe remote master, therefore having nowhere to store the remote master.\n\n> . The namespace under refs/tags theoretically also has the same\n>   issue, but I suspect it would not matter too much in practice.\n>   The tags people fetches from remote tend to be release-point\n>   tags (e.g. v2.6.14) whose names implicitly follow an obvious\n>   (to humans) naming convention; when you name your temporary\n>   anchor points using lightweight tags, you can easily avoid\n>   name clashes with those \"for other people\" tags [*2*].\n\nI still believe we need the notion of private tags which shouldn't be\ncloned.\n\nHmm. Wait.\n\nAll right. git-update-server-info ignores hidden refs, but referencing a\nhidden ref works all right (unsurprisingly). So let's just codify that\nprivate tags which shan't be fetched (unless requested explicitly) start\nwith a dot (/^\\./) and we are all set...?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11154","messageId":"7voe50rskh.fsf@assigned-by-dhcp.cox.net","threadId":"2348","inReplyTo":"20051104210820.GM1431@pasky.or.cz","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-04T21:50:22Z","receivedAt":"2005-11-04T21:50:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> I still believe we need the notion of private tags which shouldn't be\n> cloned.\n\nI agree with you violently.  I just do not know what is the\nright convention to tell which is private and which is not.\n\nFetching used to be a different matter, because we did not do\n'git-fetch --tags' for a reason: you do not have any business\nwith my tags unless I tell you about them.  But now we tell\nothers about what tags we have, so...\n\n> All right. git-update-server-info ignores hidden refs, but referencing a\n> hidden ref works all right (unsurprisingly). So let's just codify that\n> private tags which shan't be fetched (unless requested explicitly) start\n> with a dot (/^\\./) and we are all set...?\n\nExcept that I suspect refs.c::check_ref_format() will barf on it\ninstead of ignoring it, and obviously you would want it to do\ntwo different things depending on what kind of operation you are\ndoing.  You for example would want to change git-branch or\ngit-tag not to refuse creating such \"private\" tag.  You would\nstill want git-upload-pack to show it to the other end, for\nbetter common commit computation purposes, especially if the tag\nis of lightweight kind, but would want git-clone to ignore\nthem.  It should be doable but we first need a plan.\n"},{"id":"11156","messageId":"Pine.LNX.4.64.0511041359050.28804@g5.osdl.org","threadId":"2348","inReplyTo":"7voe50rskh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-04T22:07:48Z","receivedAt":"2005-11-04T22:07:48Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 4 Nov 2005, Junio C Hamano wrote:\n> \n> I agree with you violently.  I just do not know what is the\n> right convention to tell which is private and which is not.\n\nI don't like the dot idea, but it certainly _would_ make sense to have a \nlocal prefix.\n\nWe could even make it a _totally_ different namespace:\n\n\t.git/refs/local/heads\n\t.git/refs/local/tags\n\nwhich means that even if you call a local head the same thing as a global \none, both can still exist.\n\nThen, make \"origin\" always be a local head.\n\nThat avoids the issue of the remote repo _also_ having an \"origin\" branch.\n\nLocally, the \"local\" heads would always take precedence, with this trivial \npatch making sure of that.. \n\nIf you want to access a global tag or head, you can always do so by using \nthe full path (\"refs/tags/tagname\" is the global one, but \"tags/tagname\" \nor \"tagname\" would be the local one if one exists).\n\n\t\tLinus\n\n---\ndiff --git a/sha1_name.c b/sha1_name.c\nindex be1755a..5daaa11 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -231,6 +231,8 @@ static int get_sha1_basic(const char *st\n \tstatic const char *prefix[] = {\n \t\t\"\",\n \t\t\"refs\",\n+\t\t\"refs/local/tags\",\n+\t\t\"refs/local/heads\",\n \t\t\"refs/tags\",\n \t\t\"refs/heads\",\n \t\tNULL\n"},{"id":"11189","messageId":"7v8xw216q9.fsf@assigned-by-dhcp.cox.net","threadId":"2348","inReplyTo":"Pine.LNX.4.64.0511041359050.28804@g5.osdl.org","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T09:11:10Z","receivedAt":"2005-11-06T09:11:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I don't like the dot idea, but it certainly _would_ make sense to have a \n> local prefix.\n>\n> We could even make it a _totally_ different namespace:\n>\n> \t.git/refs/local/heads\n> \t.git/refs/local/tags\n>\n> which means that even if you call a local head the same thing as a global \n> one, both can still exist.\n>\n> Then, make \"origin\" always be a local head.\n\nWhile that is logically the right thing to do, it is somewhat\nconfusing to see all those branch heads we obtained from the\nremote side stored as our \"local\" branches -- meaning they are\nprivate to us.\n\nJust for discussion, I'd suggest a less structured approach as\nan alternative, and making it just a convention.\n\n - clone by default [*1*] creates .git/refs/heads/origin/*\n   heads; your \"master\" becomes my \"origin/master\".\n   Interestingly but logically, if your repository was cloned\n   from somewhere else, you would have \"origin/master\", which\n   would become my \"origin/origin/master\".\n\n - clone creates remotes/origin that knows all branches from the\n   origin as copied by the above process, as suggested by Daniel\n   in the other thread.\n\nThen we would have a recommended workflow example that uses\norigin/* as reference branches after they are set up.  After\nbecoming familiar with this setup, when people fetch/pull from\nmore than one repository, they can configure things correctly by\nemulating what clone did to the \"origin\" remote repository for\nthem.\n\n[Footnote]\n\n*1* I say \"by default\" here; I think there should be an\noperating mode for git clone that acts as a straight copy, not\neven the current \"HEAD\" -> \"origin\" renaming.  In fact that is\nwhat you do with low-level git-clone-pack.\n"},{"id":"11282","messageId":"20051107232122.GZ1431@pasky.or.cz","threadId":"2348","inReplyTo":"7v8xw216q9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-07T23:21:22Z","receivedAt":"2005-11-07T23:21:22Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Nov 06, 2005 at 10:11:10AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Just for discussion, I'd suggest a less structured approach as\n> an alternative, and making it just a convention.\n\nThe problem is that at least Cogito defaults to the 'origin' branch when\npulling/merging, so if you'll have 'origin/master' instead of 'origin',\nI will have to hack that around. So it's not _just_ a convention but\nsomething reflected in some code as well.\n\n>  - clone by default [*1*] creates .git/refs/heads/origin/*\n>    heads; your \"master\" becomes my \"origin/master\".\n>    Interestingly but logically, if your repository was cloned\n>    from somewhere else, you would have \"origin/master\", which\n>    would become my \"origin/origin/master\".\n\nThis loses the pretty nice property that 'origin' refers to the HEAD\nbranch of the remote repository, no matter how is it called (well, it is\nnice as long as the remote repository doesn't _switch_ the HEAD to some\nnon-superset branch; but repositories you're cloning from shouldn't do\nthat). So you should either have origin/HEAD locally, or make the\n'master' branch more \"socially canonical\".\n\n> *1* I say \"by default\" here; I think there should be an\n> operating mode for git clone that acts as a straight copy, not\n> even the current \"HEAD\" -> \"origin\" renaming.  In fact that is\n> what you do with low-level git-clone-pack.\n\nWhat would it be useful for?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11284","messageId":"7vhdaoqaxb.fsf@assigned-by-dhcp.cox.net","threadId":"2348","inReplyTo":"20051107232122.GZ1431@pasky.or.cz","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-07T23:45:52Z","receivedAt":"2005-11-07T23:45:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> This loses the pretty nice property that 'origin' refers to the HEAD\n> branch of the remote repository,...\n\nI think the code actually honors what your HEAD points at;\nI did not go into that detail in the above description.\n\n>> *1* I say \"by default\" here; I think there should be an\n>> operating mode for git clone that acts as a straight copy, not\n>> even the current \"HEAD\" -> \"origin\" renaming.  In fact that is\n>> what you do with low-level git-clone-pack.\n>\n> What would it be useful for?\n\nCheap back-up, Linus style.\n"},{"id":"11329","messageId":"200511081746.20348.Josef.Weidendorfer@gmx.de","threadId":"2348","inReplyTo":"20051107232122.GZ1431@pasky.or.cz","subject":"Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-08T16:46:20Z","receivedAt":"2005-11-08T16:46:20Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 08 November 2005 00:21, Petr Baudis wrote:\n> The problem is that at least Cogito defaults to the 'origin' branch when\n> pulling/merging, so if you'll have 'origin/master' instead of 'origin',\n> I will have to hack that around. So it's not _just_ a convention but\n> something reflected in some code as well.\n\nThe new git-clone simply would not produce an \"origin\" branch at all, and I do\nnot think Cogito expects that a repository always has an \"origin\" branch.\n\nThe following fact (Git's default clone setup until now, Cogito's clone setup)\n\n\t\"origin\" tracks remote \"master\", to be merged into local \"master\"\n\nhas to be stored into some configuration file, and not to be set up implicitly\nas it is done currently. Then you take this setup from the configuration, and\nthere never would be something hardcoded, and Junios suggestion would be a\nconvention.\n\nGit already stores half of this into remotes/repo: the \"Pull\" lines specify\nwhich local head tracks which remote head; the same with Cogito's .git/branches.\nMissing in both cases is the information that \"origin\" maps to the local\ndevelopment head \"master\". More common name for this information: \"origin\" is\nthe upstream for \"master\".\n\nThis information is useful at least for two cases:\n(1) for specifying the default action to be done on \"git-pull\" or \"cg-update\",\nand (2) try to prohibit accidental bogus merges.\n\nThe default action currently is either hardcoded (Cogito) or working somehow\nby luck (Git: you have to be on \"master\" for git-pull).\nAFAIK, Cogito prohibits bogus merges by enforcing to be either on \"master\"\nor to be in a not-mergeable state (cg-seeking).\n\nMerge relationship is useful to be specified not only for upstream direction,\nbut also for branches which branched off the current head and should be\nmerged back (e.g. topical branches). For this, multiple branches to be\nmerged with \"git pull\" should be specifyable.\n\nWhere to put the information about default merge relation?\n\nBoth .git/remotes and .git/branches are candidates, but merge relation\nalso makes sense for local branches, i.e. git-branch <branch> <origbranch>\nshould set up to merge from <origbranch> if you are on <branch> by default.\nSimilarly, it should set up a relation the other way to state that it is\nuseful to merge from <branch> into <origbranch> (this is for (2) above).\n\nA possiblity would be to put the merge relationship into .git/config:\n\n[master]\nmerge-canditate: origin\nmerge-default: origin\n\nProblem here is that head names should not appear in key names,\nbecause key names are case insensitive :-(\nA possibility would be for config keys to become case sensitive after a \":\"\n(of course only for toplevel keys):\n\n[head:master]\nmerge-default: origin\n\n> >  - clone by default [*1*] creates .git/refs/heads/origin/*\n> >    heads; your \"master\" becomes my \"origin/master\".\n> >    Interestingly but logically, if your repository was cloned\n> >    from somewhere else, you would have \"origin/master\", which\n> >    would become my \"origin/origin/master\".\n> \n> This loses the pretty nice property that 'origin' refers to the HEAD\n> branch of the remote repository, no matter how is it called (well, it is\n> nice as long as the remote repository doesn't _switch_ the HEAD to some\n> non-superset branch; but repositories you're cloning from shouldn't do\n> that). So you should either have origin/HEAD locally, or make the\n> 'master' branch more \"socially canonical\".\n\nAh, so git-clone sets up a local development head for the remote HEAD, which\ndoes not always have to be \"master\", right? This information would be available\nby the proposed storing of merge relationship: local \"master\" wants get merges\nfrom remote HEAD to be updated.\n\nJosef\n"}]}