{"thread":{"id":"43215","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","startedAt":"2006-12-06T12:07:23Z","lastAt":"2006-12-08T10:36:36Z","messageCount":15,"participants":["Jakub Narebski","Aneesh Kumar K.V","Josef Weidendorfer","Johannes Schindelin","Andy Parkins","Peter Baumann","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"298745","messageId":"200612061207.23437.andyparkins@gmail.com","threadId":"43215","inReplyTo":null,"subject":"[PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-06T12:07:23Z","receivedAt":"2006-12-06T12:07:23Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Without any specification in the .git/config file, git-pull will execute\n\"git-pull origin\"; which in turn defaults to pull from the first \"pull\"\ndefinition for the remote, \"origin\".\n\nThis is a difficult set of defaults to track for a new user, and it's\ndifficult to see what tells git to do this (especially when it is\nactually hard-coded behaviour). To ameliorate this slightly, this patch\nexplicitly specifies the default behaviour during a clone using the\n\"branch\" section of the config.\n\nFor example, a clone of a typical repository would create a .git/config\ncontaining:\n [remote \"origin\"]\n url = proto://host/repo.git\n fetch = refs/heads/master:refs/remotes/origin/master\n [branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nThe [branch \"master\"] section is such that there is no change to the\nfunctionality of git-pull, but that functionality is now explicitly\ndocumented.\n\nSigned-off-by: Andy Parkins \n---\nThis is really to help newbies. By explicitly documenting the default\nbehaviour, it makes it clearer what is going on. It also means no routing\nthrough documentation to find out what config option needs changing.\n\nIt's possible that we would want to remove the default behaviour entirely\nif there is no \"branch\" definition in the config. That would prevent\naccidents by users who don't know what pull does fully yet.\n\n git-clone.sh | 4 +++-\n 1 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 826fdda..992cb7c 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -413,7 +413,9 @@ then\n \t\t\trm -f \"refs/remotes/$origin/HEAD\"\n \t\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n \t\t\t\t\"refs/remotes/$origin/$head_points_at\"\n-\t\tesac\n+\t\tesac &&\n+\t\tgit-repo-config branch.\"$head_points_at\".remote \"$origin\" &&\n+\t\tgit-repo-config branch.\"$head_points_at\".merge \"refs/heads/$head_points_at\"\n \tesac\n \n \tcase \"$no_checkout\" in\n-- \n1.4.4.1.g3ece-dirty\n"},{"id":"296719","messageId":"Pine.LNX.4.63.0612061320360.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43215","inReplyTo":"200612061207.23437.andyparkins@gmail.com","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-06T12:20:58Z","receivedAt":"2006-12-06T12:20:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 6 Dec 2006, Andy Parkins wrote:\n\n> This is really to help newbies. By explicitly documenting the default \n> behaviour, it makes it clearer what is going on. It also means no \n> routing through documentation to find out what config option needs \n> changing.\n\nMelikes.\n\nCiao,\n"},{"id":"294770","messageId":"el6crv$p7e$1@sea.gmane.org","threadId":"43215","inReplyTo":"200612061207.23437.andyparkins@gmail.com","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-06T12:27:43Z","receivedAt":"2006-12-06T12:27:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> Without any specification in the .git/config file, git-pull will execute\n> \"git-pull origin\"; which in turn defaults to pull from the first \"pull\"\n> definition for the remote, \"origin\".\n> \n> This is a difficult set of defaults to track for a new user, and it's\n> difficult to see what tells git to do this (especially when it is\n> actually hard-coded behaviour). To ameliorate this slightly, this patch\n> explicitly specifies the default behaviour during a clone using the\n> \"branch\" section of the config.\n> \n> For example, a clone of a typical repository would create a .git/config\n> containing:\n> [remote \"origin\"]\n> url = proto://host/repo.git\n> fetch = refs/heads/master:refs/remotes/origin/master\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n> \n> The [branch \"master\"] section is such that there is no change to the\n> functionality of git-pull, but that functionality is now explicitly\n> documented.\n\nThis doesn't help newbies if they do \"git pull\" on branch other than\n\"master\". Git would fetch (a) from default remote \"origin\" (which can\nbe unexpected a bit) (b) into current branch (which can be very\nunexpected for newbie) (c) the first branch in remote (which can be\nvery unexpected).\n\nThe part (c) could be ameliorated (especially when globbing/regexp\nmatching would get into 'master') with \"Merge:\" line in remotes file\nand equivalent remote..merge which would specify explicitely\nthe branch to be merged, instead of using first branch.\n\n> Signed-off-by: Andy Parkins \n> ---\n> This is really to help newbies. By explicitly documenting the default\n> behaviour, it makes it clearer what is going on. It also means no routing\n> through documentation to find out what config option needs changing.\n\nVery nice.\n \n> It's possible that we would want to remove the default behaviour entirely\n> if there is no \"branch\" definition in the config. That would prevent\n> accidents by users who don't know what pull does fully yet.\n\nPerhaps protected by config option and/or pull option... or perhaps not.\nRefuse pulling into current branch if it doesn.t have branch..remote\nmatching current remote and doesn't have branch..merge entry, unless\nof course refspec is provided.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296975","messageId":"slrnendeau.7j4.Peter.B.Baumann@xp.machine.xx","threadId":"43215","inReplyTo":"200612061207.23437.andyparkins@gmail.com","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-12-06T12:36:46Z","receivedAt":"2006-12-06T12:36:46Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2006-12-06, Andy Parkins wrote:\n> Without any specification in the .git/config file, git-pull will execute\n> \"git-pull origin\"; which in turn defaults to pull from the first \"pull\"\n> definition for the remote, \"origin\".\n>\n> This is a difficult set of defaults to track for a new user, and it's\n> difficult to see what tells git to do this (especially when it is\n> actually hard-coded behaviour). To ameliorate this slightly, this patch\n> explicitly specifies the default behaviour during a clone using the\n> \"branch\" section of the config.\n>\n> For example, a clone of a typical repository would create a .git/config\n> containing:\n> [remote \"origin\"]\n> url = proto://host/repo.git\n> fetch = refs/heads/master:refs/remotes/origin/master\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n>\n> The [branch \"master\"] section is such that there is no change to the\n> functionality of git-pull, but that functionality is now explicitly\n> documented.\n>\n> Signed-off-by: Andy Parkins \n> ---\n> This is really to help newbies. By explicitly documenting the default\n> behaviour, it makes it clearer what is going on. It also means no routing\n> through documentation to find out what config option needs changing.\n>\n\nI second that. It took me a while to understand why the first entry in\nremotes/origin merged with the current branch. I thought it was a bug\nbecause sometimes it did the right thing and once in a while nothing\nwent wrong.\n\nObviously, it have switched the branch. I even tried to made this\n\"buggy\" behaviour reproducable to write a bugreport, but after several\ndays the light goes on and I just felt a little bit stupid :-)\n\n> It's possible that we would want to remove the default behaviour entirely\n> if there is no \"branch\" definition in the config. That would prevent\n> accidents by users who don't know what pull does fully yet.\n>\n\nI'm not absolutly sure about this, but with --use-separate-remote this makes\nsense, because you can easly teach someone new to git that the changes\nfrom the remote branches are under refs/remotes/ and (s)he\ncould merge it with git-pull . refs/remotes/$branch\n\nNo more clueless users why git pull on master branch updated the working\ntree and git pull an other branch does nothing.\n\n-Peter\n\n> git-clone.sh | 4 +++-\n> 1 files changed, 3 insertions(+), 1 deletions(-)\n>\n> diff --git a/git-clone.sh b/git-clone.sh\n> index 826fdda..992cb7c 100755\n> --- a/git-clone.sh\n> +++ b/git-clone.sh\n> @@ -413,7 +413,9 @@ then\n> \t\t\trm -f \"refs/remotes/$origin/HEAD\"\n> \t\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n> \t\t\t\t\"refs/remotes/$origin/$head_points_at\"\n> -\t\tesac\n> +\t\tesac &&\n> +\t\tgit-repo-config branch.\"$head_points_at\".remote \"$origin\" &&\n> +\t\tgit-repo-config branch.\"$head_points_at\".merge \"refs/heads/$head_points_at\"\n> \tesac\n> \n> \tcase \"$no_checkout\" in\n"},{"id":"296063","messageId":"200612061255.42379.andyparkins@gmail.com","threadId":"43215","inReplyTo":"el6crv$p7e$1@sea.gmane.org","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-06T12:55:41Z","receivedAt":"2006-12-06T12:55:41Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 December 06 12:27, Jakub Narebski wrote:\n\n> This doesn't help newbies if they do \"git pull\" on branch other than\n> \"master\". Git would fetch (a) from default remote \"origin\" (which can\n> be unexpected a bit) (b) into current branch (which can be very\n> unexpected for newbie) (c) the first branch in remote (which can be\n> very unexpected).\n\nThat's why I was suggesting to remove the default behaviour when there is no \nbranch defined. In that case git-pull would just exit with an appropriate \nmessage.\n\n> Perhaps protected by config option and/or pull option... or perhaps not.\n> Refuse pulling into current branch if it doesn.t have branch..remote\n> matching current remote and doesn't have branch..merge entry, unless\n> of course refspec is provided.\n\nThat's exactly what I meant; although your description is better.\n\nAndy\n\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296645","messageId":"200612061800.17087.Josef.Weidendorfer@gmx.de","threadId":"43215","inReplyTo":"200612061207.23437.andyparkins@gmail.com","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-06T17:00:16Z","receivedAt":"2006-12-06T17:00:16Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 06 December 2006 13:07, Andy Parkins wrote:\n> The [branch \"master\"] section is such that there is no change to the\n> functionality of git-pull, but that functionality is now explicitly\n> documented.\n\nNice.\nHowever, changing \"git-clone\" for this is an adhoc solution and\nlooks wrong.\n\nBranching off a local development branch for a tracking branch is\nthe job of git-branch. So first, git-branch should be called from\ngit-clone to do this setup.\n\nAnd git-branch should be told to change the configuration of default\nbehavior of git-pull, whenever it sees that you are branching off\nfrom a branch tracking a remote one. I even would go so far to setup\na default \"git-pull\" action even for branching off from local branches,\nby setting \"branch..remote = .\" to merge from local \"upstream\".\n\nSimilar, \"git-checkout -b \" should call \"git-branch\"\nfor branch creation, too.\n\n"},{"id":"298562","messageId":"el6to1$vhi$1@sea.gmane.org","threadId":"43215","inReplyTo":"200612061800.17087.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-06T17:15:46Z","receivedAt":"2006-12-06T17:15:46Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Josef Weidendorfer wrote:\n\n> I even would go so far to setup\n> a default \"git-pull\" action even for branching off from local branches,\n> by setting \"branch..remote = .\" to merge from local \"upstream\".\n\nI wouldn't go that far, as it would forbit perfectly good \"git fetch\"\nfrom anywhere in the sources meaning \"git fetch origin\".\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295895","messageId":"Pine.LNX.4.63.0612070022180.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43215","inReplyTo":"200612061800.17087.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-06T23:23:02Z","receivedAt":"2006-12-06T23:23:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 6 Dec 2006, Josef Weidendorfer wrote:\n\n> On Wednesday 06 December 2006 13:07, Andy Parkins wrote:\n> > The [branch \"master\"] section is such that there is no change to the\n> > functionality of git-pull, but that functionality is now explicitly\n> > documented.\n> \n> Nice. However, changing \"git-clone\" for this is an adhoc solution and \n> looks wrong.\n\nNot to me. There is _no_ other place to put this, if you want to help \npeople graps the concept of branch.*.merge.\n\nCiao,\nDscho\n"},{"id":"298295","messageId":"200612070349.58521.Josef.Weidendorfer@gmx.de","threadId":"43215","inReplyTo":"Pine.LNX.4.63.0612070022180.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-07T02:49:57Z","receivedAt":"2006-12-07T02:49:57Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 07 December 2006 00:23, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 6 Dec 2006, Josef Weidendorfer wrote:\n> \n> > On Wednesday 06 December 2006 13:07, Andy Parkins wrote:\n> > > The [branch \"master\"] section is such that there is no change to the\n> > > functionality of git-pull, but that functionality is now explicitly\n> > > documented.\n> > \n> > Nice. However, changing \"git-clone\" for this is an adhoc solution and \n> > looks wrong.\n> \n> Not to me. There is _no_ other place to put this, if you want to help \n> people graps the concept of branch.*.merge.\n\nAs far as I understand, git-clone defaults to kind of a mirror operation\nwhile changing remotes ref names slightly as tracking branches, and\nafterwards, it sets up a local branch for development, which is\nbranched off from the branch which tracks remote's master.\n\nIMHO there only should be one place/command which is creating new branches,\nand which is called by other porcelain commands [*1*]. This way, if we add\nsome further action to \"branching off\" (like adding a default merge branch),\nwe will not miss any place where a new branch will be created, thus keeping\neverything consistent.\n\nWhy should we not setup branch.*.merge when a create a new development\nbranch from a tracking branch via \"git branch\", or \"git checkout -b\" ?\n\nJosef\n\n[*1*] I recently made up my mind about this. I suggested a patch (see\n\"[PATCH/RFC] Convenient support of remote branches in git-checkout\"\nin the mail archive), which also set up \"branch.*.merge\" in a similar\nway as this patch is doing. And I got - rightly - the same response\n"},{"id":"298103","messageId":"7v64cowers.fsf@assigned-by-dhcp.cox.net","threadId":"43215","inReplyTo":"200612070349.58521.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-07T03:44:55Z","receivedAt":"2006-12-07T03:44:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> IMHO there only should be one place/command which is creating new branches,\n> and which is called by other porcelain commands [*1*].\n\nGiving an option to git branch to set something like this up\nwould be nice. I would agree the division of labor you propose\nis a good way to keep the scripts maintainable.\n\nIt however is a different matter if we would want to set up the\nmerge default always in the way you propose for a new branch at\nthe policy level.\n\nIt also is a different matter if \"git branch\" has enough\ninformation to figure out which upstream \"origin\" needs to be\nfetched from, given an origin SHA-1 expression to create a new\nbranch from, at the technical level\n\nIt entirely is possible to use the same remotes/origin/\nhierarchy to track two physically different URLs (thus two\ndifferent \"origin\"s) on a mobile machine that has different\nconnectivity to the outside world depending on where you are\n(\"that mirror is closer from here\" and \"I need to go over the\nfirewall while I am here\"). Because they track the logically\nsame repository, it does not make sense to use different\nhierarchies under remotes/ for this purpose.\n\nIn such a setup, \"git branch new origin/for-public\" would not be\nable to tell which \"origin\" to fetch from, so it may not even be\nfeasible to do what you propose without an explicit help from\nthe command line option. At least, however, the call to \"git branch\"\nyou would add as a part of this proposal to \"git clone\" would\nknow which URL, because at that point it would not even know\nabout the alternate connectivity yet.\n\n> Why should we not setup branch.*.merge when a create a new development\n> branch from a tracking branch via \"git branch\", or \"git checkout -b\"?\n\nSo while I am definitely in favor of the technical side of your\nproposal to have \"git checkout -b\" use \"git branch\", instead of\ndoing it by hand, I think it would be an easier sell to separate\nthe policy from the discussion at least in the beginning.\n\nI say this not because I disagree with your question: \"Why\nshould we not?\" I do not have a ready-answer to that rhetorical\nquestion yet. But that is different from saying \"it does not\nmake sense to do this setup because of such and such concrete\nreasons\", so I haven't formed an opinion on this policy matter\nyet.\n\n"},{"id":"294328","messageId":"4577B990.9090708@gmail.com","threadId":"43215","inReplyTo":"200612061207.23437.andyparkins@gmail.com","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Aneesh Kumar K.V","fromEmail":"aneesh.kumar@gmail.com","sentAt":"2006-12-07T06:49:52Z","receivedAt":"2006-12-07T06:49:52Z","isPatch":true,"sender":{"key":"aneesh.kumar@gmail.com","avatar":"https://gravatar.com/avatar/0621fc0b2f14ead1e9024382f16053a808c148596da30c1b92572fa075621f68?d=mp&s=160"},"body":"Andy Parkins wrote:\n> Without any specification in the .git/config file, git-pull will execute\n> \"git-pull origin\"; which in turn defaults to pull from the first \"pull\"\n> definition for the remote, \"origin\".\n> \n> This is a difficult set of defaults to track for a new user, and it's\n> difficult to see what tells git to do this (especially when it is\n> actually hard-coded behaviour). To ameliorate this slightly, this patch\n> explicitly specifies the default behaviour during a clone using the\n> \"branch\" section of the config.\n> \n> For example, a clone of a typical repository would create a .git/config\n> containing:\n> [remote \"origin\"]\n> url = proto://host/repo.git\n> fetch = refs/heads/master:refs/remotes/origin/master\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n> \n> The [branch \"master\"] section is such that there is no change to the\n> functionality of git-pull, but that functionality is now explicitly\n> documented.\n> \n> Signed-off-by: Andy Parkins \n> ---\n> This is really to help newbies. By explicitly documenting the default\n> behaviour, it makes it clearer what is going on. It also means no routing\n> through documentation to find out what config option needs changing.\n> \n> It's possible that we would want to remove the default behaviour entirely\n> if there is no \"branch\" definition in the config. That would prevent\n> accidents by users who don't know what pull does fully yet.\n> \n\nI liked this. This avoid lot of confusion and the \"magic\" master update.\n\n-aneesh\n"},{"id":"297786","messageId":"Pine.LNX.4.63.0612071511440.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43215","inReplyTo":"200612070349.58521.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-07T14:13:40Z","receivedAt":"2006-12-07T14:13:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 7 Dec 2006, Josef Weidendorfer wrote:\n\n> On Thursday 07 December 2006 00:23, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Wed, 6 Dec 2006, Josef Weidendorfer wrote:\n> > \n> > > On Wednesday 06 December 2006 13:07, Andy Parkins wrote:\n> > > > The [branch \"master\"] section is such that there is no change to the\n> > > > functionality of git-pull, but that functionality is now explicitly\n> > > > documented.\n> > > \n> > > Nice. However, changing \"git-clone\" for this is an adhoc solution and \n> > > looks wrong.\n> > \n> > Not to me. There is _no_ other place to put this, if you want to help \n> > people graps the concept of branch.*.merge.\n> \n> As far as I understand, git-clone defaults to kind of a mirror operation\n> while changing remotes ref names slightly as tracking branches, and\n> afterwards, it sets up a local branch for development, which is\n> branched off from the branch which tracks remote's master.\n\nYes. And I should back off from my strong language: I think this git-clone \nthe most obvious program to set branch.master.merge. It should make life \neasier for new Git users.\n\nCiao,\n"},{"id":"295437","messageId":"200612071544.03306.Josef.Weidendorfer@gmx.de","threadId":"43215","inReplyTo":"Pine.LNX.4.63.0612071511440.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-07T14:44:03Z","receivedAt":"2006-12-07T14:44:03Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 07 December 2006 15:13, Johannes Schindelin wrote:\n> > > > Nice. However, changing \"git-clone\" for this is an adhoc solution and \n> > > > looks wrong.\n> > > \n> > > Not to me. There is _no_ other place to put this, if you want to help \n> > > people graps the concept of branch.*.merge.\n> > \n> > As far as I understand, git-clone defaults to kind of a mirror operation\n> > while changing remotes ref names slightly as tracking branches, and\n> > afterwards, it sets up a local branch for development, which is\n> > branched off from the branch which tracks remote's master.\n> \n> Yes. And I should back off from my strong language: I think this git-clone \n> the most obvious program to set branch.master.merge. It should make life \n> easier for new Git users.\n\nOh, no problem ;-) I myself used quite strong words. And I fully agree that\nit makes life easier for users. And it is way easier to do it in git-clone\nbecause\n(1) in git-clone we _know_ that we branch of a tracking branch; in git-branch,\nwe first have to check if we want the configuration set.\n(2) git-branch is more difficult to change because it's written in C :-)\n\nHowever, as discussed in another thread, branch.*.merge currently has quite\na strange semantic [*1*], and without changing, users have no way to grasp this\nconfiguration option.\n\nAnd that branch renaming feature cooking in pu really has to move branch\nattributes too, when we even officially set them now in git-clone.\n\nJosef\n\n[*1*] Currently, in branch.*.merge you have to specify the remote branch name\nof a refspec which updates a local tracking branch in the fetch phase of git pull.\n"},{"id":"298111","messageId":"200612071552.51799.Josef.Weidendorfer@gmx.de","threadId":"43215","inReplyTo":"7v64cowers.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-07T14:52:51Z","receivedAt":"2006-12-07T14:52:51Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 07 December 2006 04:44, Junio C Hamano wrote:\n> Josef Weidendorfer writes:\n> \n> > IMHO there only should be one place/command which is creating new branches,\n> > and which is called by other porcelain commands [*1*].\n> \n> Giving an option to git branch to set something like this up\n> would be nice. I would agree the division of labor you propose\n> is a good way to keep the scripts maintainable.\n> \n> It however is a different matter if we would want to set up the\n> merge default always in the way you propose for a new branch at\n> the policy level.\n> \n> It also is a different matter if \"git branch\" has enough\n> information to figure out which upstream \"origin\" needs to be\n> fetched from, given an origin SHA-1 expression to create a new\n> branch from, at the technical level\n\nWe could setup the branch.*.remote option for every tracking branch\ngit-clone is fetching (and git-fetch with the wildcard refspec).\nAnd git-branch sets branch.*.remote/merge for the new branch\nwhenever it sees that a remote is set for the branch we are\nbranching off.\n \n> It entirely is possible to use the same remotes/origin/\n> hierarchy to track two physically different URLs (thus two\n> different \"origin\"s) on a mobile machine that has different\n> connectivity to the outside world depending on where you are\n> (\"that mirror is closer from here\" and \"I need to go over the\n> firewall while I am here\"). Because they track the logically\n> same repository, it does not make sense to use different\n> hierarchies under remotes/ for this purpose.\n> \n> In such a setup, \"git branch new origin/for-public\" would not be\n> able to tell which \"origin\" to fetch from\n\nI see.\nBut I hope with my suggestion above, this can be looked up then\nin the branch.\"remotes/origin/for-public\".remote option.\n\n"},{"id":"294050","messageId":"elbf3l$bm7$1@sea.gmane.org","threadId":"43215","inReplyTo":"200612071544.03306.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-08T10:36:36Z","receivedAt":"2006-12-08T10:36:36Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Josef Weidendorfer wrote:\n\n> However, as discussed in another thread, branch.*.merge currently has quite\n> a strange semantic [*1*], and without changing, users have no way to grasp this\n> configuration option.\n[...]\n> [*1*] Currently, in branch.*.merge you have to specify the remote branch name\n> of a refspec which updates a local tracking branch in the fetch phase of git pull.\n> I.e. the option value has nothing todo with the merge action itself!\n\nThat's (I think) because branch..merge can be for pull used _without_\ntracking branch. So it is not that easy to change semantics, I agree bit\nstrange for newbie git users, who know git from the begining with\n--use-separate-remote and tracking branches.\n\nPerhaps we should extend it so it can take beginning part of refspec\n(as now), full refspec, or ':' and local branch.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"}]}