{"thread":{"id":"6178","subject":"[PATCH] Documentation: update git-clone.txt for clone's new default behavior","startedAt":"2006-12-31T23:47:33Z","lastAt":"2007-01-06T01:17:33Z","messageCount":47,"participants":["bfields@fieldses.org","Junio C Hamano","J. Bruce Fields","Luben Tuikov","Theodore Tso","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"30594","messageId":"11676088584199-git-send-email-bfields@fieldses.org","threadId":"6178","inReplyTo":null,"subject":"[PATCH] Docs: update cvs-migration.txt to reflect clone's new default behavior","fromName":"","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-31T23:47:33Z","receivedAt":"2006-12-31T23:47:33Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"From: J. Bruce Fields \n\nI couldn't think of a really quick way to give all the details, so just refer\nreaders to the git-repo-config man page instead.\n\nI haven't tested recent cvs import behavior--some time presumably it should be\nupdated to do something more similar to clone.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/cvs-migration.txt | 11 ++++-------\n 1 files changed, 4 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt\nindex b657f45..8e09bea 100644\n--- a/Documentation/cvs-migration.txt\n+++ b/Documentation/cvs-migration.txt\n@@ -34,13 +34,10 @@ them first before running git pull.\n \n [NOTE]\n ================================\n-The first `git clone` places the following in the\n-`my-project/.git/remotes/origin` file, and that's why the previous step\n-and the next step both work.\n-------------\n-URL: foo.com:/pub/project.git/\n-Pull: refs/heads/master:refs/remotes/origin/master\n-------------\n+The `pull` command knows where to get updates from because of certain\n+configuration variables that were set by the first `git clone`\n+command; see `git repo-config -l` and the gitlink:git-repo-config[1] man\n+page for details.\n ================================\n \n You can update the shared repository with your changes by first committing\n-- \n1.5.0.rc0.gac28\n"},{"id":"30592","messageId":"1167608858759-git-send-email-bfields@fieldses.org","threadId":"6178","inReplyTo":"11676088584199-git-send-email-bfields@fieldses.org","subject":"[PATCH] Documentation: update git-clone.txt for clone's new default behavior","fromName":"","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-31T23:47:34Z","receivedAt":"2006-12-31T23:47:34Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"From: J. Bruce Fields \n\nFix a couple remaining references to the origin branch.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/git-clone.txt | 11 ++++-------\n 1 files changed, 4 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 874934a..9652320 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -75,16 +75,13 @@ OPTIONS\n \tAlso the branch heads at the remote are copied directly\n \tto corresponding local branch heads, without mapping\n \tthem to `refs/remotes/origin/`. When this option is\n-\tused, neither the `origin` branch nor the default\n-\t`remotes/origin` file is created.\n+\tused, neither remote-tracking branches nor the related\n+\tconfiguration variables are created.\n \n --origin ::\n -o ::\n-\tInstead of using the branch name 'origin' to keep track\n-\tof the upstream repository, use instead. Note\n-\tthat the shorthand name stored in `remotes/origin` is\n-\tnot affected, but the local branch name to pull the\n-\tremote `master` branch into is.\n+\tInstead of using the remote name 'origin' to keep track\n+\tof the upstream repository, use instead.\n \n --upload-pack ::\n -u ::\n-- \n1.5.0.rc0.gac28\n"},{"id":"30596","messageId":"11676088582634-git-send-email-bfields@fieldses.org","threadId":"6178","inReplyTo":"1167608858759-git-send-email-bfields@fieldses.org","subject":"[PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-31T23:47:35Z","receivedAt":"2006-12-31T23:47:35Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"From: J. Bruce Fields \n\nUpdate examples. I'm not sure if the last two examples are really useful\nany more.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/git-pull.txt | 75 +++++++++++++++++++++++++------------------\n 1 files changed, 44 insertions(+), 31 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 2a5aea7..5b9ff96 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -37,8 +37,15 @@ EXAMPLES\n --------\n \n git pull, git pull origin::\n-\tFetch the default head from the repository you cloned\n-\tfrom and merge it into your current branch.\n+\tUpdate the remote tracking brances for the repository\n+\tyou cloned from, then merge one of them into your\n+\tcurrent branch. Normally the branch merged in is\n+\tthe HEAD of the remote repository, when your master\n+\tbranch is checked out. When on another branch,\n+\tthe (alphabetically) first branch from the remote\n+\trepository is merged in. These defaults can be modified\n+\tusing the branch and remote sections of the repository\n+\tconfiguration; see gitlink:git-repo-config[1] for details.\n \n git pull -s ours . obsolete::\n \tMerge local branch `obsolete` into the current branch,\n@@ -58,51 +65,57 @@ You should refrain from abusing this option to sneak substantial\n changes into a merge commit. Small fixups like bumping\n release/version name would be acceptable.\n \n-Command line pull of multiple branches from one repository::\n+Pull of multiple branches from one repository using default configuration::\n +\n ------------------------------------------------\n-$ cat .git/remotes/origin\n-URL: git://git.kernel.org/pub/scm/git/git.git\n-Pull: master:origin\n-\n+$ git repo-config -l\n+...\n+remote.origin.url=git://git.kernel.org/pub/scm/git/git.git\n+remote.origin.fetch=+refs/heads/*:refs/remotes/foo/*\n+branch.master.remote=origin\n+branch.master.merge=refs/heads/master\n $ git checkout master\n-$ git fetch origin master:origin +pu:pu maint:maint\n-$ git pull . origin\n+$ git fetch origin\n+$ git pull . origin/master\n ------------------------------------------------\n +\n-Here, a typical `.git/remotes/origin` file from a\n+Here, a typical configuration created by the\n `git-clone` operation is used in combination with\n-command line options to `git-fetch` to first update\n-multiple branches of the local repository and then\n-to merge the remote `origin` branch into the local\n-`master` branch. The local `pu` branch is updated\n-even if it does not result in a fast forward update.\n+`git-fetch` to update all of the remote tracking\n+branches for `origin` (the remote repository which\n+you originally cloned from). Thanks to the \"+\" on\n+the `remote.origin.fetch` line, the tracking branches\n+will all be updated even if they do not result in a\n+fast forward update.\n++\n+The `git pull` command then merges the newly\n+fetched origin/master into the local `master` branch.\n Here, the pull can obtain its objects from the local\n repository using `.`, as the previous `git-fetch` is\n known to have already obtained and made available\n all the necessary objects.\n++\n+Note that given the configuration above, a simple\n+`git pull` would have the same result as the above\n+sequence of fetch and pull.\n \n \n-Pull of multiple branches from one repository using `.git/remotes` file::\n+Commandline pull of multiple branches from one repository::\n +\n ------------------------------------------------\n-$ cat .git/remotes/origin\n-URL: git://git.kernel.org/pub/scm/git/git.git\n-Pull: master:origin\n-Pull: +pu:pu\n-Pull: maint:maint\n-\n $ git checkout master\n-$ git pull origin\n+$ git fetch origin master:origin +pu:pu maint:maint\n+$ git pull . origin\n ------------------------------------------------\n +\n-Here, a typical `.git/remotes/origin` file from a\n-`git-clone` operation has been hand-modified to include\n-the branch-mapping of additional remote and local\n-heads directly. A single `git-pull` operation while\n-in the `master` branch will fetch multiple heads and\n-merge the remote `origin` head into the current,\n-local `master` branch.\n+Assuming the same configuration as above, this overrides\n+the default fetch behavior, updating (or creating, as\n+necessary) branches \"origin\", \"pu\", and \"maint\" in the\n+local repository by fetching from the branches (respectively)\n+\"master\", \"pu\", and \"maint\" from the remote repository.\n++\n+The \"pu\" branch will be updated even if it is does not\n+fast-foward; the others will not be.\n \n \n If you tried a pull which resulted in a complex conflicts and\n@@ -112,7 +125,7 @@ gitlink:git-reset[1].\n \n SEE ALSO\n --------\n-gitlink:git-fetch[1], gitlink:git-merge[1]\n+gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]\n \n \n Author\n-- \n1.5.0.rc0.gac28\n"},{"id":"30595","messageId":"11676088581948-git-send-email-bfields@fieldses.org","threadId":"6178","inReplyTo":"11676088582634-git-send-email-bfields@fieldses.org","subject":"[PATCH] Documentation: update glossary entry for \"origin\"","fromName":"","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-31T23:47:36Z","receivedAt":"2006-12-31T23:47:36Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"From: J. Bruce Fields \n\nUpdate glossary entry for \"origin\" to reflect fact that it normally now refers\nto a remote repository, not a branch.\n\nAlso, warning not to work on remote-tracking branches is no longer necessary\nsince git doesn't allow that.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/glossary.txt | 7 ++++---\n 1 files changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/glossary.txt b/Documentation/glossary.txt\nindex 894883d..7c1a659 100644\n--- a/Documentation/glossary.txt\n+++ b/Documentation/glossary.txt\n@@ -188,11 +188,12 @@ octopus::\n \tpredator.\n \n origin::\n-\tThe default upstream tracking branch. Most projects have at\n+\tThe default upstream repository. Most projects have at\n \tleast one upstream project which they track. By default\n \t'origin' is used for that purpose. New upstream updates\n-\twill be fetched into this branch; you should never commit\n-\tto it yourself.\n+\twill be fetched into remote tracking branches named\n+\torigin/name-of-upstream-branch, which you can see using\n+\t\"git branch -r\".\n \n pack::\n \tA set of objects which have been compressed into one file (to save\n-- \n1.5.0.rc0.gac28\n"},{"id":"30593","messageId":"1167608858532-git-send-email-bfields@fieldses.org","threadId":"6178","inReplyTo":"11676088581948-git-send-email-bfields@fieldses.org","subject":"[PATCH] Documentation: remove master:origin example from pull-fetch-param.txt","fromName":"","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-31T23:47:37Z","receivedAt":"2006-12-31T23:47:37Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"From: J. Bruce Fields \n\nThis is no longer a useful example.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/pull-fetch-param.txt | 4 ----\n 1 files changed, 0 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt\nindex e852f41..8d4e950 100644\n--- a/Documentation/pull-fetch-param.txt\n+++ b/Documentation/pull-fetch-param.txt\n@@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of\n the progress of the remote side, and when you see something new\n on the remote branch, merge it into your development branch with\n `git pull . remote-B`, while you are on `my-B` branch.\n-The common `Pull: master:origin` mapping of a remote `master`\n-branch to a local `origin` branch, which is then merged to a\n-local development branch, again typically named `master`, is made\n-when you run `git clone` for you to follow this pattern.\n +\n [NOTE]\n There is a difference between listing multiple \n-- \n1.5.0.rc0.gac28\n"},{"id":"30597","messageId":"11676088581777-git-send-email-bfields@fieldses.org","threadId":"6178","inReplyTo":"1167608858532-git-send-email-bfields@fieldses.org","subject":"[PATCH] Documentation: update tutorial's discussion of origin","fromName":"","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-31T23:47:38Z","receivedAt":"2006-12-31T23:47:38Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"From: J. Bruce Fields \n\nUpdate tutorial's discussion of origin branch to reflect new defaults,\nand include a brief mention of git-repo-config.\n\nSigned-off-by: J. Bruce Fields \n---\n Documentation/tutorial.txt | 25 +++++++++++++++----------\n 1 files changed, 15 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex cb808d9..d043e84 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -323,20 +323,25 @@ $ git pull\n \n Note that he doesn't need to give the path to Alice's repository;\n when Bob cloned Alice's repository, git stored the location of her\n-repository in the file .git/remotes/origin, and that location is used\n-as the default for pulls.\n-\n-Bob may also notice a branch in his repository that he didn't create:\n+repository in the repository configuration, and that location is\n+used for pulls:\n \n -------------------------------------\n-$ git branch\n-* master\n- origin\n+$ git repo-config --get remote.origin.url\n+/home/bob/myrepo\n -------------------------------------\n \n-The \"origin\" branch, which was created automatically by \"git clone\",\n-is a pristine copy of Alice's master branch; Bob should never commit\n-to it.\n+(The complete configuration created by git-clone is visible using\n+\"git repo-config -l\", and the gitlink:git-repo-config[1] man page\n+explains the meaning of each option.)\n+\n+Git also keeps a pristine copy of Alice's master branch under the\n+name \"origin/master\":\n+\n+-------------------------------------\n+$ git branch -r\n+ origin/master\n+-------------------------------------\n \n If Bob later decides to work from a different host, he can still\n perform clones and pulls using the ssh protocol:\n-- \n1.5.0.rc0.gac28\n"},{"id":"30598","messageId":"7vd55zd1nm.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"11676088582634-git-send-email-bfields@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-01T00:35:41Z","receivedAt":"2007-01-01T00:35:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"bfields@fieldses.org writes:\n\n> git pull, git pull origin::\n> -\tFetch the default head from the repository you cloned\n> -\tfrom and merge it into your current branch.\n> +\tUpdate the remote tracking brances for the repository\n> +\tyou cloned from, then merge one of them into your\n> +\tcurrent branch. Normally the branch merged in is\n> +\tthe HEAD of the remote repository, when your master\n> +\tbranch is checked out. When on another branch,\n> +\tthe (alphabetically) first branch from the remote\n> +\trepository is merged in. These defaults can be modified\n> +\tusing the branch and remote sections of the repository\n> +\tconfiguration; see gitlink:git-repo-config[1] for details.\n\nI think documenting this is wrong. At least we should say \"do\nnot be lazy and say 'git pull' or 'git pull origin' without\nconfiguring what branch you are interested in when on a branch\nyou created yourself\". Later, people can supply patches to make\nthat configuration easier.\n\nWhen the user says \"pull origin\" while on another branch that\ndoes not have branch.$that_branch.merge properly configured, it\nhappens to find the first remote branch -- which unfortunately\ncomes from the wildcard remote.origin.fetch created by clone to\nsay \"track all remote branches\".\n\nWhat we wanted to do ideally was to forbid \"git pull\" that does\nnot have explicit refspec from the command line, without\nconfiguring branch.*.merge. However this broke established\nworkflow of people who has remote.$origin.fetch configured to\nlist the remote branch to fetch explicitly; the merged branch\nselection has always been \"the first set of branches listed in\nthe configuration\" and these peoples had their configuration\nright without needing to have branch.*.merge at all.\n\nUnfortunately git is too flexible around this area. \n\nWe probably could somehow arrante the remote branches that came\nfrom wildcarding not subject to the merge branch selection\nlogic, but honestly I am tired of looking at that code for now.\n\nAn acceptable short-term workaround might be to revert the\neffect of commit 3dd3d5b0.\n"},{"id":"30599","messageId":"20070101011220.GB15537@fieldses.org","threadId":"6178","inReplyTo":"7vd55zd1nm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-01T01:12:20Z","receivedAt":"2007-01-01T01:12:20Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Dec 31, 2006 at 04:35:41PM -0800, Junio C Hamano wrote:\n> bfields@fieldses.org writes:\n> \n> > git pull, git pull origin::\n> > -\tFetch the default head from the repository you cloned\n> > -\tfrom and merge it into your current branch.\n> > +\tUpdate the remote tracking brances for the repository\n> > +\tyou cloned from, then merge one of them into your\n> > +\tcurrent branch. Normally the branch merged in is\n> > +\tthe HEAD of the remote repository, when your master\n> > +\tbranch is checked out. When on another branch,\n> > +\tthe (alphabetically) first branch from the remote\n> > +\trepository is merged in. These defaults can be modified\n> > +\tusing the branch and remote sections of the repository\n> > +\tconfiguration; see gitlink:git-repo-config[1] for details.\n> \n> I think documenting this is wrong. At least we should say \"do\n> not be lazy and say 'git pull' or 'git pull origin' without\n> configuring what branch you are interested in when on a branch\n> you created yourself\". Later, people can supply patches to make\n> that configuration easier.\n\nYeah, OK, I'll admit I felt silly writing that; so for now, how about\njust omitting mention of the current behavior and saying instead\nsomething like this?:\n\n\t\".... Normally the branch merged in is\n\tthe HEAD of the remote repository, when your master\n\tbranch is checked out. For branches other than master,\n\tyou can choose the default remote branch to merge using the\n\tbranch..remote and branch..merge options; see\n\tgitlink:git-repo-config[1] for details.\"\n\n--b.\n"},{"id":"30600","messageId":"7vwt47bjwa.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"7vd55zd1nm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-01T01:44:37Z","receivedAt":"2007-01-01T01:44:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> What we wanted to do ideally was to forbid \"git pull\" that does\n> not have explicit refspec from the command line, without\n> configuring branch.*.merge. However this broke established\n> workflow of people who has remote.$origin.fetch configured to\n> list the remote branch to fetch explicitly; the merged branch\n> selection has always been \"the first set of branches listed in\n> the configuration\" and these peoples had their configuration\n> right without needing to have branch.*.merge at all.\n>\n> Unfortunately git is too flexible around this area. \n>\n> We probably could somehow arrante the remote branches that came\n> from wildcarding not subject to the merge branch selection\n> logic, but honestly I am tired of looking at that code for now.\n\nI am still tired of looking at the code, but I would rather \nlook at it now than having to still look at it next year.\n\nHow about doing this? The difference this time around is that\nif you have non-wildcard refspec listed first, which usually\nis the case for people with established git workflow with\nexisting repositories, we use the old-and-proven rule to\nmerge the first set of refs. An earlier round botched this\ncompletely by basing the logic on lack of branch.*.merge,\nwhich broke for many people.\n\n-- >8 --\n[PATCH] Do not merge random set of refs out of wildcarded refs\n\nWhen your fetch configuration has only the wildcards, we would\npick the lexicographically first ref from the remote side for\nmerging, which was complete nonsense. Make sure nothing except\nthe one that is specified with branch.*.merge is merged in this\ncase.\n\nSigned-off-by: Junio C Hamano \n\n---\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex 144f170..d2e4c2b 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -76,16 +76,32 @@ get_remote_default_refs_for_push () {\n # from get_remote_refs_for_fetch when it deals with refspecs\n # supplied on the command line. $ls_remote_result has the list\n # of refs available at remote.\n+#\n+# The first token returned is either \"explicit\" or \"glob\"; this\n+# is to help prevent randomly \"globbed\" ref from being chosen as\n+# a merge candidate\n expand_refs_wildcard () {\n+\tfirst_one=yes\n \tfor ref\n \tdo\n \t\tlref=${ref#'+'}\n \t\t# a non glob pattern is given back as-is.\n \t\texpr \"z$lref\" : 'zrefs/.*/\\*:refs/.*/\\*$' >/dev/null || {\n+\t\t\tif test -n \"$first_one\"\n+\t\t\tthen\n+\t\t\t\techo \"explicit\"\n+\t\t\t\tfirst_one=\n+\t\t\tfi\n \t\t\techo \"$ref\"\n \t\t\tcontinue\n \t\t}\n \n+\t\t# glob\n+\t\tif test -n \"$first_one\"\n+\t\tthen\n+\t\t\techo \"glob\"\n+\t\t\tfirst_one=\n+\t\tfi\n \t\tfrom=`expr \"z$lref\" : 'z\\(refs/.*/\\)\\*:refs/.*/\\*$'`\n \t\tto=`expr \"z$lref\" : 'zrefs/.*/\\*:\\(refs/.*/\\)\\*$'`\n \t\tlocal_force=\n@@ -116,7 +132,8 @@ canon_refs_list_for_fetch () {\n \tif test \"$1\" = \"-d\"\n \tthen\n \t\tshift ; remote=\"$1\" ; shift\n-\t\tset x $(expand_refs_wildcard \"$@\")\n+\t\tset $(expand_refs_wildcard \"$@\")\n+\t\tis_explicit=\"$1\"\n \t\tshift\n \t\tif test \"$remote\" = \"$(get_default_remote)\"\n \t\tthen\n@@ -125,6 +142,10 @@ canon_refs_list_for_fetch () {\n \t\t\tmerge_branches=$(git-repo-config \\\n \t\t\t --get-all \"branch.${curr_branch}.merge\")\n \t\tfi\n+\t\tif test -z \"$merge_branches\" && test $is_explicit != explicit\n+\t\tthen\n+\t\t\tmerge_branches=..this.will.never.match.any.ref..\n+\t\tfi\n \tfi\n \tfor ref\n \tdo\n"},{"id":"30603","messageId":"59142.7095.qm@web31801.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vwt47bjwa.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-01T03:29:22Z","receivedAt":"2007-01-01T03:29:22Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > What we wanted to do ideally was to forbid \"git pull\" that does\n> > not have explicit refspec from the command line, without\n> > configuring branch.*.merge. However this broke established\n> > workflow of people who has remote.$origin.fetch configured to\n> > list the remote branch to fetch explicitly; the merged branch\n> > selection has always been \"the first set of branches listed in\n> > the configuration\" and these peoples had their configuration\n> > right without needing to have branch.*.merge at all.\n> >\n> > Unfortunately git is too flexible around this area. \n> >\n> > We probably could somehow arrante the remote branches that came\n> > from wildcarding not subject to the merge branch selection\n> > logic, but honestly I am tired of looking at that code for now.\n> \n> I am still tired of looking at the code, but I would rather \n> look at it now than having to still look at it next year.\n> \n> How about doing this? The difference this time around is that\n> if you have non-wildcard refspec listed first, which usually\n> is the case for people with established git workflow with\n> existing repositories, we use the old-and-proven rule to\n> merge the first set of refs. An earlier round botched this\n> completely by basing the logic on lack of branch.*.merge,\n> which broke for many people.\n\nCan we please instead revisit the \"branch..remote\"\nand \"branch..merge\" options?\n\nWhat I'd really like to see and what really would be useful\nto me every day is if I could individually _address_ a\n\"branch..remote\" and \"branch..merge\" pair of\noptions.\n\nI.e. I'd like to say \"git-pull parent\" or \"git-pull parents\"\nin such and such branch, and this would pull the designated\nparent(s) for the current branch. But if I'm in a different\nbranch (of the same repo) then the meaning of \"parent\" changes\naccordingly.\n\nCurrently, the parent<-->child branch relationship only\nexists in paper: for example: git master is the parent for\nall my (local) branches, \"git-upstream\" is child of \"next\",\n\"git-lt-work\" is child of \"git-upstream\" and \"git-home\" is\nchild of \"git-lt-work\", each one introducing its own\ncustomizations and changes. I currently do the pull/merge\nby hand, remembering the child/parent relationship and enforcing\nit manually by the strict pull/merge sequence I do.\n\nOf course we shouldn't break existing usages like\nfor example \"git-pull . tag ...\".\n\nI can achieve the same thing using the \"branch.*\" options\ntoday, but I do \"git-pull\" and I'm not entrirely satisfied\nwith that since in my head I know I'm doing a \"parent->child\"\nmerge and would like to express that on the command line.\n\nSo this is something of a cross between the remotes/ and\n\"branch.*\" option.\n\nFor example \"branch...fetch\" and\n\"branch...merge\" would do the trick.\n\nThen at prompt, I say \"git-pull \" which will\nmatch local branch and symbolic name to whatever matches.\n\nOf course, \"branch...*\" would seem to be\nidentical to remotes. We should disallow that by stipulating\nthat a non-empty symbolic name imples non-empty branch name.\n\"branch...*\" would be identical to its current usage.\n\nThe point is that the symbolic name changes its designation depending\non which is the current branch, and with a name like \"parent\" that\nmakes sense.\n\n Luben\n"},{"id":"30604","messageId":"20070101034825.GD15537@fieldses.org","threadId":"6178","inReplyTo":"59142.7095.qm@web31801.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-01T03:48:25Z","receivedAt":"2007-01-01T03:48:25Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Dec 31, 2006 at 07:29:22PM -0800, Luben Tuikov wrote:\n> I.e. I'd like to say \"git-pull parent\" or \"git-pull parents\"\n> in such and such branch, and this would pull the designated\n> parent(s) for the current branch. But if I'm in a different\n> branch (of the same repo) then the meaning of \"parent\" changes\n> accordingly.\n\nCould you explain a situation where this would be useful? A\n\"parent<-->child\" relationship, where there's one upstream branch that\nis always merged in, is easily handled; just replace your \"git pull\nparent\" by a \"git pull\", right? Am I misunderstanding the proposal?\n\nAnd is there any reason why your proposal conflicts with Junio's?\n\n--b.\n"},{"id":"30605","messageId":"951491.40207.qm@web31807.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070101034825.GD15537@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-01T05:13:49Z","receivedAt":"2007-01-01T05:13:49Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"J. Bruce Fields\" wrote:\n> On Sun, Dec 31, 2006 at 07:29:22PM -0800, Luben Tuikov wrote:\n> > I.e. I'd like to say \"git-pull parent\" or \"git-pull parents\"\n> > in such and such branch, and this would pull the designated\n> > parent(s) for the current branch. But if I'm in a different\n> > branch (of the same repo) then the meaning of \"parent\" changes\n> > accordingly.\n> \n> Could you explain a situation where this would be useful?\n\nI don't know how to respond to this question.\n\n> A\n> \"parent<-->child\" relationship, where there's one upstream branch that\n> is always merged in, is easily handled;\n\ne is the base of natural logarithms.\n\n> just replace your \"git pull parent\" by a \"git pull\", right?\n\nYes, but I don't want to just type \"git-pull\", I want to explicitly\ntype \"git-pull parent\" and depending in which branch I'm at, \"parent\"\nwould have identical meaning but would merge a different branch... because\nI'm in a different branch...\n\n(Since this is what is actually ment by the \"branch.*\" options.)\n\n> Am I misunderstanding the proposal?\n\nI did give an example of usage in my email to which you replied.\n\nBasically I'd like to extend the concept of \"branch spec\" locally.\n\n> And is there any reason why your proposal conflicts with Junio's?\n\nYes. Beating on a dead horse. \"branch.*\" options simply do not cut it.\nWe can either get rid of them completely or extend them to where they\nare actually useful. Globbing resolution is secondary to resolving\nthe methodology.\n\nHTH,\n Luben\n"},{"id":"30606","messageId":"20070101054536.GG15537@fieldses.org","threadId":"6178","inReplyTo":"951491.40207.qm@web31807.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-01T05:45:36Z","receivedAt":"2007-01-01T05:45:36Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Dec 31, 2006 at 09:13:49PM -0800, Luben Tuikov wrote:\n> Yes, but I don't want to just type \"git-pull\", I want to explicitly\n> type \"git-pull parent\" and depending in which branch I'm at, \"parent\"\n> would have identical meaning but would merge a different branch... because\n> I'm in a different branch...\n\nWouldn't it do what you want if by default \"git branch new\" and \"git\ncheckout -b new\" set branch.* options that pointed at the \"parent\"\nbranch?\n\nThe only reason I can see to require the extra bit of syntax (\"git-pull\nparent\" instead of \"git-pull\") is if for the same branch you expect to\nsometimes pull from one source and sometimes from another, and the pulls\nfrom those various sources are common enough that it's worth defining\nsome shortcuts for more than one of them.\n\nI can imagine sometimes doing that. (E.g. if you pull into your master\nbranch from upstream and from local topic branches.) But in that case\nhaving to give the remote and branch name explicitly doesn't seem so\nbad.\n\nI dunno....\n\n--b.\n"},{"id":"30611","messageId":"7vfyav8ae1.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"951491.40207.qm@web31807.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-01T07:38:14Z","receivedAt":"2007-01-01T07:38:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- \"J. Bruce Fields\" wrote:\n> ...\n>> Could you explain a situation where this would be useful?\n>\n> I don't know how to respond to this question.\n>\n>> A\n>> \"parent<-->child\" relationship, where there's one upstream branch that\n>> is always merged in, is easily handled;\n>\n> e is the base of natural logarithms.\n\nYou lost me here; I am guessing this is some sarcasm not worth\npaying attention to, so I'd ignore this part for now.\n\n>> just replace your \"git pull parent\" by a \"git pull\", right?\n>\n> Yes, but I don't want to just type \"git-pull\", I want to explicitly\n> type \"git-pull parent\" and depending in which branch I'm at, \"parent\"\n> would have identical meaning but would merge a different branch... because\n> I'm in a different branch...\n>\n>> Am I misunderstanding the proposal?\n>\n> I did give an example of usage in my email to which you replied.\n\nBut what confuses me (and I think JBF shares the same confusion\nwith me) is that you had only one example \"parent\".\n\nWhile I understand that it would make sense to define \"parent\"\nfor each branch in a downstream developer's workflow, (1) I do\nnot see the difference between your wording, \"parent\", and what\nwe traditionally have called \"origin\", and (2) I do not think of\nrelationship other than \"parent\" (\"origin\") that is applicable\ncommonly (in other words, \"worth having your 'symbolic'\nmechanism for, because it is so commonly applicable\") to\nbranches offhand. Hence, JBF's suggestion to use \"git pull\"\nwithout using noiseword \"parent\" or \"origin\" feels very natural\nto me --- if there can be only one valid thing to say, why do\nyou even have to say it?\n\nBecause I do not understand what you would want \"parent\" for and\nwhy \"git pull\" is not sufficient, I cannot tell if this would\nhelp solving what you are trying to solve in a different way,\nbut I suspect a useful thing to have might be a per-branch\nalias. For example, we could allow \"git merge\" without\nparameters to alias to \"git merge origin/next\" when you are on\nyour 'next' and the same \"git merge\" could be aliased to \"git\nmerge origin/master\" when you are on your 'master'.\n"},{"id":"30612","messageId":"452383.57759.qm@web31813.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070101054536.GG15537@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-01T07:53:53Z","receivedAt":"2007-01-01T07:53:53Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"J. Bruce Fields\" wrote:\n> On Sun, Dec 31, 2006 at 09:13:49PM -0800, Luben Tuikov wrote:\n> > Yes, but I don't want to just type \"git-pull\", I want to explicitly\n> > type \"git-pull parent\" and depending in which branch I'm at, \"parent\"\n> > would have identical meaning but would merge a different branch... because\n> > I'm in a different branch...\n> \n> Wouldn't it do what you want if by default \"git branch new\" and \"git\n> checkout -b new\" set branch.* options that pointed at the \"parent\"\n> branch?\n\nTechnically yes. Presentationally no.\n\n> The only reason I can see to require the extra bit of syntax (\"git-pull\n> parent\" instead of \"git-pull\") is if for the same branch you expect to\n> sometimes pull from one source and sometimes from another, and the pulls\n> from those various sources are common enough that it's worth defining\n> some shortcuts for more than one of them.\n\nExactly.\n\n> I can imagine sometimes doing that. (E.g. if you pull into your master\n> branch from upstream and from local topic branches.) But in that case\n> having to give the remote and branch name explicitly doesn't seem so\n> bad.\n\nBasically I want to _name_ the dependency, instead of having it be\nimplicit. One can extend that dependency, in more complicated\ntopic branch relationship, where for example, C extends B, B extends\nA, A extends master, but B' also extends A, consider B' a \"version\"\nof the extension which B implements. This is of course a trivial\nexample and more complicated ones exist.\n\nNaming the dependency would give git greater coverage when it needs\nto implement complicated source development environments and code\nrelationship. IOW, it is the way to go. Having a single implicit\ndependency is just a crutch, half-way there.\n\nOr, one can look at it in a different way, extending the\nremote/ functionality as is, but instead of being remote-pulls-\ninto-local, extending for local pulls into local.\n\nI.e. the remote relationship is named, I'd like to extend\nthis locally as well.\n\nConsider the examples of \"branch...{fetch, merge}\"\nI gave in a previous email in this thread.\n\n Luben\n"},{"id":"30615","messageId":"997672.38239.qm@web31814.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vfyav8ae1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-01T08:19:45Z","receivedAt":"2007-01-01T08:19:45Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > --- \"J. Bruce Fields\" wrote:\n> > ...\n> >> Could you explain a situation where this would be useful?\n> >\n> > I don't know how to respond to this question.\n> >\n> >> A\n> >> \"parent<-->child\" relationship, where there's one upstream branch that\n> >> is always merged in, is easily handled;\n> >\n> > e is the base of natural logarithms.\n> \n> You lost me here; I am guessing this is some sarcasm not worth\n> paying attention to, so I'd ignore this part for now.\n\nAbsolutely correct. I just needed to respond to an obvious fact with\nanother obvious fact.\n\n> >> just replace your \"git pull parent\" by a \"git pull\", right?\n> >\n> > Yes, but I don't want to just type \"git-pull\", I want to explicitly\n> > type \"git-pull parent\" and depending in which branch I'm at, \"parent\"\n> > would have identical meaning but would merge a different branch... because\n> > I'm in a different branch...\n> >\n> >> Am I misunderstanding the proposal?\n> >\n> > I did give an example of usage in my email to which you replied.\n> \n> But what confuses me (and I think JBF shares the same confusion\n> with me) is that you had only one example \"parent\".\n\nMore complicated and exotic examples exist. See my response\nto JBF, which I just posted a moment ago.\n\n> While I understand that it would make sense to define \"parent\"\n\nNo, no, no. Forget about the semantic attibute of \"parent\".\nI could've called it \"xyz\" for that matter.\n\nWhat I'm talking about is the concept of \"branch spec\". It\nis a well known concept in SCMs.\n\nWe currently implement it, in git specific way, for remotes/\nonly, but not for local (\"topic\") branches.\n\nAnother way to look at it is that a Topic, can have many\nother self-contained sub-Topics, each one building on the one\n\"before\" it, extending it, yet introducing new functionality,\nand only in the \"leaf\" branch, do you get a fully capable software.\nEach sub-topic branch is also a working software but only implements\npart of the functionality of your product and/or toned down version\nof it, say if someone doesn't want support for feature ABC, which\nuses 100MiB of memory...\n\n> for each branch in a downstream developer's workflow, (1) I do\n> not see the difference between your wording, \"parent\", and what\n> we traditionally have called \"origin\",\n\nI've always contended that it is the same and had mentioned\nthat it is only implemented for remotes/.\n\n> and (2) I do not think of\n> relationship other than \"parent\" (\"origin\") that is applicable\n> commonly (in other words, \"worth having your 'symbolic'\n> mechanism for, because it is so commonly applicable\") to\n> branches offhand. Hence, JBF's suggestion to use \"git pull\"\n> without using noiseword \"parent\" or \"origin\" feels very natural\n> to me --- if there can be only one valid thing to say, why do\n> you even have to say it?\n\nWell, this is the question... Can you stipulate that there is\nonly _one_ valid thing to say? Wouldn't it be easier to generalize\nthe concept of \"branch spec\" to local \"topic\" branches as we do\nnow for remotes/. Wouldn't this allow people to have more freedom\nat what and how they'd like to set their software dependencies?\n\nThe SCM industry seem to have generalized this with the\nconcept of a \"branch spec\".\n\n> Because I do not understand what you would want \"parent\" for and\n> why \"git pull\" is not sufficient,\n\nBecause it _implicitly_ defines the relationship. Nothing wrong\nwith that, but also allowing an explicit naming of the relationship,\nas is currently done for remotes/, would give git much, much more\npower to define even the most complicated software development\nsetup (locally).\n\nAs I pointed out before, \"branch...{fetch,merge}\" would\ncover the \"git-pull\" case. \"branch...{fetch,merge}\"\nshould be illegal since it is the same as remotes/, and\n\"branch...{fetch, merge}\" matches\n\"git-pull \".\n\n> I cannot tell if this would\n> help solving what you are trying to solve in a different way,\n\n1) It would help solve it the proper way and,\n2) it would give git the concept of \"branch spec\" universally, i.e.\nlocal branches as well as remotes.\n\n> but I suspect a useful thing to have might be a per-branch\n> alias. For example, we could allow \"git merge\" without\n> parameters to alias to \"git merge origin/next\" when you are on\n> your 'next' and the same \"git merge\" could be aliased to \"git\n> merge origin/master\" when you are on your 'master'.\n\nAny why not solve the absolute general case forever, by\nimplementing what I have described above, and move on\nto more interesting things?\n\n Luben\n"},{"id":"30619","messageId":"20070101131726.GA21933@thunk.org","threadId":"6178","inReplyTo":"997672.38239.qm@web31814.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-01T13:17:26Z","receivedAt":"2007-01-01T13:17:26Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"Luben,\n\nLet me see if I can understand what you are asking for without using\nthe term \"branch spec\", which I don't think has been adequately\ndefined yet in this thread. (Where \"the SCM industry has adopted\"\nisn't a definition. :-)\n\nCurrently, today, if you type:\n\n\tgit fetch \n\n... it will look up \"\" in a single global namespace, which\n(using only the new config scheme) is looked up in remote.\nand remote..{url,fetch} is used to control the operation of\ngit-fetch.\n\nWhat you want to do is to change this to where:\n\n\tgit fetch \n\n...will now lookup \"\" in a namespace which is qualified by\nthe branch that you are in. So you want to look up the information in\nbranches...{url,fetch} instead.\n\nYou haven't stated it explicitly, but I assume that if\nbranches.. doesn't exist, you're proposing\nthat the code fall back to looking in the old configuration parameter,\nremote., so that certain names that should be global can\ncontinue to be global, and that people who want a single global\nnamespace can continue to have it?\n\nIs that your proposal, stripped of the arguments of why you want it,\nand of the somewhat confusing \"parent\" example (which is a bad one\ngiven that your \"git pull parent\" example was the semantic equivalent\nof \"git pull\")?\n\nIf it is, I'm a bit nervous since it's making the git-fetch command\nmodal, and modal UI's are confusing to users. On the other hand, it's\na fundamental modality we have already (based on the question \"which\nbranch am I\"), and there are hacks that will allow you to put the\ncurrent branch into your command-line. And as long as you are\nproposing a lookup in branches.current.branch. first before\nchecking remotes. it seems mostly harmless to me. I doubt\nI'd ever use it, but maybe it would be helpful to some.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"30627","messageId":"20070101213906.GA23857@fieldses.org","threadId":"6178","inReplyTo":"7vwt47bjwa.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-01T21:39:06Z","receivedAt":"2007-01-01T21:39:06Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:\n> How about doing this? The difference this time around is that\n> if you have non-wildcard refspec listed first, which usually\n> is the case for people with established git workflow with\n> existing repositories, we use the old-and-proven rule to\n> merge the first set of refs. An earlier round botched this\n> completely by basing the logic on lack of branch.*.merge,\n> which broke for many people.\n\nUpdated man page assuming that change; does this look any better?\n\n--b.\n\n[PATCH] Documentation: update git-pull.txt for new clone behavior\n\nUpdate examples, stop using branch named \"origin\" as an example.\nRemove large example of use of remotes; that particular case is\nnicely automated by default, so it's not so pressing to explain, and\nwe can refer to git-repo-config for the details.\n\nSigned-off-by: \"J. Bruce Fields\" \n---\n Documentation/git-pull.txt | 69 ++++++++++++++++----------------------------\n 1 files changed, 25 insertions(+), 44 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 2a5aea7..13be992 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -37,17 +37,27 @@ EXAMPLES\n --------\n \n git pull, git pull origin::\n-\tFetch the default head from the repository you cloned\n-\tfrom and merge it into your current branch.\n-\n-git pull -s ours . obsolete::\n-\tMerge local branch `obsolete` into the current branch,\n-\tusing `ours` merge strategy.\n+\tUpdate the remote-tracking branches for the repository\n+\tyou cloned from, then merge one of them into your\n+\tcurrent branch. Normally the branch merged in is\n+\tthe HEAD of the remote repository, but the choice is\n+\tdetermined by the branch..remote and\n+\tbranch..merge options; see gitlink:git-repo-config[1]\n+\tfor details.\n+\n+git pull origin next::\n+\tMerge into the current branch the remote branch `next`;\n+\tleaves a copy of `next` temporarily in FETCH_HEAD, but\n+\tdoes not update any remote-tracking branches.\n \n git pull . fixes enhancements::\n \tBundle local branch `fixes` and `enhancements` on top of\n \tthe current branch, making an Octopus merge.\n \n+git pull -s ours . obsolete::\n+\tMerge local branch `obsolete` into the current branch,\n+\tusing `ours` merge strategy.\n+\n git pull --no-commit . maint::\n \tMerge local branch `maint` into the current branch, but\n \tdo not make a commit automatically. This can be used\n@@ -61,48 +71,19 @@ release/version name would be acceptable.\n Command line pull of multiple branches from one repository::\n +\n ------------------------------------------------\n-$ cat .git/remotes/origin\n-URL: git://git.kernel.org/pub/scm/git/git.git\n-Pull: master:origin\n-\n $ git checkout master\n-$ git fetch origin master:origin +pu:pu maint:maint\n-$ git pull . origin\n+$ git fetch origin +pu:pu maint:tmp\n+$ git pull . tmp\n ------------------------------------------------\n +\n-Here, a typical `.git/remotes/origin` file from a\n-`git-clone` operation is used in combination with\n-command line options to `git-fetch` to first update\n-multiple branches of the local repository and then\n-to merge the remote `origin` branch into the local\n-`master` branch. The local `pu` branch is updated\n-even if it does not result in a fast forward update.\n-Here, the pull can obtain its objects from the local\n-repository using `.`, as the previous `git-fetch` is\n-known to have already obtained and made available\n-all the necessary objects.\n-\n-\n-Pull of multiple branches from one repository using `.git/remotes` file::\n+This updates (or creates, as necessary) branches `pu` and `tmp`\n+in the local repository by fetching from the branches\n+(respectively) `pu` and `maint` from the remote repository.\n +\n-------------------------------------------------\n-$ cat .git/remotes/origin\n-URL: git://git.kernel.org/pub/scm/git/git.git\n-Pull: master:origin\n-Pull: +pu:pu\n-Pull: maint:maint\n-\n-$ git checkout master\n-$ git pull origin\n-------------------------------------------------\n+The `pu` branch will be updated even if it is does not\n+fast-forward; the others will not be.\n +\n-Here, a typical `.git/remotes/origin` file from a\n-`git-clone` operation has been hand-modified to include\n-the branch-mapping of additional remote and local\n-heads directly. A single `git-pull` operation while\n-in the `master` branch will fetch multiple heads and\n-merge the remote `origin` head into the current,\n-local `master` branch.\n+The final command then merges the newly fetched `tmp` into master.\n \n \n If you tried a pull which resulted in a complex conflicts and\n@@ -112,7 +93,7 @@ gitlink:git-reset[1].\n \n SEE ALSO\n --------\n-gitlink:git-fetch[1], gitlink:git-merge[1]\n+gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]\n \n \n Author\n-- \n1.5.0.rc0.gac28\n"},{"id":"30628","messageId":"20070101214023.GB23857@fieldses.org","threadId":"6178","inReplyTo":"20070101213906.GA23857@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-01T21:40:23Z","receivedAt":"2007-01-01T21:40:23Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Jan 01, 2007 at 04:39:06PM -0500, J. Bruce Fields wrote:\n> On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:\n> > How about doing this? The difference this time around is that\n> > if you have non-wildcard refspec listed first, which usually\n> > is the case for people with established git workflow with\n> > existing repositories, we use the old-and-proven rule to\n> > merge the first set of refs. An earlier round botched this\n> > completely by basing the logic on lack of branch.*.merge,\n> > which broke for many people.\n> \n> Updated man page assuming that change; does this look any better?\n\nAlso, resend of the following patch:\n\n--b.\n\n[PATCH] Documentation: remove master:origin example from pull-fetch-param.txt\n\nThis is no longer a useful example.\n\nSigned-off-by: \"J. Bruce Fields\" \n---\n Documentation/pull-fetch-param.txt | 4 ----\n 1 files changed, 0 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt\nindex e852f41..8d4e950 100644\n--- a/Documentation/pull-fetch-param.txt\n+++ b/Documentation/pull-fetch-param.txt\n@@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of\n the progress of the remote side, and when you see something new\n on the remote branch, merge it into your development branch with\n `git pull . remote-B`, while you are on `my-B` branch.\n-The common `Pull: master:origin` mapping of a remote `master`\n-branch to a local `origin` branch, which is then merged to a\n-local development branch, again typically named `master`, is made\n-when you run `git clone` for you to follow this pattern.\n +\n [NOTE]\n There is a difference between listing multiple \n-- \n1.5.0.rc0.gac28\n"},{"id":"30629","messageId":"926020.70066.qm@web31802.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070101131726.GA21933@thunk.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-01T23:56:05Z","receivedAt":"2007-01-01T23:56:05Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Theodore Tso wrote:\n> Luben,\n> \n> Let me see if I can understand what you are asking for without using\n> the term \"branch spec\", which I don't think has been adequately\n> defined yet in this thread. (Where \"the SCM industry has adopted\"\n> isn't a definition. :-)\n\nYou can also think of it as \"the merge direction given a symbolic name\".\n\n> Currently, today, if you type:\n> \n> \tgit fetch \n> \n> ... it will look up \"\" in a single global namespace, which\n> (using only the new config scheme) is looked up in remote.\n> and remote..{url,fetch} is used to control the operation of\n> git-fetch.\n\nI'm talking about more in terms of git-merge, but since git-pull\nis a git-fetch and git-merge, I've been using git-pull for completeness.\nIOW, I've tried to concentrate on a per-repo operations (merge) as opposed\nto on a multi-repo, which is currently handled by git as is expected.\n\n> What you want to do is to change this to where:\n> \n> \tgit fetch \n\ngit-pull, for completeness. See my paragraph above.\n\n> ...will now lookup \"\" in a namespace which is qualified by\n> the branch that you are in. So you want to look up the information in\n> branches...{url,fetch} instead.\n\nMore specifically,\nbranch...{fetch,merge}.\n\nbranch...{fetch,merge} is allowed and defalts\nto already implemented \"git-pull\".\n\nbranch...{fetch,merge} is forbidden\nsince it is essentially remotes/ and is handled by the current\n\"remotes/\" infrastructure by git.\n\nbranch...{fetch,merge} will\nperform the fetch, which would be a no-op, since the branch\nwe're \"fetching\" is local, and the merge merges into the\ncurrent branch if it matches.\n\n> You haven't stated it explicitly, but I assume that if\n> branches.. doesn't exist, you're proposing\n> that the code fall back to looking in the old configuration parameter,\n> remote., so that certain names that should be global can\n> continue to be global, and that people who want a single global\n> namespace can continue to have it?\n\nYes, I absolutely do not want to break existing behavior. But\nif it is extended, it should be done properly, and a general\ncase should be solved as to solve this once and forever.\n\n> Is that your proposal, stripped of the arguments of why you want it,\n> and of the somewhat confusing \"parent\" example (which is a bad one\n> given that your \"git pull parent\" example was the semantic equivalent\n> of \"git pull\")?\n\nMore or less. Basically, I want local \"git-pull\" (fetch[no-op],merge)\nto be addressable, i.e. _named_, so that I can establish a more complex\nsoftware dependency, which I currently do, my means of the order and\nthe type of \"git-pull . \" I do.\n\n> If it is, I'm a bit nervous since it's making the git-fetch command\n> modal, and modal UI's are confusing to users.\n\nThink of \"git-pull\", not just of \"git-fetch\". As well as think\nof a setup where there are more than one branch implementing\nsoftware dependency, resolving to a software product.\n\n> On the other hand, it's\n> a fundamental modality we have already (based on the question \"which\n> branch am I\"), and there are hacks that will allow you to put the\n> current branch into your command-line.\n\nAh, yes. Well, the many-branches-one-directory is confusing and\nis modal. *But*, it doesn't have to be like that. Git allows\nthe freedom to define branch-per-directory-yet-single-repo which I've\nabsolutely always used with GIT, and other SCMs. This way it is\nabsolutely unambiguous \"what branch I'm at\".\n\nIt is in this sense that I do \"cd ; git-pull . \"\nin a sequence, and I'd rather do \"cd ; git-pull \"\nto define which branch is the merge coming from given the current branch\n_and_ the symbolic ref.\n\n> And as long as you are\n> proposing a lookup in branches.current.branch. first before\n> checking remotes. it seems mostly harmless to me. I doubt\n> I'd ever use it, but maybe it would be helpful to some.\n\nYes, current behavior should absolutely not be broken.\nFirst (,) is matched against\n\"branch...{fetch,merge}\" modulo the \ncases I've outlined before, and then if everything else\nfails, we default to remote/.\n\n Luben\n"},{"id":"30630","messageId":"535252.4420.qm@web31811.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070101213906.GA23857@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-01T23:59:44Z","receivedAt":"2007-01-01T23:59:44Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"J. Bruce Fields\" wrote:\n> On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:\n> > How about doing this? The difference this time around is that\n> > if you have non-wildcard refspec listed first, which usually\n> > is the case for people with established git workflow with\n> > existing repositories, we use the old-and-proven rule to\n> > merge the first set of refs. An earlier round botched this\n> > completely by basing the logic on lack of branch.*.merge,\n> > which broke for many people.\n> \n> Updated man page assuming that change; does this look any better?\n> \n> --b.\n> \n> [PATCH] Documentation: update git-pull.txt for new clone behavior\n> \n> Update examples, stop using branch named \"origin\" as an example.\n> Remove large example of use of remotes; that particular case is\n> nicely automated by default, so it's not so pressing to explain, and\n> we can refer to git-repo-config for the details.\n> \n> Signed-off-by: \"J. Bruce Fields\" \n> ---\n> Documentation/git-pull.txt | 69 ++++++++++++++++----------------------------\n> 1 files changed, 25 insertions(+), 44 deletions(-)\n> \n> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> index 2a5aea7..13be992 100644\n> --- a/Documentation/git-pull.txt\n> +++ b/Documentation/git-pull.txt\n> @@ -37,17 +37,27 @@ EXAMPLES\n> --------\n> \n> git pull, git pull origin::\n> -\tFetch the default head from the repository you cloned\n> -\tfrom and merge it into your current branch.\n> -\n> -git pull -s ours . obsolete::\n> -\tMerge local branch `obsolete` into the current branch,\n> -\tusing `ours` merge strategy.\n> +\tUpdate the remote-tracking branches for the repository\n> +\tyou cloned from, then merge one of them into your\n> +\tcurrent branch. Normally the branch merged in is\n> +\tthe HEAD of the remote repository, but the choice is\n> +\tdetermined by the branch..remote and\n> +\tbranch..merge options; see gitlink:git-repo-config[1]\n> +\tfor details.\n> +\n> +git pull origin next::\n\nNo.\n\n> +\tMerge into the current branch the remote branch `next`;\n\nSo, \"origin\" now means \"current branch\".\n\nNACK!\n\n Luben\n\n\n> +\tleaves a copy of `next` temporarily in FETCH_HEAD, but\n> +\tdoes not update any remote-tracking branches.\n> \n> git pull . fixes enhancements::\n> \tBundle local branch `fixes` and `enhancements` on top of\n> \tthe current branch, making an Octopus merge.\n> \n> +git pull -s ours . obsolete::\n> +\tMerge local branch `obsolete` into the current branch,\n> +\tusing `ours` merge strategy.\n> +\n> git pull --no-commit . maint::\n> \tMerge local branch `maint` into the current branch, but\n> \tdo not make a commit automatically. This can be used\n> @@ -61,48 +71,19 @@ release/version name would be acceptable.\n> Command line pull of multiple branches from one repository::\n> +\n> ------------------------------------------------\n> -$ cat .git/remotes/origin\n> -URL: git://git.kernel.org/pub/scm/git/git.git\n> -Pull: master:origin\n> -\n> $ git checkout master\n> -$ git fetch origin master:origin +pu:pu maint:maint\n> -$ git pull . origin\n> +$ git fetch origin +pu:pu maint:tmp\n> +$ git pull . tmp\n> ------------------------------------------------\n> +\n> -Here, a typical `.git/remotes/origin` file from a\n> -`git-clone` operation is used in combination with\n> -command line options to `git-fetch` to first update\n> -multiple branches of the local repository and then\n> -to merge the remote `origin` branch into the local\n> -`master` branch. The local `pu` branch is updated\n> -even if it does not result in a fast forward update.\n> -Here, the pull can obtain its objects from the local\n> -repository using `.`, as the previous `git-fetch` is\n> -known to have already obtained and made available\n> -all the necessary objects.\n> -\n> -\n> -Pull of multiple branches from one repository using `.git/remotes` file::\n> +This updates (or creates, as necessary) branches `pu` and `tmp`\n> +in the local repository by fetching from the branches\n> +(respectively) `pu` and `maint` from the remote repository.\n> +\n> -------------------------------------------------\n> -$ cat .git/remotes/origin\n> -URL: git://git.kernel.org/pub/scm/git/git.git\n> -Pull: master:origin\n> -Pull: +pu:pu\n> -Pull: maint:maint\n> -\n> -$ git checkout master\n> -$ git pull origin\n> -------------------------------------------------\n> +The `pu` branch will be updated even if it is does not\n> +fast-forward; the others will not be.\n> +\n> -Here, a typical `.git/remotes/origin` file from a\n> -`git-clone` operation has been hand-modified to include\n> -the branch-mapping of additional remote and local\n> -heads directly. A single `git-pull` operation while\n> -in the `master` branch will fetch multiple heads and\n> -merge the remote `origin` head into the current,\n> -local `master` branch.\n> +The final command then merges the newly fetched `tmp` into master.\n> \n> \n> If you tried a pull which resulted in a complex conflicts and\n> @@ -112,7 +93,7 @@ gitlink:git-reset[1].\n> \n> SEE ALSO\n> --------\n> -gitlink:git-fetch[1], gitlink:git-merge[1]\n> +gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]\n> \n> \n> Author\n> -- \n> 1.5.0.rc0.gac28\n> \n> \n"},{"id":"30631","messageId":"182318.86313.qm@web31812.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070101214023.GB23857@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T00:01:15Z","receivedAt":"2007-01-02T00:01:15Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"J. Bruce Fields\" wrote:\n> On Mon, Jan 01, 2007 at 04:39:06PM -0500, J. Bruce Fields wrote:\n> > On Sun, Dec 31, 2006 at 05:44:37PM -0800, Junio C Hamano wrote:\n> > > How about doing this? The difference this time around is that\n> > > if you have non-wildcard refspec listed first, which usually\n> > > is the case for people with established git workflow with\n> > > existing repositories, we use the old-and-proven rule to\n> > > merge the first set of refs. An earlier round botched this\n> > > completely by basing the logic on lack of branch.*.merge,\n> > > which broke for many people.\n> > \n> > Updated man page assuming that change; does this look any better?\n> \n> Also, resend of the following patch:\n> \n> --b.\n> \n> [PATCH] Documentation: remove master:origin example from pull-fetch-param.txt\n> \n> This is no longer a useful example.\n> \n> Signed-off-by: \"J. Bruce Fields\" \n> ---\n> Documentation/pull-fetch-param.txt | 4 ----\n> 1 files changed, 0 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt\n> index e852f41..8d4e950 100644\n> --- a/Documentation/pull-fetch-param.txt\n> +++ b/Documentation/pull-fetch-param.txt\n> @@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of\n> the progress of the remote side, and when you see something new\n> on the remote branch, merge it into your development branch with\n> `git pull . remote-B`, while you are on `my-B` branch.\n> -The common `Pull: master:origin` mapping of a remote `master`\n> -branch to a local `origin` branch, which is then merged to a\n> -local development branch, again typically named `master`, is made\n> -when you run `git clone` for you to follow this pattern.\n\nSo is this no longer the case?\n\nCan someone please bring me up to date?\n\nWhat is going on?\n\n Luben\n\n\n\n> +\n> [NOTE]\n> There is a difference between listing multiple \n> -- \n> 1.5.0.rc0.gac28\n> \n> \n"},{"id":"30632","messageId":"20070102000606.GA32148@fieldses.org","threadId":"6178","inReplyTo":"535252.4420.qm@web31811.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-02T00:06:06Z","receivedAt":"2007-01-02T00:06:06Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Jan 01, 2007 at 03:59:44PM -0800, Luben Tuikov wrote:\n> --- \"J. Bruce Fields\" wrote:\n> > +git pull origin next::\n> \n> No.\n> \n> > +\tMerge into the current branch the remote branch `next`;\n> \n> So, \"origin\" now means \"current branch\".\n\nNo, \"origin\" refers to the remote repository that you originally cloned\nfrom.\n\nPulls always merge into the current branch. So it wouldn't make sense\nto specify the current branch on the command line.\n\n--b.\n"},{"id":"30636","messageId":"20070102001044.GB32148@fieldses.org","threadId":"6178","inReplyTo":"182318.86313.qm@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-02T00:10:44Z","receivedAt":"2007-01-02T00:10:44Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Jan 01, 2007 at 04:01:15PM -0800, Luben Tuikov wrote:\n> --- \"J. Bruce Fields\" wrote:\n> > -The common `Pull: master:origin` mapping of a remote `master`\n> > -branch to a local `origin` branch, which is then merged to a\n> > -local development branch, again typically named `master`, is made\n> > -when you run `git clone` for you to follow this pattern.\n> \n> So is this no longer the case?\n\nRight; that mapping is no longer what git clone sets up for you.\n\n> Can someone please bring me up to date?\n> \n> What is going on?\n\nThe simplest way to understand the current behavior is probably to\ninstall the latest git, read the git-clone man page, clone a new\nrepository, and take a look at it.\n\nRemote branches are stored in separate namespaces under\n.git/refs/remotes/, so that they don't muck up your view of your local\nbranches, and so git can enforce different policies for them (such as\nforbidding committing to them).\n\n--b.\n"},{"id":"30637","messageId":"7vhcva4782.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"20070102000606.GA32148@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T00:12:29Z","receivedAt":"2007-01-02T00:12:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Mon, Jan 01, 2007 at 03:59:44PM -0800, Luben Tuikov wrote:\n>> --- \"J. Bruce Fields\" wrote:\n>> > +git pull origin next::\n>> \n>> No.\n>> \n>> > +\tMerge into the current branch the remote branch `next`;\n>> \n>> So, \"origin\" now means \"current branch\".\n>\n> No, \"origin\" refers to the remote repository that you originally cloned\n> from.\n>\n> Pulls always merge into the current branch. So it wouldn't make sense\n> to specify the current branch on the command line.\n\nI was also somewhat confused by these examples. I think the\ndescription is fine as long as we make it clear that they are\nnot meant to describe what an advanced user _could_ do with\nvarious customizations, but to describe what happens with the\ndefault configuration set up by git-clone.\n"},{"id":"30638","messageId":"7vd55y46ta.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"182318.86313.qm@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T00:21:21Z","receivedAt":"2007-01-02T00:21:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- \"J. Bruce Fields\" wrote:\n> ...\n>> -The common `Pull: master:origin` mapping of a remote `master`\n>> -branch to a local `origin` branch, which is then merged to a\n>> -local development branch, again typically named `master`, is made\n>> -when you run `git clone` for you to follow this pattern.\n>\n> So is this no longer the case?\n>\n> Can someone please bring me up to date?\n>\n> What is going on?\n\nWhat's going on is clean-up towards v1.5.0-rc1 ;-).\n\n - 'git clone' does not create a file that has a line that looks\n like \"Pull: master:origin\" anywhere anymore.\n\n - 'git clone' also does not create the traditional \"'master' is\n special and we map that to origin, others are mapped as is\n under refs/heads/, and we have to drop 'origin' from the\n remote side because that name we want to use to store their\n 'master'\" layout.\n\nSo after a clone, you would get:\n\n\t[remote \"origin\"]\n \turl = ....\n fetch = refs/heads/*:refs/remotes/origin/*\n [branch \"master\"]\n \tremote = origin\n merge = refs/heads/master\n\nThis configuration still causes \"git pull\" or \"git pull origin\"\nwhile on \"master\" to fetch and store the remote side's master as\nwhat you can refer to as 'origin' (because it expands to\n'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),\nand then merges that to your current branch, so there is no\nchange in the user experience in the big picture, but what is\ncreated to achieve that effect is different from what was\ndescribed.\n"},{"id":"30639","messageId":"enc9cn$a4o$1@sea.gmane.org","threadId":"6178","inReplyTo":"7vd55y46ta.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-02T00:38:39Z","receivedAt":"2007-01-02T00:38:39Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> So after a clone, you would get:\n> \n>         [remote \"origin\"]\n>                 url = ....\n>                 fetch = refs/heads/*:refs/remotes/origin/*\n\nBy the way, I have thought that you would also get (to avoid nasty \n\"we don't know which branch is first in glob\")\n\n fetch = refs/heads/master:refs/remotes/origin/master\n\nor\n\n fetch = refs/heads/master:refs/remotes/origin/HEAD\n\n(if master was current branch)\n\n>         [branch \"master\"]\n>                 remote = origin\n>                 merge = refs/heads/master\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30640","messageId":"20070102005708.GA4253@thunk.org","threadId":"6178","inReplyTo":"20070102001044.GB32148@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-02T00:57:08Z","receivedAt":"2007-01-02T00:57:08Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jan 01, 2007 at 07:10:44PM -0500, J. Bruce Fields wrote:\n> \n> The simplest way to understand the current behavior is probably to\n> install the latest git, read the git-clone man page, clone a new\n> repository, and take a look at it.\n\nThis should be mentioned in the 1.5 release notes --- that you won't\nsee a lot of the power the new git unless you create a new repository\nusing git-clone. For example, the man page for git-branch says that\n\"git branch -r\" will list remote branches won't print anything if the\nrepository was originally cloned using an older version of git. \n\n(I was using the version that shipped with Ubuntu Edgy before I\nrecently upgraded to the bleeding edge \"next\" branch so I could try\nout the latest and greatest git features that was being discussed on\nthe mailing list. :-)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"30641","messageId":"20070102010816.GB4253@thunk.org","threadId":"6178","inReplyTo":"926020.70066.qm@web31802.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-02T01:08:16Z","receivedAt":"2007-01-02T01:08:16Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jan 01, 2007 at 03:56:05PM -0800, Luben Tuikov wrote:\n> > Currently, today, if you type:\n> > \n> > \tgit fetch \n> > \n> > ... it will look up \"\" in a single global namespace, which\n> > (using only the new config scheme) is looked up in remote.\n> > and remote..{url,fetch} is used to control the operation of\n> > git-fetch.\n> \n> I'm talking about more in terms of git-merge, but since git-pull\n> is a git-fetch and git-merge, I've been using git-pull for completeness.\n\nWell, yes; since git-pull is implemented in terms of git-fetch\nfollowed by a git-merge, that's why I talked about git-fetch. It is\ngit-fetch which uses remote..{url,fetch}, not git-merge or\ngit-pull (since it just passes those arguments over to git-fetch).\n\n> More specifically,\n> branch...{fetch,merge}.\n\nWhat do you mean by and ?\n\nAre you assuming some kind of glob match? If so, what are the\nspecific rules of the match that you are proposing?\n\n> branch...{fetch,merge} is allowed and defalts\n> to already implemented \"git-pull\".\n\nWhat do you mean by \"..\" here? \n\n> Think of \"git-pull\", not just of \"git-fetch\". As well as think\n> of a setup where there are more than one branch implementing\n> software dependency, resolving to a software product.\n\ngit-pull is implemented in terms of git-fetch. So if we make the\nchange to git-fetch, the changes naturally follow to git-pull. Or are\nyou proposing to change that?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"30642","messageId":"65526.67561.qm@web31806.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070102001044.GB32148@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T01:28:15Z","receivedAt":"2007-01-02T01:28:15Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"J. Bruce Fields\" wrote:\n> On Mon, Jan 01, 2007 at 04:01:15PM -0800, Luben Tuikov wrote:\n> > --- \"J. Bruce Fields\" wrote:\n> > > -The common `Pull: master:origin` mapping of a remote `master`\n> > > -branch to a local `origin` branch, which is then merged to a\n> > > -local development branch, again typically named `master`, is made\n> > > -when you run `git clone` for you to follow this pattern.\n> > \n> > So is this no longer the case?\n> \n> Right; that mapping is no longer what git clone sets up for you.\n> \n> > Can someone please bring me up to date?\n> > \n> > What is going on?\n> \n> The simplest way to understand the current behavior is probably to\n> install the latest git, read the git-clone man page, clone a new\n> repository, and take a look at it.\n> \n> Remote branches are stored in separate namespaces under\n> .git/refs/remotes/, so that they don't muck up your view of your local\n> branches, and so git can enforce different policies for them (such as\n> forbidding committing to them).\n\nSmells like another \"newbie\" protection.\n\nLet me understand, someone here installed git, didn't read the then\nman page of git-clone/pull/fetch, screwed up their repo, and decided\nto change established behavior.\n\nRegardless, I think addressable (named) branch specs are the way to go.\nThis will as well, unify/reconcile remotes/ and local stuff, since\nit is already implemented for remotes/ .\n\n Luben\n"},{"id":"30643","messageId":"405044.6078.qm@web31809.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vd55y46ta.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T02:05:11Z","receivedAt":"2007-01-02T02:05:11Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> What's going on is clean-up towards v1.5.0-rc1 ;-).\n> \n> - 'git clone' does not create a file that has a line that looks\n> like \"Pull: master:origin\" anywhere anymore.\n> \n> - 'git clone' also does not create the traditional \"'master' is\n> special and we map that to origin, others are mapped as is\n> under refs/heads/, and we have to drop 'origin' from the\n> remote side because that name we want to use to store their\n> 'master'\" layout.\n> \n> So after a clone, you would get:\n> \n> \t[remote \"origin\"]\n> \turl = ....\n> fetch = refs/heads/*:refs/remotes/origin/*\n> [branch \"master\"]\n> \tremote = origin\n> merge = refs/heads/master\n> \n> This configuration still causes \"git pull\" or \"git pull origin\"\n> while on \"master\" to fetch and store the remote side's master as\n> what you can refer to as 'origin' (because it expands to\n> 'remotes/origin/HEAD' thanks to sha1_name.c::get_sha1_basic()),\n> and then merges that to your current branch, so there is no\n> change in the user experience in the big picture, but what is\n> created to achieve that effect is different from what was\n> described.\n\nAh, I see. Thanks Junio.\n\n... And this is why I see some objections as to what I'm proposing\nbecause it extends too far the extension itself of the old\nbehavior. (See below.)\n\nQuestions:\n\nWhat is the reasonining of defining branch..merge to point\nto the \"remote's setup\"? I would much, much rather stop the leak\nof the remote's setup right at [remote] and contain it there,\nwhile everything in [branch] would refer to local stuff.\n\nSo the above configuration would become:\n\n \t[remote \"origin\"]\n \turl = ....\n fetch = refs/heads/*:refs/remotes/origin/*\n [branch \"master\"]\n \tremote = origin\n# merge gives the place and name of the remote branch locally mapped\n merge = refs/heads/origin/master\n# OR, better yet\n# merge gives the name only of the remote branch to be merged\n# the local mapping can be found from \"remote = \" above\n merge = master\n\nThe reasoning is that the remote's setup should only leak into\n[remote] and no further. I.e. [remote] is the only one concerned\nwith the mapping between the remote repo and the local repo.\n\nThen, [branch] only talks about local relationships. Now\nsince [branch] does refer to _where_ the local mapping resolves\nto, i.e. the right hand part of `:', then there is a redundancy\nin branch..merge, since branch..remote _does refer_\nto [remote] where we can find where it is locally mapped.\n\nThus, by reducibility, branch.name.merge should only contain\na name. Here is the dependency graph:\n\nbranch.name.merge <- (gives a local name)\n branch.name.remote <- (gives the remote)\n remote.rname.fetch <- (gives the remote:local name mapping)\n remote.rname.url (gives the URL).\n\nNow as to what I'm talking about, should be able to be had with:\n\n [remote \"parent\"]\n url = .\n fetch = :\n [branch \"A\"]\n remote = parent\n merge = master\n [branch \"B\"]\n remote = parent\n merge = A\n [branch \"C\"]\n remote = parent\n merge = B\n\n Luben\n"},{"id":"30644","messageId":"401286.86996.qm@web31803.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070102001044.GB32148@fieldses.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T02:09:48Z","receivedAt":"2007-01-02T02:09:48Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- \"J. Bruce Fields\" wrote:\n> On Mon, Jan 01, 2007 at 04:01:15PM -0800, Luben Tuikov wrote:\n> > --- \"J. Bruce Fields\" wrote:\n> > > -The common `Pull: master:origin` mapping of a remote `master`\n> > > -branch to a local `origin` branch, which is then merged to a\n> > > -local development branch, again typically named `master`, is made\n> > > -when you run `git clone` for you to follow this pattern.\n> > \n> > So is this no longer the case?\n> \n> Right; that mapping is no longer what git clone sets up for you.\n> \n> > Can someone please bring me up to date?\n> > \n> > What is going on?\n> \n> The simplest way to understand the current behavior is probably to\n> install the latest git, read the git-clone man page, clone a new\n> repository, and take a look at it.\n\nI don't like \"learning by observation\" when there is an\nintention -- i.e. I'd rather see a well written justification\nof the intentions and design, as opposed to \"poke at the black\nbox and try to figure it out\".\n\nIt's like learning math by trying to memorize the formulas\nas opposed to knowing how to derive them and why they are\nthe way they are.\n\nI'm expecting a well written man page on the new stuff\n_compared_ to the old stuff, similarly to Junio's response\nto this very same email.\n\n Luben\n\n\n> \n> Remote branches are stored in separate namespaces under\n> .git/refs/remotes/, so that they don't muck up your view of your local\n> branches, and so git can enforce different policies for them (such as\n> forbidding committing to them).\n> \n> --b.\n> \n"},{"id":"30645","messageId":"199618.57093.qm@web31811.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"20070102010816.GB4253@thunk.org","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T02:17:13Z","receivedAt":"2007-01-02T02:17:13Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Theodore Tso wrote:\n> Well, yes; since git-pull is implemented in terms of git-fetch\n> followed by a git-merge, that's why I talked about git-fetch. It is\n> git-fetch which uses remote..{url,fetch}, not git-merge or\n> git-pull (since it just passes those arguments over to git-fetch).\n> \n> > More specifically,\n> > branch...{fetch,merge}.\n> \n> What do you mean by and ?\n> \n> Are you assuming some kind of glob match? If so, what are the\n> specific rules of the match that you are proposing?\n\nYes. I've outlined them at least twice in this thread\nalready as well as in that same email of mine which you're replying\nto, which I'm replying to.\n\n> > branch...{fetch,merge} is allowed and defalts\n> > to already implemented \"git-pull\".\n> \n> What do you mean by \"..\" here? \n\nI mean \"git-pull\", as opposed to \"git-pull \".\n\nI.e. \"branch...{fetch,merge}\" matches no symbolic\nref given, exactly what it defines.\n\n> > Think of \"git-pull\", not just of \"git-fetch\". As well as think\n> > of a setup where there are more than one branch implementing\n> > software dependency, resolving to a software product.\n> \n> git-pull is implemented in terms of git-fetch. So if we make the\n> change to git-fetch, the changes naturally follow to git-pull. Or are\n> you proposing to change that?\n\nNo, not at all.\n\nPlease see my last email to Junio in this thread. Depending on\nhow this new functionlity is implemented for git 1.5, the concept\nof \"branch spec\" can be had by using a \"dummy\" [remote] spec,\nused only as a command line match, and specifying the merge\ndependency in the [branch] spec, refering to \"remote\" and\nidentifying what to merge. See that email please.\n\n Luben\n"},{"id":"30649","messageId":"7vy7omyuaf.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"405044.6078.qm@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T03:36:08Z","receivedAt":"2007-01-02T03:36:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Questions:\n>\n> What is the reasonining of defining branch..merge to point\n> to the \"remote's setup\"?\n\nSee list archives. \n\nBecause you are not required to use remote tracking branches.\nBy the way, I think we allow the name of the remote tracking\nbranch as well, but we do not advertise it -- always using\nremote's name consistently is much less confusing.\n\n> The reasoning is that the remote's setup should only leak into\n> [remote] and no further. I.e. [remote] is the only one concerned\n> with the mapping between the remote repo and the local repo.\n\nNo. Remote is not about mapping -- if mapping is there you can\ntalk about it, but that is optional.\n"},{"id":"30650","messageId":"7vodpiytue.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"926020.70066.qm@web31802.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T03:45:45Z","receivedAt":"2007-01-02T03:45:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> It is in this sense that I do \"cd ; git-pull . \"\n> in a sequence, and I'd rather do \"cd ; git-pull \"\n> to define which branch is the merge coming from given the current branch\n> _and_ the symbolic ref.\n\nIf I am reading you correctly, you have multiple directories,\neach with its own .git/ directory but major parts of these .git/\ndirectories are shared (namely, objects/ and refs/). You would\nnot be able to have separate checkout in these directories if\nyou shared .git/HEAD and .git/index, so at least each of these\ndirectories has these two files for its own.\n\nIs that what you are doing?\n\nIf that is the case, I think you do not even have to have the\n\"branch spec\" to express the patchflow among them. Essentially\nyou are using \"one branch, one directory, one repository\"\nworkflow (my understanding is that this is how BK worked but I\nhaven't seen it) but with your own improvements. The reason\nthis is an improvement is because such a shared .git/refs/\nallows you to do diff and log across branches this way, so if\nyou have a separate .git/config just like you already have\nseparate .git/HEAD and .git/index in these directories, you can\nuse [remote \"xyz\"] sections in each of them to achieve what you\ncalled 'symbolic'.\n"},{"id":"30655","messageId":"7vzm92x7jc.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"65526.67561.qm@web31806.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T06:32:55Z","receivedAt":"2007-01-02T06:32:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- \"J. Bruce Fields\" wrote:\n> ...\n>> Remote branches are stored in separate namespaces under\n>> .git/refs/remotes/, so that they don't muck up your view of your local\n>> branches, and so git can enforce different policies for them (such as\n>> forbidding committing to them).\n>\n> Smells like another \"newbie\" protection.\n>\n> Let me understand, someone here installed git, didn't read the then\n> man page of git-clone/pull/fetch, screwed up their repo, and decided\n> to change established behavior.\n\nYou smelled and understood wrongly in this case. Another point\nin separate-remote layout is that it makes it easier to interact\nwith more than one remotes, and we do not have to treat 'master'\nand 'origin' as branch names any more specially than necessary.\n"},{"id":"30667","messageId":"endfl1$iq0$1@sea.gmane.org","threadId":"6178","inReplyTo":"7vy7omyuaf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-02T11:31:38Z","receivedAt":"2007-01-02T11:31:38Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Luben Tuikov writes:\n> \n>> Questions:\n>>\n>> What is the reasonining of defining branch..merge to point\n>> to the \"remote's setup\"?\n> \n> See list archives. \n> \n> Because you are not required to use remote tracking branches.\n> By the way, I think we allow the name of the remote tracking\n> branch as well, but we do not advertise it -- always using\n> remote's name consistently is much less confusing.\n\nIf remember correctly there were added some magic which makes\ngit search on pull first remote branches (to allow to pull\nwithout tracking branches), then tracking branches. This I think\nsupercedes alternate proposal of using branch..mergeLocal.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30677","messageId":"666730.12167.qm@web31802.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vodpiytue.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T18:39:05Z","receivedAt":"2007-01-02T18:39:05Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > It is in this sense that I do \"cd ; git-pull . \"\n> > in a sequence, and I'd rather do \"cd ; git-pull \"\n> > to define which branch is the merge coming from given the current branch\n> > _and_ the symbolic ref.\n> \n> If I am reading you correctly, you have multiple directories,\n> each with its own .git/ directory but major parts of these .git/\n> directories are shared (namely, objects/ and refs/). You would\n> not be able to have separate checkout in these directories if\n> you shared .git/HEAD and .git/index, so at least each of these\n> directories has these two files for its own.\n> \n> Is that what you are doing?\n\nYes, but the _ONLY_ thing which is NOT shared is .git/HEAD and\n.git/index. EVERYTHING else is the _same_ in all branch-per-directory.\n\n> If that is the case, I think you do not even have to have the\n> \"branch spec\" to express the patchflow among them. Essentially\n> you are using \"one branch, one directory, one repository\"\n> workflow (my understanding is that this is how BK worked but I\n> haven't seen it) but with your own improvements. The reason\n> this is an improvement is because such a shared .git/refs/\n> allows you to do diff and log across branches this way, so if\n> you have a separate .git/config just like you already have\n> separate .git/HEAD and .git/index in these directories, you can\n> use [remote \"xyz\"] sections in each of them to achieve what you\n> called 'symbolic'.\n\nYeah, but I do not want to introduce yet another non-shared\nfile -- namely the config.\n\nI want the config to be shared as well, since the repo is\nexactly the same. Firthermore, the branches are branches of\nthe same repo, not of different one. config should be one\nand the same -- per repo.\n\n Luben\n"},{"id":"30678","messageId":"560316.34562.qm@web31812.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vy7omyuaf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-02T18:48:50Z","receivedAt":"2007-01-02T18:48:50Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > Questions:\n> >\n> > What is the reasonining of defining branch..merge to point\n> > to the \"remote's setup\"?\n> \n> See list archives. \n> \n> Because you are not required to use remote tracking branches.\n\nThen why does it point to the _remote_ mapping? One shouldn't\ncare what it is, and how it looks in the remote repo. That is\nhandled by [remote]. In [branch] I shouldn't have to have any\nabsolute references, i.e. branch..remote points to [remote],\nand branch..merge should only give a _branch_ name,\nwhose remote-to-local mapping (which preserves the branch name)\ncan be found by dereferencing branch..remote to get to\nremote..fetch.\n\nThink of it as DB schema normalization.\n\n Luben\n\n\n> By the way, I think we allow the name of the remote tracking\n> branch as well, but we do not advertise it -- always using\n> remote's name consistently is much less confusing.\n> \n> > The reasoning is that the remote's setup should only leak into\n> > [remote] and no further. I.e. [remote] is the only one concerned\n> > with the mapping between the remote repo and the local repo.\n> \n> No. Remote is not about mapping -- if mapping is there you can\n> talk about it, but that is optional.\n> \n> \n"},{"id":"30682","messageId":"eneb7b$ll7$1@sea.gmane.org","threadId":"6178","inReplyTo":"560316.34562.qm@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-02T19:22:14Z","receivedAt":"2007-01-02T19:22:14Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Luben Tuikov wrote:\n\n> --- Junio C Hamano wrote:\n>> Luben Tuikov writes:\n>> \n>>> Questions:\n>>>\n>>> What is the reasonining of defining branch..merge to point\n>>> to the \"remote's setup\"?\n>> \n>> See list archives. \n>> \n>> Because you are not required to use remote tracking branches.\n> \n> Then why does it point to the _remote_ mapping? One shouldn't\n> care what it is, and how it looks in the remote repo. That is\n> handled by [remote]. In [branch] I shouldn't have to have any\n> absolute references, i.e. branch..remote points to [remote],\n> and branch..merge should only give a _branch_ name,\n> whose remote-to-local mapping (which preserves the branch name)\n> can be found by dereferencing branch..remote to get to\n> remote..fetch.\n\nOnce again: if you _don't_ have _local_ tracking branch, so you _must_\nuse _remote_ name.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30688","messageId":"7vtzz9usyp.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"560316.34562.qm@web31812.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-02T19:30:38Z","receivedAt":"2007-01-02T19:30:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- Junio C Hamano wrote:\n>> Luben Tuikov writes:\n>> \n>> > Questions:\n>> >\n>> > What is the reasonining of defining branch..merge to point\n>> > to the \"remote's setup\"?\n>> \n>> See list archives. \n>> \n>> Because you are not required to use remote tracking branches.\n>\n> Then why does it point to the _remote_ mapping? One shouldn't\n\nBecause [remote] is NOT about mapping. It asks the fetch\nmechanism to fetch from that remote, so the primary thing you\nshould look at is .url, not RHS of colon on .fetch lines. Use\nof tracking branches is strictly optional.\n"},{"id":"30925","messageId":"826.67287.qm@web31809.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vtzz9usyp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-05T23:15:18Z","receivedAt":"2007-01-05T23:15:18Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> \n> Because [remote] is NOT about mapping. It asks the fetch\n> mechanism to fetch from that remote, so the primary thing you\n> should look at is .url, not RHS of colon on .fetch lines. Use\n> of tracking branches is strictly optional.\n\nRemote\n------\n\nPlease help me understand. Here is a sample remote from\nan actual repo (actual names changed):\n\n[remote \"origin\"]\n url = http://blah/bleah.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n\nThis basically says: \"Get it\" from such and such url, where\non the repo at that url, i.e. the remote side, you will\nfind stuff in \"refs/heads/\", and when you get it here, locally,\nput it in refs/remotes/origin/.\n\nNow if this isn't a mapping, then please can someone\nexplain to me what a \"mapping\" is?\n\nThe \"fetch = :\" is inherently a mapping,\nits syntax dictates it, as does the actual actions\nit performs: \"fetch\" from \"remote\" and \"put in local \".\n\nBranch\n------\n\nHere is an actual example:\n\n[branch \"branchA\"]\n remote = origin\n merge = refs/heads/branchA\n\nYeah, but by default \"refs/heads/branchA\" doesn't exist (see\nmy previous email). It doesn't have to, since it specifies\nthe \"remote part\", but that has already been handled by\n\"[remote]\".\n\nUnless of course \"[branch \"...\"]\" specifies the _remote_ branch\nbeing tracked in refs/remotes/origin. Is this the case.\n\nDoes \"[branch]\" apply to local branches too? If so,\nthen what happens when refs/heads/branchA does exist and is\nthe same as the one it describes -- i.e. completely old behavior.\n\nThanks,\n Luben\n"},{"id":"30929","messageId":"7vvejlcb6z.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"826.67287.qm@web31809.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T23:20:52Z","receivedAt":"2007-01-05T23:20:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> --- Junio C Hamano wrote:\n>> \n>> Because [remote] is NOT about mapping. It asks the fetch\n>> mechanism to fetch from that remote, so the primary thing you\n>> should look at is .url, not RHS of colon on .fetch lines. Use\n>> of tracking branches is strictly optional.\n>\n> Remote\n> ------\n>\n> Please help me understand. Here is a sample remote from\n> an actual repo (actual names changed):\n>\n> [remote \"origin\"]\n> url = http://blah/bleah.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n>\n> This basically says: \"Get it\" from such and such url, where\n> on the repo at that url, i.e. the remote side, you will\n> find stuff in \"refs/heads/\", and when you get it here, locally,\n> put it in refs/remotes/origin/.\n\n [remote \"origin\"]\n url = http://blah/blah.git\n fetch = refs/heads/master\n\nis also fine. The point is that you do not have to use tracking\nbranches. \", and when you get it here, ...\" part is optional.\n\n> Branch\n> ------\n>\n> Here is an actual example:\n>\n> [branch \"branchA\"]\n> remote = origin\n> merge = refs/heads/branchA\n>\n> Yeah, but by default \"refs/heads/branchA\" doesn't exist (see\n> my previous email). It doesn't have to, since it specifies\n> the \"remote part\", but that has already been handled by\n> \"[remote]\".\n\nObviously fetch needs to handle the remote part because that is\nthe only name it exists at the remote. branch.*.merge is used\nby pull, not fetch, and fetch communicates with pull by using\nthe remote name, because use of local tracking branches is\noptional.\n"},{"id":"30930","messageId":"7vr6u9cann.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"7vvejlcb6z.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T23:32:28Z","receivedAt":"2007-01-05T23:32:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Luben Tuikov writes:\n>\n>> --- Junio C Hamano wrote:\n>>> \n>>> Because [remote] is NOT about mapping. It asks the fetch\n>>> mechanism to fetch from that remote, so the primary thing you\n>>> should look at is .url, not RHS of colon on .fetch lines. Use\n>>> of tracking branches is strictly optional.\n>>\n>> [remote \"origin\"]\n>> url = http://blah/bleah.git\n>> fetch = +refs/heads/*:refs/remotes/origin/*\n>>\n>> This basically says: \"Get it\" from such and such url, where\n>> on the repo at that url, i.e. the remote side, you will\n>> find stuff in \"refs/heads/\", and when you get it here, locally,\n>> put it in refs/remotes/origin/.\n>\n> [remote \"origin\"]\n> url = http://blah/blah.git\n> fetch = refs/heads/master\n>\n> is also fine. The point is that you do not have to use tracking\n> branches. \", and when you get it here, ...\" part is optional.\n\nIn other words, remote.*.fetch could be spelled as mapping to\ncause them locally stored in tracking branches, but the storing\nin tracking branches is merely a side effect of a fetch, not the\nprimary one. The primary effect is to fetch the necessary\nobjects and leave what was fetched in .git/FETCH_HEAD to\ncommunicate with later 'git pull'. The side effect is optional,\nso is spelling remote.*.fetch as a mapping.\n\n>> Yeah, but by default \"refs/heads/branchA\" doesn't exist (see\n>> my previous email). It doesn't have to, since it specifies\n>> the \"remote part\", but that has already been handled by\n>> \"[remote]\".\n>\n> Obviously fetch needs to handle the remote part because that is\n> the only name it exists at the remote. branch.*.merge is used\n> by pull, not fetch, and fetch communicates with pull by using\n> the remote name, because use of local tracking branches is\n> optional.\n\nIn other words, the remote name is the only thing that can be\nused between fetch and pull to communicate. Fetch tells pull \"I\nfetched these from the remote\", and pull uses that information\nto make a merge, and the merge comment says \"this merges the\nbranch xyz from that repository\", using the 'xyz' name used at\nthe remote side, not your local tracking branch, which you may\nor may not be using.\n"},{"id":"30940","messageId":"594263.16987.qm@web31811.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vvejlcb6z.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-06T00:22:35Z","receivedAt":"2007-01-06T00:22:35Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> > --- Junio C Hamano wrote:\n> >> \n> >> Because [remote] is NOT about mapping. It asks the fetch\n> >> mechanism to fetch from that remote, so the primary thing you\n> >> should look at is .url, not RHS of colon on .fetch lines. Use\n> >> of tracking branches is strictly optional.\n> >\n> > Remote\n> > ------\n> >\n> > Please help me understand. Here is a sample remote from\n> > an actual repo (actual names changed):\n> >\n> > [remote \"origin\"]\n> > url = http://blah/bleah.git\n> > fetch = +refs/heads/*:refs/remotes/origin/*\n> >\n> > This basically says: \"Get it\" from such and such url, where\n> > on the repo at that url, i.e. the remote side, you will\n> > find stuff in \"refs/heads/\", and when you get it here, locally,\n> > put it in refs/remotes/origin/.\n> \n> [remote \"origin\"]\n> url = http://blah/blah.git\n> fetch = refs/heads/master\n> \n> is also fine. The point is that you do not have to use tracking\n> branches. \", and when you get it here, ...\" part is optional.\n\nOk. So then in this case \"fetch = refs/heads/master\" describes\n.git/refs/heads/master or something else?\n\nIf it does, then this is a local map.\n\nI guess this is the case where one wants to automate\n\"git-pull . OtherBranch\", but shouldn't this be handled\nby [branch], i.e. the \"merge\" part of [branch].\n\n> > Branch\n> > ------\n> >\n> > Here is an actual example:\n> >\n> > [branch \"branchA\"]\n> > remote = origin\n> > merge = refs/heads/branchA\n> >\n> > Yeah, but by default \"refs/heads/branchA\" doesn't exist (see\n> > my previous email). It doesn't have to, since it specifies\n> > the \"remote part\", but that has already been handled by\n> > \"[remote]\".\n> \n> Obviously fetch needs to handle the remote part because that is\n> the only name it exists at the remote. branch.*.merge is used\n> by pull, not fetch, and fetch communicates with pull by using\n> the remote name, because use of local tracking branches is\n> optional.\n\nDoes this mean that \"fetch = :\" is legal? Shouldn't the\nRHS always exist? Is the RHS of \"fetch = :\" what you mean\nby local tracking branches?\n\n Luben\n"},{"id":"30942","messageId":"234200.4582.qm@web31806.mail.mud.yahoo.com","threadId":"6178","inReplyTo":"7vr6u9cann.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2007-01-06T00:32:30Z","receivedAt":"2007-01-06T00:32:30Z","isPatch":true,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Luben Tuikov writes:\n> >\n> >> --- Junio C Hamano wrote:\n> >>> \n> >>> Because [remote] is NOT about mapping. It asks the fetch\n> >>> mechanism to fetch from that remote, so the primary thing you\n> >>> should look at is .url, not RHS of colon on .fetch lines. Use\n> >>> of tracking branches is strictly optional.\n> >>\n> >> [remote \"origin\"]\n> >> url = http://blah/bleah.git\n> >> fetch = +refs/heads/*:refs/remotes/origin/*\n> >>\n> >> This basically says: \"Get it\" from such and such url, where\n> >> on the repo at that url, i.e. the remote side, you will\n> >> find stuff in \"refs/heads/\", and when you get it here, locally,\n> >> put it in refs/remotes/origin/.\n> >\n> > [remote \"origin\"]\n> > url = http://blah/blah.git\n> > fetch = refs/heads/master\n> >\n> > is also fine. The point is that you do not have to use tracking\n> > branches. \", and when you get it here, ...\" part is optional.\n> \n> In other words, remote.*.fetch could be spelled as mapping to\n> cause them locally stored in tracking branches, but the storing\n> in tracking branches is merely a side effect of a fetch, not the\n> primary one. The primary effect is to fetch the necessary\n> objects and leave what was fetched in .git/FETCH_HEAD to\n> communicate with later 'git pull'. The side effect is optional,\n> so is spelling remote.*.fetch as a mapping.\n\nOh ok -- I forgot about .git/FETCH_HEAD.\n\n> >> Yeah, but by default \"refs/heads/branchA\" doesn't exist (see\n> >> my previous email). It doesn't have to, since it specifies\n> >> the \"remote part\", but that has already been handled by\n> >> \"[remote]\".\n> >\n> > Obviously fetch needs to handle the remote part because that is\n> > the only name it exists at the remote. branch.*.merge is used\n> > by pull, not fetch, and fetch communicates with pull by using\n> > the remote name, because use of local tracking branches is\n> > optional.\n> \n> In other words, the remote name is the only thing that can be\n> used between fetch and pull to communicate. Fetch tells pull \"I\n> fetched these from the remote\", and pull uses that information\n> to make a merge, and the merge comment says \"this merges the\n> branch xyz from that repository\", using the 'xyz' name used at\n> the remote side, not your local tracking branch, which you may\n> or may not be using.\n\nOk.\n\n Luben\n"},{"id":"30945","messageId":"7v4pr5ar82.fsf@assigned-by-dhcp.cox.net","threadId":"6178","inReplyTo":"594263.16987.qm@web31811.mail.mud.yahoo.com","subject":"Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-06T01:17:33Z","receivedAt":"2007-01-06T01:17:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n>> [remote \"origin\"]\n>> url = http://blah/blah.git\n>> fetch = refs/heads/master\n>> \n>> is also fine. The point is that you do not have to use tracking\n>> branches. \", and when you get it here, ...\" part is optional.\n>\n> Ok. So then in this case \"fetch = refs/heads/master\" describes\n> .git/refs/heads/master or something else?\n\nIt names http://blah/blah.git/refs/heads/master (unless blah.git\nrepository uses packed refs then has pruned the loose refs).\n\n> If it does, then this is a local map.\n\nNo, it is just a list of remote refs (one element list because\nthere is only one \"fetch =\" line).\n\n> Does this mean that \"fetch = :\" is legal? Shouldn't the\n> RHS always exist?\n\nDocumentation/pull-fetch-param.txt\n"}]}