{"thread":{"id":"1630","subject":"[PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","startedAt":"2005-08-23T21:33:16Z","lastAt":"2005-11-11T16:10:21Z","messageCount":13,"participants":["Pavel Roskin","Petr Baudis","Josef Weidendorfer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"7670","messageId":"1124832796.23795.9.camel@dv","threadId":"1630","inReplyTo":null,"subject":"[PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-08-23T21:33:16Z","receivedAt":"2005-08-23T21:33:16Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nThis patch changes cg-pull so that if the branch is not specified, it\ntakes origin's .git/HEAD without first trying .git/refs/heads/master.\nThis removes preferential treatment of the \"master\" branch, allowing the\nupstream to use another name for the default branch.  To get the master\nbranch, users would have to append \"#master\" to the URL.\n\nLocal URL handling needs to be fixed to handle .git/HEAD properly, since\nit's a symlink in the upstream directory.  A new flag \"-b\" for fetch_*\nfunctions is introduced, meaning \"dereference\" (like in GNU cp).\n\nTo do: the code needs refactoring with better option handling.\n\nSigned-off-by: Pavel Roskin <proski@gnu.org>\n\ndiff --git a/cg-pull b/cg-pull\n--- a/cg-pull\n+++ b/cg-pull\n@@ -67,6 +67,8 @@ pull_progress()\n \n fetch_rsync()\n {\n+\t[ \"$1\" = \"-b\" ] && shift\n+\n \tredir=\n \tif [ \"$1\" = \"-i\" ]; then # ignore-errors\n \t\tredir=\"2>/dev/null\"\n@@ -108,6 +110,7 @@ pull_rsync()\n \n fetch_http()\n {\n+\t[ \"$1\" = \"-b\" ] && shift\n \t[ \"$1\" = \"-i\" ] && shift\n \t[ \"$1\" = \"-s\" ] && shift\n \n@@ -158,6 +161,7 @@ pull_http()\n \n fetch_ssh()\n {\n+\t[ \"$1\" = \"-b\" ] && shift\n \t[ \"$1\" = \"-i\" ] && shift\n \t[ \"$1\" = \"-s\" ] && shift\n \n@@ -205,6 +209,11 @@ fetch_local()\n \t[ \"$1\" = \"-s\" ] && shift\n \n \tcp_flags_l=\"-vdpR\"\n+\tif [ \"$1\" = \"-b\" ]; then\n+\t\tcp_flags_l=\"-vb\" # Dereference symlinks\n+\t\tshift\n+\tfi\n+\n \tif [ \"$1\" = \"-u\" ]; then\n \t\tcp_flags_l=\"$cp_flags_l -fu$can_hardlink\"\n \t\tsuggest_hardlink=\n@@ -255,7 +264,7 @@ name=${ARGS[0]}\n [ \"$name\" ] || die \"where to pull from?\"\n uri=$(cat \"$_git/branches/$name\" 2>/dev/null) || die \"unknown branch: $name\"\n \n-rembranch=master\n+rembranch=\n if echo \"$uri\" | grep -q '#'; then\n \trembranch=$(echo $uri | cut -d '#' -f 2)\n \turi=$(echo $uri | cut -d '#' -f 1)\n@@ -308,13 +317,13 @@ orig_head=\n \n \n mkdir -p $_git/refs/heads\n-rsyncerr=\n-$fetch -i \"$uri/refs/heads/$rembranch\" \"$_git/refs/heads/.$name-pulling\" || rsyncerr=1\n-if [ \"$rsyncerr\" ] && [ \"$rembranch\" = \"master\" ]; then\n-\trsyncerr=\n-\t$fetch -s \"$uri/HEAD\" \"$_git/refs/heads/.$name-pulling\" || rsyncerr=1\n+if [ \"$rembranch\" ]; then\n+\t$fetch -i \"$uri/refs/heads/$rembranch\" \"$_git/refs/heads/.$name-pulling\" ||\n+\t\tdie \"unable to get the head pointer of branch $rembranch\"\n+else\n+\t$fetch -b -s \"$uri/HEAD\" \"$_git/refs/heads/.$name-pulling\" ||\n+\t\tdie \"unable to get the HEAD branch\"\n fi\n-[ \"$rsyncerr\" ] && die \"unable to get the head pointer of branch $rembranch\"\n \n new_head=$(cat \"$_git/refs/heads/.$name-pulling\")\n if ! [ \"$symlinked\" ]; then\n\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11498","messageId":"20051110192430.GS30496@pasky.or.cz","threadId":"1630","inReplyTo":"1124832796.23795.9.camel@dv","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T19:24:30Z","receivedAt":"2005-11-10T19:24:30Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hello,\n\nDear diary, on Tue, Aug 23, 2005 at 11:33:16PM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> said that...\n> Local URL handling needs to be fixed to handle .git/HEAD properly, since\n> it's a symlink in the upstream directory.  A new flag \"-b\" for fetch_*\n> functions is introduced, meaning \"dereference\" (like in GNU cp).\n> \n> @@ -205,6 +209,11 @@ fetch_local()\n>  \t[ \"$1\" = \"-s\" ] && shift\n>  \n>  \tcp_flags_l=\"-vdpR\"\n> +\tif [ \"$1\" = \"-b\" ]; then\n> +\t\tcp_flags_l=\"-vb\" # Dereference symlinks\n> +\t\tshift\n> +\tfi\n> +\n>  \tif [ \"$1\" = \"-u\" ]; then\n>  \t\tcp_flags_l=\"$cp_flags_l -fu$can_hardlink\"\n>  \t\tsuggest_hardlink=\n\n  can you still remember why did you introduce this? In GNU cp\ndocumentation, I can see just\n\n       -b, --backup\n              Make backups of files that are about to be overwritten or removed.\n\nwhich doesn't make sense to me - -L dereferences symlinks.\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":"11509","messageId":"1131653507.11283.31.camel@dv","threadId":"1630","inReplyTo":"20051110192430.GS30496@pasky.or.cz","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-10T20:11:47Z","receivedAt":"2005-11-10T20:11:47Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hi, Petr!\n\nOn Thu, 2005-11-10 at 20:24 +0100, Petr Baudis wrote:\n>   can you still remember why did you introduce this? In GNU cp\n> documentation, I can see just\n> \n>        -b, --backup\n>               Make backups of files that are about to be overwritten or removed.\n> \n> which doesn't make sense to me - -L dereferences symlinks.\n\nYou are right, it must be my error.  Anyway, it was so long ago that I\nwould need to review and retest it.\n\nWhile at that, let's stop using symlinks.  git doesn't use symlinks on\nCygwin.  I think git should use that code on all OSes, since the\nbenefits of using symlinks are minimal (I think the only benefits are\ntheir atomicity and resolving the reference in the kernel rather than in\nuserspace).  Having more uniform code for all platforms would simplify\ndevelopment and testing.  It could also reduce requirements for the\ntransport protocols.  Finally, symlinks could be still used by the users\n(if they know what they are doing) - git and cogito would simply become\nsymlink agnostic.\n\nWhen files are copied around, symlinks are pain to deal with.  They\nrequire special handling to be preserved both for remote operation and\ndereferenced for local operation (that's what my patch was intended to\ndo).  I'm not even considering what would happen when cloning from Linux\nto Windows or vice versa.\n\nSure, it can wait until git 1.0, but it would be great to keep this goal\nin mind.\n\nDisclaimer - I'm not reading the git mailing list, so if it was\ndiscussed, I'm sorry, I don't intend to restart that discussion - just\ngive me the pointer and I'll read it.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11526","messageId":"200511110026.18324.Josef.Weidendorfer@gmx.de","threadId":"1630","inReplyTo":"1124832796.23795.9.camel@dv","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-10T23:26:18Z","receivedAt":"2005-11-10T23:26:18Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:\n> Hello!\n> \n> This patch changes cg-pull so that if the branch is not specified, it\n> takes origin's .git/HEAD without first trying .git/refs/heads/master.\n> This removes preferential treatment of the \"master\" branch, allowing the\n> upstream to use another name for the default branch.  To get the master\n> branch, users would have to append \"#master\" to the URL.\n\nI think this is wrong.\n\nWhy would anybody want to fetch the current upstream HEAD at cg-pull\ntime? If you do this, and you have no control on the upstream\nrepository, \"origin\" will jump randomly around after cg-pull, depending\non the current HEAD of the origin repository.\n\nBesides, this is a incompatible change in cg-pull behavior: I am sure that\na lot of people did a cg-clone in the past without any specific remote branch,\nand expect that cg-pull will update their origin to the remote \"master\".\nNow, if they update to a new Cogito with this patch, the next cg-pull\nsometimes will rebase their origin to another random branch, depending\non remote HEAD ?!\n\nOr am I missing something here?\n\nJosef\n"},{"id":"11528","messageId":"20051110234029.GE30496@pasky.or.cz","threadId":"1630","inReplyTo":"200511110026.18324.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T23:40:29Z","receivedAt":"2005-11-10T23:40:29Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:\n> > Hello!\n> > \n> > This patch changes cg-pull so that if the branch is not specified, it\n> > takes origin's .git/HEAD without first trying .git/refs/heads/master.\n> > This removes preferential treatment of the \"master\" branch, allowing the\n> > upstream to use another name for the default branch.  To get the master\n> > branch, users would have to append \"#master\" to the URL.\n> \n> I think this is wrong.\n> \n> Why would anybody want to fetch the current upstream HEAD at cg-pull\n> time? If you do this, and you have no control on the upstream\n> repository, \"origin\" will jump randomly around after cg-pull, depending\n> on the current HEAD of the origin repository.\n\nIn public repositories, you usually set the HEAD once and it stays\nthere, or when you switch it, you are really careful about it.\n\n> Besides, this is a incompatible change in cg-pull behavior: I am sure that\n> a lot of people did a cg-clone in the past without any specific remote branch,\n> and expect that cg-pull will update their origin to the remote \"master\".\n> Now, if they update to a new Cogito with this patch, the next cg-pull\n> sometimes will rebase their origin to another random branch, depending\n> on remote HEAD ?!\n\nSee above. The remote HEAD is supposed to be generally stable for public\nrepositories, pointing to the _default_ head for public consumption.\nIf you want something specific, specify it by the #branchname.\n\n> Or am I missing something here?\n\nThat this is from 23 August and this change was in Cogito for several\nmajor releases and noone ever complained. ;-)\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":"11529","messageId":"200511110056.54476.Josef.Weidendorfer@gmx.de","threadId":"1630","inReplyTo":"20051110234029.GE30496@pasky.or.cz","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-10T23:56:54Z","receivedAt":"2005-11-10T23:56:54Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 11 November 2005 00:40, Petr Baudis wrote:\n> Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter\n> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:\n> > > Hello!\n> > > \n> > > This patch changes cg-pull so that if the branch is not specified, it\n> > > takes origin's .git/HEAD without first trying .git/refs/heads/master.\n> > > This removes preferential treatment of the \"master\" branch, allowing the\n> > > upstream to use another name for the default branch.  To get the master\n> > > branch, users would have to append \"#master\" to the URL.\n> ...\n> > Or am I missing something here?\n> \n> That this is from 23 August and this change was in Cogito for several\n> major releases and noone ever complained. ;-)\n\nYou catched me ;-)\n\nStill I think my reasoning holds: cg-clone is also used locally, thus\ncloning a repository on which you probably are working on, too.\nIf I want to branch off from master, I can use cg-clone to start a new\ndevelopment branch. I suppose this is the suggested Cogito way, from\nthe README; and it makes Cogitos usage so simple, even with multiple\ndevelopment branches: by using a cloned repository for each branch.\n\nOf course, a Git user would use \"git branch ...\", and switch between\nbranches inside of one repository.\n\nJosef\n"},{"id":"11530","messageId":"20051111000923.GF30496@pasky.or.cz","threadId":"1630","inReplyTo":"200511110056.54476.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-11T00:09:23Z","receivedAt":"2005-11-11T00:09:23Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Nov 11, 2005 at 12:56:54AM CET, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> Still I think my reasoning holds: cg-clone is also used locally, thus\n> cloning a repository on which you probably are working on, too.\n\nYes, that's a valid point, but I still think for the usual case\ndefaulting to HEAD is the right thing to do. But it wasn't described\nin the documentation and that's indeed a bug - fixed now.\n\n> If I want to branch off from master, I can use cg-clone to start a new\n> development branch. I suppose this is the suggested Cogito way, from\n> the README; and it makes Cogitos usage so simple, even with multiple\n> development branches: by using a cloned repository for each branch.\n\nYes, this is the recommended workflow. Well, if you plan to switch\nbranches randomly in your \"central private repository\", better explicitly\nspecify #master in the offsprings. ;-)\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":"11534","messageId":"1131668075.3987.5.camel@dv","threadId":"1630","inReplyTo":"20051110234029.GE30496@pasky.or.cz","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-11T00:14:35Z","receivedAt":"2005-11-11T00:14:35Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2005-11-11 at 00:40 +0100, Petr Baudis wrote: \n> Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter\n> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > Why would anybody want to fetch the current upstream HEAD at cg-pull\n> > time? If you do this, and you have no control on the upstream\n> > repository, \"origin\" will jump randomly around after cg-pull, depending\n> > on the current HEAD of the origin repository.\n> \n> In public repositories, you usually set the HEAD once and it stays\n> there, or when you switch it, you are really careful about it.\n\nCorrect.  But if it's a concern, I think we could make some\nimprovements.  Following approaches could be tried (starting from top,\nusing following steps as a fallback):\n\n1) Use recorded branch, i.e. the branch name that was used in cg-clone.\n\n2) Check a file specifying the default branch for cloning (let's call it\ne.g. .git/default_export).  Record branch name.\n\n3) If cg-switch is implemented, another file would be likely used to\nspecify the default branch for local operations\n(e.g. .git/default_branch).  Use it.  Record branch name.\n\n4) If .git/HEAD can be recognized as link (we may need to eliminate\nsymlinks for that to work over remote transport), use the branch it\npoints to.  Record branch name.\n\n5) If .git/HEAD cannot be recognized as link, use it as the branch to\nclone.  Don't record the branch name.  (I'm not sure if we really want\nthat - it's good to know what branch we are using).\n\n6) Use \"master\" branch.  Record branch name.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11539","messageId":"200511110213.54846.Josef.Weidendorfer@gmx.de","threadId":"1630","inReplyTo":"1131668075.3987.5.camel@dv","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-11T01:13:54Z","receivedAt":"2005-11-11T01:13:54Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 11 November 2005 01:14, Pavel Roskin wrote:\n> On Fri, 2005-11-11 at 00:40 +0100, Petr Baudis wrote: \n> > Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter\n> > where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > > Why would anybody want to fetch the current upstream HEAD at cg-pull\n> > > time?\n> ...\n> Correct.  But if it's a concern, I think we could make some\n> improvements.  Following approaches could be tried (starting from top,\n> using following steps as a fallback):\n> \n> 1) Use recorded branch, i.e. the branch name that was used in cg-clone.\n\nThis is the \"#...\" part in .git/branches/origin, and it is already used.\n\nI have nothing against using HEAD for cloning, but the branch name should\nbe recorded, such that cg-pull always fetches from the same branch.\n\nI think 1) is enough if we add the detected branch name in the #... part\nin .git/branches/origin at cg-clone time.\n\nAnd \"detectable\" covers the local case, which was my concern here [*1*]\n\nJosef\n\n[*1*] after being told about the \"stable HEAD\" property of public repositories,\nwhich is correct. I am not even sure that a HEAD makes sense\nin public repositories: in my opinion HEAD has something to do with checked out\nfiles, and a public repository usually does not have these. But perhaps\nthat's only me...\n"},{"id":"11546","messageId":"1131684784.31172.16.camel@dv","threadId":"1630","inReplyTo":"200511110213.54846.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-11T04:53:04Z","receivedAt":"2005-11-11T04:53:04Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2005-11-11 at 02:13 +0100, Josef Weidendorfer wrote:\n> > Correct.  But if it's a concern, I think we could make some\n> > improvements.  Following approaches could be tried (starting from top,\n> > using following steps as a fallback):\n> > \n> > 1) Use recorded branch, i.e. the branch name that was used in cg-clone.\n> \n> This is the \"#...\" part in .git/branches/origin, and it is already used.\n\nI'm not sure if we understand each other, but \"recorded\" refers to\nautomatically determined branch name.  If cg-clone can determine the\nbranch name, that name should be saved and used for updates.\n\nWhether the branch name is saved in .git/branches/ using hash notation\n(old style) or in .git/remotes/ (new style) is irrelevant.\n\nIf cg-clone cannot determine the branch name, we may either support it,\nor revert to \"master\".  I'm ambivalent about that.  Probably reverting\nto \"master\" is better to simplify the code.  On the other hand, I can\nimagine public repositories without the \"master\" branch.\n\n> I have nothing against using HEAD for cloning, but the branch name should\n> be recorded, such that cg-pull always fetches from the same branch.\n\nTo use HEAD, we'll need to port git from Cygwin, since readlink doesn't\nwork over http.\n\n> I think 1) is enough if we add the detected branch name in the #... part\n> in .git/branches/origin at cg-clone time.\n\nI agree that the branch name should be saved explicitly using already\nsupported notation (if that's what you mean).\n\n> And \"detectable\" covers the local case, which was my concern here [*1*]\n> \n> Josef\n> \n> [*1*] after being told about the \"stable HEAD\" property of public repositories,\n> which is correct. I am not even sure that a HEAD makes sense\n> in public repositories: in my opinion HEAD has something to do with checked out\n> files, and a public repository usually does not have these. But perhaps\n> that's only me...\n\nThat's why I mentioned the idea of having a separate file to indicate\nthe default branch for export.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11589","messageId":"200511111522.37979.Josef.Weidendorfer@gmx.de","threadId":"1630","inReplyTo":"1131684784.31172.16.camel@dv","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-11T14:22:37Z","receivedAt":"2005-11-11T14:22:37Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 11 November 2005 05:53, Pavel Roskin wrote:\n> I'm not sure if we understand each other, but \"recorded\" refers to\n> automatically determined branch name.  If cg-clone can determine the\n> branch name, that name should be saved and used for updates.\n> \n> Whether the branch name is saved in .git/branches/ using hash notation\n> (old style) or in .git/remotes/ (new style) is irrelevant.\n\nYes.\nBut for the conrete implementation it is relevant.\n\nAFAIK, there is not really a \"new\" and \"old\" style, but more the\ngit way (attributes for remote repositories in .git/remotes) and the\nCogito way (attributes for a remote branch).\n\n\"Recording\" talks about storing the name of the remote branch that\nmaps to the local \"origin\" branch, so I would vote for storing this\nin .git/branches/origin.\n\nFor cg-clone, this is no problem because cg-clone writes this file itself.\nAnother thing is if you add later on a remote branch with cg-branch-add\nwithout specifying a concrete remote branch name. Do we want the\nrecord the branch name at the first cg-fetch for the future?\n\n> That's why I mentioned the idea of having a separate file to indicate\n> the default branch for export.\n\nAgree.\n\nJosef\n"},{"id":"11597","messageId":"1131722791.1284.20.camel@dv","threadId":"1630","inReplyTo":"200511111522.37979.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-11T15:26:31Z","receivedAt":"2005-11-11T15:26:31Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Fri, 2005-11-11 at 15:22 +0100, Josef Weidendorfer wrote:\n> On Friday 11 November 2005 05:53, Pavel Roskin wrote:\n> > I'm not sure if we understand each other, but \"recorded\" refers to\n> > automatically determined branch name.  If cg-clone can determine the\n> > branch name, that name should be saved and used for updates.\n> > \n> > Whether the branch name is saved in .git/branches/ using hash notation\n> > (old style) or in .git/remotes/ (new style) is irrelevant.\n> \n> Yes.\n> But for the conrete implementation it is relevant.\n> \n> AFAIK, there is not really a \"new\" and \"old\" style, but more the\n> git way (attributes for remote repositories in .git/remotes) and the\n> Cogito way (attributes for a remote branch).\n\nSwitching to the \"git way\" is long overdue, since hashes can be used in\nthe actual path.\n\n> \"Recording\" talks about storing the name of the remote branch that\n> maps to the local \"origin\" branch, so I would vote for storing this\n> in .git/branches/origin.\n\nYes, cg-clone should do its best to determine the branch name and to\nsave it for future use by cg-fetch.\n\n> For cg-clone, this is no problem because cg-clone writes this file itself.\n> Another thing is if you add later on a remote branch with cg-branch-add\n> without specifying a concrete remote branch name. Do we want the\n> record the branch name at the first cg-fetch for the future?\n\nGood that you noticed that.\n\ncg-fetch could do that, but maybe cg-branch-add would be an even better\nplace for that?  I mean, cg-branch-add could actually check the\nrepository and prompt the user which branch to use if there is no\nobvious default.  I think, there should be a way to run cg-branch-add\nwithout having it connect the repository or prompt the user, but the\ndefault should be user-friendly.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11603","messageId":"200511111710.21984.Josef.Weidendorfer@gmx.de","threadId":"1630","inReplyTo":"1131722791.1284.20.camel@dv","subject":"Re: [PATCH] cg-pull to stop treating \"master\" specially, fix fetch_local for .git/HEAD","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-11T16:10:21Z","receivedAt":"2005-11-11T16:10:21Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 11 November 2005 16:26, Pavel Roskin wrote:\n> > AFAIK, there is not really a \"new\" and \"old\" style, but more the\n> > git way (attributes for remote repositories in .git/remotes) and the\n> > Cogito way (attributes for a remote branch).\n> \n> Switching to the \"git way\" is long overdue, since hashes can be used in\n> the actual path.\n\nCurrently, Git does not store mappings of remote to local branches in\n.git/remotes/ per se. \"Pull\" lines allow you to specify default actions\nfor git-fetch/git-pull, but even this is quite limited:\n\"git-fetch\" defaults to fetching all heads mentioned, and \"git-pull\"\ndefaults to merging the first head on the first \"Pull\" line.\n\nBecause the git way is per-remote-repository, you always have to specify\nthe remote repository shortcut in git-fetch/git-pull/git-push, as there\nis no implicit remote repository. With per-branch, it is far simpler as\nyou always have a current active branch which is HEAD. By using\n.git/remotes, you more or less get a shortcut name for a remote repository.\nOf course, Cogito could use this shortcut in the .git/branches/, too.\n\nAnother thing: Per branch configuration is not only about branches which\nhave a mapping to a remote file. I would *love* to be able to specify\nmerge candidates and default merge branches for every local branch.\nSuch configuration of local branches can also reside in .git/branches.\n\nBut you are right, hashes can be part of an path, so Cogito should use\nmultiple lines in .git/branches/ like Git does in .git/remotes.\n\nSo what are possible configuration items for a branch?\nBranches can be of 2 kinds: either a branch should track a remote branch,\nor it is used for local development.\n\nA branch which is tracking a remote one does need\n* the remote repository URL, or path (if local)\n* the branch name to track from the remote repository\n\nA branch used for development can have:\n* set of local branch names which are candidates for merging\n* set of local branch names for default merge action\n* a default remote branch to use for pushing\n\n> > For cg-clone, this is no problem because cg-clone writes this file itself.\n> > Another thing is if you add later on a remote branch with cg-branch-add\n> > without specifying a concrete remote branch name. Do we want the\n> > record the branch name at the first cg-fetch for the future?\n> \n> Good that you noticed that.\n> \n> cg-fetch could do that, but maybe cg-branch-add would be an even better\n> place for that?  I mean, cg-branch-add could actually check the\n> repository and prompt the user which branch to use if there is no\n> obvious default.  I think, there should be a way to run cg-branch-add\n> without having it connect the repository or prompt the user, but the\n> default should be user-friendly.\n\nYes.\n\nJosef\n"}]}