{"thread":{"id":"13265","subject":"[PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","startedAt":"2008-04-26T07:31:28Z","lastAt":"2008-05-14T19:40:44Z","messageCount":74,"participants":["Paolo Bonzini","Shawn O. Pearce","Junio C Hamano","Jeff King","Stephen R. van den Berg","Johannes Schindelin","Alex Riesen","Andreas Ericsson","しらいしななこ"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"75210","messageId":"4812DA50.3000702@gnu.org","threadId":"13265","inReplyTo":null,"subject":"[PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-26T07:31:28Z","receivedAt":"2008-04-26T07:31:28Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch builds on the infrastructure for remote..mirror and\ntweaks the behavior of \"git push\". The idea is that \"git push\",\n\"git push --all\", \"git push --mirror\", instead of defaulting to origin,\nbecome DWIM commands:\n\n- \"git push\" pushes to origin *and* to all mirrors\n\n- \"git push --all\" pushes to origin with --all. I didn't make it push\n to mirrors because --all and --mirror are incompatible.\n\n- \"git push --mirror\" only updates mirror repositories, without touching\n origin.\n\nThis is useful when a project has a public repository managed by the\nintegrator, but the integrator also wants to publish his own mirror\nsomewhere. In this case, the integrator will just do \"git push\".\nSimilarly, if a developer uses the integrator's repository but\nwishes to publish his own mirror somewhere, he can just do \"git push\n--mirror\".\n\nThe code explicitly disables pushing to mirrors when a refspec is present.\nThis is just defensive, because right now refspecs cannot be specified\nwithout giving a repository too.\n\nSigned-off-by: Paolo Bonzini \n---\n Documentation/git-push.txt | 17 ++++++---\n builtin-push.c | 43 ++++++++++++++++------\n t/t5517-push-mirror.sh | 86 ++++++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 130 insertions(+), 16 deletions(-)\n\n\tSent a week ago, no comments received.\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex dc1d4b0..8195517 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -29,6 +29,11 @@ OPTIONS\n \tThe \"remote\" repository that is destination of a push\n \toperation. See the section <> below.\n\n+\tThe default behavior of the command when no repository is specified\n+\tis to push to \"origin\" if \\--all is given, to push to all mirror\n+\tremotes if \\--mirror is given, and to do both actions if neither\n+\t\\--all nor \\--mirror is given.\n+\n ::\n \tThe canonical format of a parameter is\n \t`+?:`; that is, an optional plus `+`, followed\n@@ -69,9 +74,11 @@ the remote repository.\n \tbe mirrored to the remote repository. Newly created local\n \trefs will be pushed to the remote end, locally updated refs\n \twill be force updated on the remote end, and deleted refs\n-\twill be removed from the remote end. This is the default\n-\tif the configuration option `remote..mirror` is\n-\tset.\n+\twill be removed from the remote end.\n+\n+\tWhen a is given on the command line, git looks up the\n+\tcorresponding configuration option `remote..mirror`\n+\tand enables mirror mode if it is set.\n\n \\--dry-run::\n \tDo everything except actually send the updates.\n@@ -97,8 +104,8 @@ the remote repository.\n \tremote repository to lose commits; use it with care.\n\n \\--repo=::\n-\tWhen no repository is specified the command defaults to\n-\t\"origin\"; this overrides it.\n+\tOverrides the default behavior of the command when no repository\n+\tis specified, so that is used as the destination repository.\n\n \\--thin, \\--no-thin::\n \tThese options are passed to `git-send-pack`. Thin\ndiff --git a/builtin-push.c b/builtin-push.c\nindex e992c37..3756d5e 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -48,14 +48,9 @@ static void set_refspecs(const char **refs, int nr)\n \t}\n }\n\n-static int do_push(const char *repo, int flags)\n+static int do_push(struct remote *remote, int flags)\n {\n \tint i, errs;\n-\tstruct remote *remote = remote_get(repo);\n-\n-\tif (!remote)\n-\t\tdie(\"bad repository '%s'\", repo);\n-\n \tif (remote->mirror)\n \t\tflags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);\n\n@@ -99,6 +94,18 @@ static int do_push(const char *repo, int flags)\n \treturn !!errs;\n }\n\n+static int push_to_mirrors(struct remote *remote, void *priv)\n+{\n+\tint *p_flags = priv;\n+\tint rc = 0;\n+\tif (remote->mirror)\n+\t\trc = do_push (remote, *p_flags);\n+\t\n+\t/* No command-line errors should occur. */\n+\tassert (rc != -1);\n+\treturn rc;\n+}\n+\n int cmd_push(int argc, const char **argv, const char *prefix)\n {\n \tint flags = 0;\n@@ -109,6 +116,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \tint tags = 0;\n \tint rc;\n \tconst char *repo = NULL;\t/* default repository */\n+\tstruct remote *remote;\n\n \tstruct option options[] = {\n \t\tOPT__VERBOSE(&verbose),\n@@ -144,9 +152,22 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tset_refspecs(argv + 1, argc - 1);\n \t}\n\n-\trc = do_push(repo, flags);\n-\tif (rc == -1)\n-\t\tusage_with_options(push_usage, options);\n-\telse\n-\t\treturn rc;\n+\t/* \"git push --mirror\" will only push to mirrors. */\n+\tif (repo || !mirror) {\n+\t\tremote = remote_get(repo);\n+\t\tif (!remote)\n+\t\t\tdie(\"bad repository '%s'\", repo);\n+\t\n+\t\trc = do_push(remote, flags);\n+\t\tif (rc == -1)\n+\t\t\tusage_with_options(push_usage, options);\n+\t}\n+\n+\t/* \"git push\" with only --force, --dry-run, --verbose, --mirror options\n+\t will also (or, in the case of \"git push --mirror\", only) push to\n+\t all mirrors. */\n+\tif (!rc && !repo && !refspec && !all)\n+\t\trc = for_each_remote (push_to_mirrors, &flags);\n+\t\n+\treturn rc;\n }\ndiff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh\nindex ea49ded..beb71f4 100755\n--- a/t/t5517-push-mirror.sh\n+++ b/t/t5517-push-mirror.sh\n@@ -29,6 +29,26 @@ mk_repo_pair () {\n \t)\n }\n\n+# a more complicated setup where we have also an origin repo\n+mk_repo_threesome () {\n+\trm -rf master mirror origin &&\n+\tmkdir mirror &&\n+\t(\n+\t\tcd mirror &&\n+\t\tgit init\n+\t) &&\n+\tmkdir origin &&\n+\t(\n+\t\tcd origin &&\n+\t\tgit init\n+\t\techo one >foo && git add foo && git commit -m one\n+\t) &&\n+\tgit clone origin master &&\n+\t(\n+\t\tcd master &&\n+\t\tgit remote add --mirror up ../mirror\n+\t)\n+}\n\n # BRANCH tests\n test_expect_success 'push mirror creates new branches' '\n@@ -264,4 +284,70 @@ test_expect_success 'remote.foo.mirror=no has no effect' '\n\n '\n\n+test_expect_success 'mirrors are updated by \"git push\"' '\n+\n+\tmk_repo_threesome &&\n+\t(\n+\t\tcd master &&\n+\t\tgit branch keep master &&\n+\t\tgit branch remove master &&\n+\t\tgit push &&\n+\t\tgit branch -D remove\n+\t\tgit push\n+\t) &&\n+\t(\n+\t\tcd mirror &&\n+\t\tgit show-ref -s --verify refs/heads/keep &&\n+\t\tinvert git show-ref -s --verify refs/heads/remove\n+\t) &&\n+\t(\n+\t\tcd origin &&\n+\t\tinvert git show-ref -s --verify refs/heads/keep &&\n+\t\tinvert git show-ref -s --verify refs/heads/remove\n+\t)\n+\n+'\n+\n+test_expect_success 'mirrors are not updated by \"git push --all\"' '\n+\n+\tmk_repo_threesome &&\n+\t(\n+\t\tcd master &&\n+\t\tgit branch b1 master &&\n+\t\tgit push --all\n+\t) &&\n+\t(\n+\t\tcd mirror &&\n+\t\tinvert git show-ref -s --verify refs/heads/b1\n+\t) &&\n+\t(\n+\t\tcd origin &&\n+\t\tgit show-ref -s --verify refs/heads/b1\n+\t)\n+\n+'\n+\n+test_expect_success 'mirrors are not updated by \"git push --repo\" or \"git push \"' '\n+\n+\tmk_repo_threesome &&\n+\t(\n+\t\tcd master &&\n+\t\tgit branch b1 master &&\n+\t\tgit push origin\n+\t\tgit branch b2 master &&\n+\t\tgit push --repo=origin\n+\t) &&\n+\t(\n+\t\tcd mirror &&\n+\t\tinvert git show-ref -s --verify refs/heads/b1 &&\n+\t\tinvert git show-ref -s --verify refs/heads/b2\n+\t) &&\n+\t(\n+\t\tcd origin &&\n+\t\tinvert git show-ref -s --verify refs/heads/b1 &&\n+\t\tinvert git show-ref -s --verify refs/heads/b2\n+\t)\n+\n+'\n+\n test_done\n-- \n1.5.5\n"},{"id":"75226","messageId":"20080426170126.GC29771@spearce.org","threadId":"13265","inReplyTo":"4812DA50.3000702@gnu.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-26T17:01:26Z","receivedAt":"2008-04-26T17:01:26Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Paolo Bonzini wrote:\n> This patch builds on the infrastructure for remote..mirror and\n> tweaks the behavior of \"git push\". The idea is that \"git push\",\n> \"git push --all\", \"git push --mirror\", instead of defaulting to origin,\n> become DWIM commands:\n> \n> - \"git push\" pushes to origin *and* to all mirrors\n> \n> - \"git push --all\" pushes to origin with --all. I didn't make it push\n> to mirrors because --all and --mirror are incompatible.\n> \n> - \"git push --mirror\" only updates mirror repositories, without touching\n> origin.\n> \n> This is useful when a project has a public repository managed by the\n> integrator, but the integrator also wants to publish his own mirror\n> somewhere. In this case, the integrator will just do \"git push\".\n\nSorry, I don't really see a use case behind this. `git push` today\nwill push to origin all branches that exist both locally and already\non the remote. If you want to push to multiple locations, just\nspecify the other URLs in the remote.origin.url configuration list.\nLinus added support for that years ago.\n\n> Similarly, if a developer uses the integrator's repository but\n> wishes to publish his own mirror somewhere, he can just do \"git push\n> --mirror\".\n\nWhy not just have a remote named \"my-mirror\" and do `git push my-mirror`?\nYes, its on keystroke longer to type. Call it foo. `git push foo` would\nbe shorter, and not require code changes in Git.\n\n-- \nShawn.\n"},{"id":"75228","messageId":"7vzlrgmrvb.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"20080426170126.GC29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-26T17:46:16Z","receivedAt":"2008-04-26T17:46:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Why not just have a remote named \"my-mirror\" and do `git push my-mirror`?\n> Yes, its on keystroke longer to type. Call it foo. `git push foo` would\n> be shorter, and not require code changes in Git.\n\nConfiguring to push to multiple can already be done as you described, not\nhaving to have a special case code like this patch is certainly very\nattractive, and also it is one less \"magic\" applied to the configuration\n(meaning, when you have to figure out what an unadorned \"git push\" does\nfor somebody else who is having trouble, you have one less thing to\nconsider).\n\nI've been torn between\n\n (1) but then you have to have an extra 'foo' remote and with this patch\n it becomes unnecessary, and\n\n (2) no, by separating individual remotes (which are not 'foo') and a\n magic \"pushing to everywhere\" (which is 'foo'), that extra 'foo'\n simplifies things, to explain, understand, and diagnose (when\n something goes south).\n\nI am leaning towards the latter argument now, especially after you\ncommented on this issue.\n"},{"id":"75251","messageId":"20080427043014.GI29771@spearce.org","threadId":"13265","inReplyTo":"7vzlrgmrvb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-27T04:30:14Z","receivedAt":"2008-04-27T04:30:14Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Why not just have a remote named \"my-mirror\" and do `git push my-mirror`?\n> > Yes, its on keystroke longer to type. Call it foo. `git push foo` would\n> > be shorter, and not require code changes in Git.\n...\n> (2) no, by separating individual remotes (which are not 'foo') and a\n> magic \"pushing to everywhere\" (which is 'foo'), that extra 'foo'\n> simplifies things, to explain, understand, and diagnose (when\n> something goes south).\n\nThis is the only behavior that really makes sense to me.\n\nWhen I first started to learn and use a DVCS I'll admit that I did\nfound it odd that \"$dvcs commit\" did not make my changes immediately\navailable to everyone else on the project. I've gotten over that\nand have become very used to the idea that \"git push foo\" is the\nmeans that I publish my work to location(s) named \"foo\", using the\npublication means I have pre-configured for that name.\n\nNot all of my work from the same repository is always published\nthe same way. For example in egit I can publish to both\nthe master egit tree (repo.or.cz/egit.git) and to my fork\n(repo.or.cz/egit/spearce.git). I publish to the latter almost\ndaily, and rebase even more often than that. But the master tree\nonly receives stable work whose history does not rewind.\n\nIn git being able to configure two different remotes and specifically\npushing to the destination is very easy. What is less easy is our\nreliance on a default named \"origin\" and the syntax we have for\nthe remote configuration. It is fairly simple, but new users do\nseem to struggle with it a bit.\n\n-- \nShawn.\n"},{"id":"75252","messageId":"20080427044049.GJ29771@spearce.org","threadId":"13265","inReplyTo":"20080427043014.GI29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-27T04:40:49Z","receivedAt":"2008-04-27T04:40:49Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> \n> In git being able to configure two different remotes and specifically\n> pushing to the destination is very easy. What is less easy is our\n> reliance on a default named \"origin\" and the syntax we have for\n> the remote configuration. It is fairly simple, but new users do\n> seem to struggle with it a bit.\n\nPerhaps I should clarify this statement a bit.\n\nI _hate_ the default remote. One of the first things I wind up\ndoing is deleting it and creating a new one. At least git-clone has\nthe -o flag to setup your own name, which then the tools (git-fetch\nand git-push) cannot find.\n\nAnytime I use git-fetch, git-pull or git-push I am always giving\nit a remote name, or a remote name and a refspec. So having these\ntools default to 'origin' is of little to no value to me.\n\n-- \nShawn.\n"},{"id":"75255","messageId":"7vabjflvlh.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"20080427044049.GJ29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-27T05:23:22Z","receivedAt":"2008-04-27T05:23:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I _hate_ the default remote. One of the first things I wind up\n> doing is deleting it and creating a new one. At least git-clone has\n> the -o flag to setup your own name, which then the tools (git-fetch\n> and git-push) cannot find.\n>\n> Anytime I use git-fetch, git-pull or git-push I am always giving\n> it a remote name, or a remote name and a refspec. So having these\n> tools default to 'origin' is of little to no value to me.\n\nIt sounds as if you want to say it a bit stronger than that --- to you,\ndefaulting to 'origin' is not of \"little to no\" but \"negative\" value, is\nit?\n\nBut I think we are minotiry. To people with \"CVS migrant\" workflow,\ncloning from _the_ central repo, hacking, and then pushing back will never\ninvolve anything other than 'origin' and local repositories, and I am\nsympathetic when they want to say \"git push\" and have it default to that\nsingle other repository.\n\nIf you have more than one places to push, like we do, we have these\nmultiple repositories exactly because we would want to push to these\nrepositories for different reasons, and being able to name to which one we\nwould want to push in each invocation of push is a power. But not all\npeople need to use that power. If somebody pushes only to one place,\nwhich may be very typical, that's fine, and in such a typical \"single\nremote\" configuration, they will be pushing back to where they cloned\nfrom.\n"},{"id":"75272","messageId":"481429EB.70809@gnu.org","threadId":"13265","inReplyTo":"20080426170126.GC29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-27T07:23:23Z","receivedAt":"2008-04-27T07:23:23Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Sorry, I don't really see a use case behind this. `git push` today\n> will push to origin all branches that exist both locally and already\n> on the remote. If you want to push to multiple locations, just\n> specify the other URLs in the remote.origin.url configuration list.\n> Linus added support for that years ago.\n\nI publish my topic branches (with --mirror) on my personal site, and the \nmaster and stable branches on savannah.gnu.org.\n\n>> Similarly, if a developer uses the integrator's repository but\n>> wishes to publish his own mirror somewhere, he can just do \"git push\n>> --mirror\".\n> \n> Why not just have a remote named \"my-mirror\" and do `git push my-mirror`?\n\nMore precisely, it would be \"git push && git push --mirror mirror\". My \nprevious patch to add remote..mirror shortens it to eliminate the \n--mirror, but I cannot condense it in one remote because one is mirror \nand the other isn't.\n\nI can do this, in other words:\n\n> For example in egit I can publish to both\n> the master egit tree (repo.or.cz/egit.git) and to my fork\n> (repo.or.cz/egit/spearce.git). I publish to the latter almost\n> daily, and rebase even more often than that.\n\n... just by choosing whether to work in a topic branch or in a repo that \nis already on git.sv.gnu.org, but from a single checked out tree. Like \nyou guys, I have multiple places to push to -- and I want \"git push\" to \nDWIM.\n\nOf course I have a git-mirror script that does it, but the use case \nseemed frequent enough to warrant the effort to provide it for other \nusers too.\n\nReplying to Junio:\n\n> Configuring to push to multiple can already be done as you described, not\n> having to have a special case code like this patch is certainly very\n> attractive\n\nI considered actually to change it to \"push to every remote that has a \npush refspec\", and adding code to \"git clone\" that added a push refspec \nfor origin. This would simplify the magic, but I wasn't sure of the \nramifications and of whether it would change the behavior of the default \nremote.\n\nPaolo\n"},{"id":"75279","messageId":"48144150.8040001@gnu.org","threadId":"13265","inReplyTo":"20080427044049.GJ29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-27T09:03:12Z","receivedAt":"2008-04-27T09:03:12Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Patch withdrawn, I'll send a different series.\n\nPaolo\n"},{"id":"75311","messageId":"20080427173446.GM29771@spearce.org","threadId":"13265","inReplyTo":"7vabjflvlh.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-27T17:34:46Z","receivedAt":"2008-04-27T17:34:46Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > I _hate_ the default remote. [...]\n> \n> It sounds as if you want to say it a bit stronger than that --- to you,\n> defaulting to 'origin' is not of \"little to no\" but \"negative\" value, is\n> it?\n> \n> But I think we are minotiry. To people with \"CVS migrant\" workflow,\n> cloning from _the_ central repo, hacking, and then pushing back will never\n> involve anything other than 'origin' and local repositories, and I am\n> sympathetic when they want to say \"git push\" and have it default to that\n> single other repository.\n\nYes, I think we are in the minority. Many people come to Git from\na centralized system so the idea of just a single place to pull/push\nfrom makes perfect sense to them.\n\nBut then they later wonder why they need `git pull origin branch`\nto merge in branch, when they usually just say `git pull`. What is\nthe need for that funny keyword `origin`? Why do I have to say\nwhere to get the branch from sometimes and not others?\n\nI think this argument is like the one we had with `git pull . branch`\nvs. `git merge branch`. However we probably could have gotten users\nto accept `git merge . branch`, as the main argument there was the\nfact that git-merge (the natural command to invoke) didn't actually do\nwhat the user wanted, and git-pull did.\n\nJust take the above as the rantings of someone who knows git a\nlittle too well, and has tried to teach it to people who don't,\nand they all have asked about the funny (to them) need for origin\nin git-pull/git-push command line sometimes (no refspecs) and not\nothers (with refspecs).\n\n-- \nShawn.\n"},{"id":"75325","messageId":"7vy76zf449.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"20080427173446.GM29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-27T20:13:26Z","receivedAt":"2008-04-27T20:13:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> But then they later wonder why they need `git pull origin branch`\n> to merge in branch, when they usually just say `git pull`. What is\n> the need for that funny keyword `origin`? Why do I have to say\n> where to get the branch from sometimes and not others?\n> ...\n> Just take the above as the rantings of someone who knows git a\n> little too well, and has tried to teach it to people who don't,\n> and they all have asked about the funny (to them) need for origin\n> in git-pull/git-push command line sometimes (no refspecs) and not\n> others (with refspecs).\n\nWhat's the constructive suggestion for improvement we can draw from this\nafter all? Should we deprecate the defaulting of \"origin\" so that\neverybody now should always say \"git pull $where\"? In other words, make\npeople more aware that what _they_ do is the special case to have only one\nremote to interact with?\n"},{"id":"75327","messageId":"4814E097.7030407@gnu.org","threadId":"13265","inReplyTo":"7vy76zf449.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-27T20:22:47Z","receivedAt":"2008-04-27T20:22:47Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> What's the constructive suggestion for improvement we can draw from this\n> after all? Should we deprecate the defaulting of \"origin\" so that\n> everybody now should always say \"git pull $where\"?\n\nbranch.*.remote would still provide a default, wouldn't it? And if \nmaster is by default set up to track origin/master, the behavior \nwouldn't change.\n\n> In other words, make\n> people more aware that what _they_ do is the special case to have only one\n> remote to interact with?\n\nI think \"git pull\" is different, because it is more often fetching from \none defined place (while Shawn said that he has a need for one-to-many \n\"git push\"es and so do I). For \"git pull\", the branch config provides a \nvaluable default more often than for \"git push\".\n\nPaolo\n"},{"id":"75338","messageId":"20080428012113.GA15121@sigill.intra.peff.net","threadId":"13265","inReplyTo":"20080427173446.GM29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-28T01:21:13Z","receivedAt":"2008-04-28T01:21:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 27, 2008 at 01:34:46PM -0400, Shawn O. Pearce wrote:\n\n> Just take the above as the rantings of someone who knows git a\n> little too well, and has tried to teach it to people who don't,\n> and they all have asked about the funny (to them) need for origin\n> in git-pull/git-push command line sometimes (no refspecs) and not\n> others (with refspecs).\n\nI know git pretty well, and I find that particular distinction (that is,\nneeding to specify the remote if using refspecs, but not otherwise)\nannoying. And it _is_ a bit funny, but it has nothing to do with\nconcepts. It is purely a syntactic issue that relying on order of\narguments means you can't default earlier ones but specify later ones.\n\nWhether you hit this particular syntactic funniness depends totally on\nyour workflow. If you don't tend to default that particular argument,\nthen you won't see it. But there are plenty of workflows where you\nnever need to specify a remote, and then typing \"git push master:foo\"\nmakes you stop and blink for a second when it fails.\n\nOf course, I don't think there is a reasonable fix now, short of \"git\npush --ref master:foo\".\n\n-Peff\n"},{"id":"75339","messageId":"20080428012613.GB15121@sigill.intra.peff.net","threadId":"13265","inReplyTo":"4814E097.7030407@gnu.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-28T01:26:13Z","receivedAt":"2008-04-28T01:26:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 27, 2008 at 10:22:47PM +0200, Paolo Bonzini wrote:\n\n> I think \"git pull\" is different, because it is more often fetching from \n> one defined place (while Shawn said that he has a need for one-to-many \n> \"git push\"es and so do I). For \"git pull\", the branch config provides a \n> valuable default more often than for \"git push\".\n\nI think it is highly dependent on your workflow. I would have said the\nexact opposite.\n\nFor example, on one project, I keep a \"working\" repo on my laptop where\nI develop and integrate work from others. I get their work by pulling\nindividually from other developers. But when I push, it always goes to\none place: my \"publish\" repo, where the other developers will grab my\nchanges.\n\nIn that workflow, I pull from many different places, but always push to\none. I assumed that is actually similar to the Linus \"integrator\"\nworkflow (although I think he just does one-shot pulls without defining\nremotes).\n\n-Peff\n"},{"id":"75342","messageId":"20080428033237.GN29771@spearce.org","threadId":"13265","inReplyTo":"7vy76zf449.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-28T03:32:38Z","receivedAt":"2008-04-28T03:32:38Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > But then they later wonder why they need `git pull origin branch`\n> > to merge in branch, when they usually just say `git pull`. What is\n> > the need for that funny keyword `origin`? Why do I have to say\n> > where to get the branch from sometimes and not others?\n> \n> What's the constructive suggestion for improvement we can draw from this\n> after all? Should we deprecate the defaulting of \"origin\" so that\n> everybody now should always say \"git pull $where\"?\n\nYes, I think that is what I was thinking. By making users always say\nwhere they are pulling, fetching or pushing from/to it becomes less\nweird when you have to give a refspec too.\n\nBut this clearly harms the `git pull` case that relies upon the magic\nbranch.$name.remote and branch.$name.merge keys, as now git-pull is\nexpecting the user to supply a remote name, but one was already saved\nfor this current branch.\n\nIt also clearly harms people who have only origin and want to grab\nupdates from there with just `git fetch` or `git pull`. Such a\nchange would be asking these users to enter a longer command line.\n\nOn the other hand, I think it would teach those users how to better\nmake use of git, and may cause less questions when they have to\nstep slightly outside of their normal use case and specify a refspec.\n\n> In other words, make\n> people more aware that what _they_ do is the special case to have only one\n> remote to interact with?\n\nMy special case is always the other guys' common case. You can't\nplease everone. But here I think that _our_ special case (where we\nalways give the remote name/URL to fetch/pull/push) helps users to\nlearn the tool better, because it erases a special case from their\nvocabularly of Git commands.\n\n-- \nShawn.\n"},{"id":"75344","messageId":"48155AAC.5020106@gnu.org","threadId":"13265","inReplyTo":"20080428033237.GN29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T05:03:40Z","receivedAt":"2008-04-28T05:03:40Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Yes, I think that is what I was thinking. By making users always say\n> where they are pulling, fetching or pushing from/to it becomes less\n> weird when you have to give a refspec too.\n> \n> But this clearly harms the `git pull` case that relies upon the magic\n> branch.$name.remote and branch.$name.merge keys, as now git-pull is\n> expecting the user to supply a remote name, but one was already saved\n> for this current branch.\n\nI would have no problem at all in removing the defaulting to \"origin\". \nLeaving the magic branch..{remote,merge} as the only case where \n0-argument \"git pull\" is allowed, would be much simpler to explain, and \nwould not impact the \"centralized\" operation mode.\n\nPaolo\n"},{"id":"75345","messageId":"48155B7F.8020202@gnu.org","threadId":"13265","inReplyTo":"20080428012613.GB15121@sigill.intra.peff.net","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T05:07:11Z","receivedAt":"2008-04-28T05:07:11Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> I think \"git pull\" is different, because it is more often fetching from \n>> one defined place (while Shawn said that he has a need for one-to-many \n>> \"git push\"es and so do I). For \"git pull\", the branch config provides a \n>> valuable default more often than for \"git push\".\n> \n> I think it is highly dependent on your workflow. I would have said the\n> exact opposite.\n\nAh, to do so I always do fetch+gitk+merge (or cherry-pick instead of \nmerge). I use \"git pull\" (without arguments) only when I can blindly \nnot care about what's on the other side, e.g. because it's Junio who \nassures it is good. :-)\n\nI actually think I never use \"git pull\" with arguments, but that's \nevidently me.\n\nPaolo\n"},{"id":"75346","messageId":"20080428060810.GA11858@cuci.nl","threadId":"13265","inReplyTo":"20080428033237.GN29771@spearce.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-04-28T06:08:10Z","receivedAt":"2008-04-28T06:08:10Z","isPatch":true,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>It also clearly harms people who have only origin and want to grab\n>updates from there with just `git fetch` or `git pull`. Such a\n>change would be asking these users to enter a longer command line.\n\nMaybe this can be accomodated by having git fetch/git pull reference\nall targets specified in the config file if none are specified on the\ncommand line?\n\n>On the other hand, I think it would teach those users how to better\n>make use of git, and may cause less questions when they have to\n>step slightly outside of their normal use case and specify a refspec.\n\nI've been using git since november, and I found the magic \"origin\"\ndefault one of the most confusing aspects (to figure out when it applies\nand when not, and why (or why not)).\n-- \nSincerely, srb@cuci.nl\n Stephen R. van den Berg.\n"},{"id":"75354","messageId":"20080428090948.GC16153@sigill.intra.peff.net","threadId":"13265","inReplyTo":"48155B7F.8020202@gnu.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-28T09:09:48Z","receivedAt":"2008-04-28T09:09:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 28, 2008 at 07:07:11AM +0200, Paolo Bonzini wrote:\n\n> Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of \n> merge). I use \"git pull\" (without arguments) only when I can blindly not \n> care about what's on the other side, e.g. because it's Junio who assures \n> it is good. :-)\n\nWell, I lied a little; I also use fetch + examine + merge. But the idea\nabout arguments holds true for \"git fetch\".\n\n-Peff\n"},{"id":"75356","messageId":"20080428091150.GA16209@sigill.intra.peff.net","threadId":"13265","inReplyTo":"20080428090948.GC16153@sigill.intra.peff.net","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-28T09:11:51Z","receivedAt":"2008-04-28T09:11:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 28, 2008 at 05:09:48AM -0400, Jeff King wrote:\n\n> On Mon, Apr 28, 2008 at 07:07:11AM +0200, Paolo Bonzini wrote:\n> \n> > Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of \n> > merge). I use \"git pull\" (without arguments) only when I can blindly not \n> > care about what's on the other side, e.g. because it's Junio who assures \n> > it is good. :-)\n> \n> Well, I lied a little; I also use fetch + examine + merge. But the idea\n> about arguments holds true for \"git fetch\".\n\nBTW, I find myself decreasingly using \"git fetch\" in favor of \"git\nremote update\" which handles fetching from multiple remotes. That seems\nto be analagous to what you want with \"git push\". IOW, maybe instead of\nchanging the default behavior of \"git push\" you would be happy with a\n\"git remote push\" which impacted multiple remotes.\n\n-Peff\n"},{"id":"75357","messageId":"48159688.2030202@gnu.org","threadId":"13265","inReplyTo":"20080428091150.GA16209@sigill.intra.peff.net","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T09:19:04Z","receivedAt":"2008-04-28T09:19:04Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> BTW, I find myself decreasingly using \"git fetch\" in favor of \"git\n> remote update\" which handles fetching from multiple remotes. That seems\n> to be analagous to what you want with \"git push\". IOW, maybe instead of\n> changing the default behavior of \"git push\" you would be happy with a\n> \"git remote push\" which impacted multiple remotes.\n\nI'm preparing a patch that has \"git fetch\" fetch from all remotes (same \nas \"git remote update\" with no groups defined) and \"git push\" push to \nall remotes. I think this is much more sound; and it's not really as \neasy as this, but that's the idea. :-)\n\nAs always, thanks to the list for straightening my first design. It \nhappened for --track, for prepare-commit-msg (by the way, I am using it \nnow that it's in 1.5.5, and it helps me so much) and for this too. I \nhope that my improvements to git is worth your time, guys.\n\nPaolo\n"},{"id":"75367","messageId":"alpine.DEB.1.00.0804281132420.5399@eeepc-johanness","threadId":"13265","inReplyTo":"48159688.2030202@gnu.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T10:33:49Z","receivedAt":"2008-04-28T10:33:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Paolo Bonzini wrote:\n\n> I'm preparing a patch that has \"git fetch\" fetch from all remotes (same \n> as \"git remote update\" with no groups defined)\n\nFunny, I would think that this functionality belongs into git-remote \ninstead of git-fetch. Especially since it would be possible to reuse the \ncode you referred to...\n\nCiao,\nDscho\n"},{"id":"75368","messageId":"4815B3F6.1030402@gnu.org","threadId":"13265","inReplyTo":"alpine.DEB.1.00.0804281132420.5399@eeepc-johanness","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T11:24:38Z","receivedAt":"2008-04-28T11:24:38Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 28 Apr 2008, Paolo Bonzini wrote:\n> \n>> I'm preparing a patch that has \"git fetch\" fetch from all remotes (same \n>> as \"git remote update\" with no groups defined)\n> \n> Funny, I would think that this functionality belongs into git-remote \n> instead of git-fetch.\n\nMaybe, but I'm pretty satisfied with the result. It would take more \neffort than that to add all the functionality within \"git remote \nupdate\", and my patch series removes most of the magic associated with \n\"origin\".\n\n> Especially since it would be possible to reuse the \n> code you referred to...\n\nI checked and there's not much to reuse, since we don't care about \ngroups or anything else.\n\nStay tuned -- I'm looking forward to any criticism.\n\nPaolo\n"},{"id":"75369","messageId":"alpine.DEB.1.00.0804281256380.5399@eeepc-johanness","threadId":"13265","inReplyTo":"4815B3F6.1030402@gnu.org","subject":"Re: [PATCH resend] make \"git push\" update origin and mirrors, \"git push --mirror\" update mirrors","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T11:57:18Z","receivedAt":"2008-04-28T11:57:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Paolo Bonzini wrote:\n\n> Johannes Schindelin wrote:\n>\n> > On Mon, 28 Apr 2008, Paolo Bonzini wrote:\n> > \n> > > I'm preparing a patch that has \"git fetch\" fetch from all remotes \n> > > (same as \"git remote update\" with no groups defined)\n> > \n> > Funny, I would think that this functionality belongs into git-remote \n> > instead of git-fetch.\n> \n> Maybe, but I'm pretty satisfied with the result. It would take more \n> effort than that to add all the functionality within \"git remote \n> update\", and my patch series removes most of the magic associated with \n> \"origin\".\n\nThen I must have misread your statement \"same as \"git remote \nupdate\" with no groups defined\".\n\nCiao,\nDscho\n"},{"id":"75386","messageId":"cover.1209391614.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"4812DA50.3000702@gnu.org","subject":"[PATCH 0/7] limit the usage of the default remote \"origin\" to the minimum","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:11Z","receivedAt":"2008-04-28T15:32:11Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"The aim of this series of patches limits the \"magic\" default of\n\"origin\", that git sometimes uses in its fetch/push/pull commands,\nto what I consider to be the bare acceptable minimum. (I will discuss\nlater what this minimum is).\n\nThis has two aims. The first is to make people more aware of what remote\nthey are interacting with. The second is to allow faster operation for\nthose people that do work with more than one remote. While \"git remote\nupdate\" already does some of the latter, it is limited to fetching.\nThese patches use a different approach: they take the zero-argument\ncommands \"git fetch\", \"git push\", \"git pull\" that all git users know,\nand make them scale nicely to use cases with >1 remote.\n\nPatches 1 to 4 deal with \"git push\". The problem here is that the\n\"magic\" default operation (\"git push sends to origin all refs that\nare already present there\"), as of new, cannot be explained in the\nconfiguration, and this is fixed by patches 1 and 2. Patch 1 adds a\nspecial push refspec meaning \"consider all refs already on the remote\",\nand patch 2 makes git-clone add one such line when it creates the\norigin remote.\n\nPatch 3 could also be split out of this series. It adds to \"git-remote\nadd\" a new --push option, that sets up a push refspec for the newly\ncreated remote. If git-clone will ever use \"git-remote add\", it should\npass this option. This patch also defines the \"--push --mirror\" combo\nto create a remote *which will backup the current repository*. I posted\nthis patch here, and placed it as the third, because some design decisions\nin patch 4 are clearer if one considers the --push --mirror use case.\n\nPatch 4 is a reworking of my previous patch. Instead of having \"git\npush\" push to \"all mirrors plus the magic origin branch\", it will\npush to \"all remotes having a push refspec\". In the future, this\nwill always include the origin branch because of patch 2, while\nright now the origin branch is still used if no remote has a\npush refspec (for backwards compatibility -- more discussion in the\npatch log message).\n\nThis patch may cause incompatibilities to be warned about in\nthe release notes. Luckily, these incompatibilities only affect\nusers that already know their way in .git/config, because no porcelain\ncommand creates push refspecs.\n\nPatches 5 and 6 affect \"git pull\". Pulling uses the magic origin branch\nless often, because branch.*.remote already establishes a saner default.\nTherefore, here we can actually warn and deprecate the misfeature for\nreal (patch 6). Patch 5 however is still needed, so that \"git pull\"\nitself decides when to use the magic \"origin\" branch instead of making\nthe decision in \"git fetch\".\n\nFinally, patch 7 affects \"git fetch\". As hinted earlier, I chose to\nduplicate the functionality already present in \"git remote update\"\n(for the case where remotes are not grouped), but the code is much\nsimpler so there is no incentive (at least for now) in borrowing code\nfrom \"git remote update\" into \"git fetch\"---actually, as a cleanup\nit is maybe possible to borrow code in the other direction.\n\nThe patch series touches relatively many areas. Some patches could\ngo in separately as cleanups, new features or just because their effect\nis less profound. In particular:\n- patch 5 could go in separately as a code cleanup;\n- patch 6 does not affect the user operation, it just adds a warning\n that should not appear for the most common cases; it can go in IMHO\n even if \"git fetch\" and \"git push\" keep the magic choice of \"origin\".\n- patches 1 and 2 add a new feature and could go in separately.\n\nAs a closing comment (this cover letter is already too long possibly!),\nI think this design is sound. In particular, here is a list of\ncitations from the earlier thread in light of which, I think, this\ndesign makes a lot of sense.\n\n\"I _hate_ the default remote.\"\n\tWell, this series does not make origin behave differently. Still,\n\ta \"remote configured by default to behave in a particular way\",\n\tis obviously much better than \"a remote whose default behavior\n\tis built into git\". Also, even though this series could not\n\tcompletely remove git's knowledge of origin, that's only motivated\n\tby backwards compatibility.\n\n\"I am sympathetic when they want to say \"git push\" and have it default\n to that single other repository.\"\n\tSo that's what git will keep doing. However...\n\n\"Should we [...] make people more aware that what _they_ do is the\n special case to have only one remote to interact with?\"\n\t... after this series, it will scale to >1 remote consistently\n\twith this aim. \"git fetch\" and \"git push\" will examine every\n\tpossible remote (and there is just one in the simple \"CVS\" case).\n\n\"BTW, I find myself decreasingly using \"git fetch\" in favor of \"git\n remote update\" which handles fetching from multiple remotes.\"\n\tThe series remove the need to switch from \"git fetch\" to\n\t\"git remote update\" as one learns the power of DVCS.\n\n\"[Removing a default altogether] harms the `git pull` case that relies\nupon the magic branch.$name.remote and branch.$name.merge keys.\"\n\tIndeed, IMHO the way to go (in general, and especially for\n\t\"git pull\") is to deprecate the magic usage of \"origin\"---not\n\tto deprecate the zero-argument versions.\n\n\"I know git pretty well, and I find that particular distinction (that is,\nneeding to specify the remote if using refspecs, but not otherwise)\nannoying. It is purely a syntactic issue that relying on order of\narguments means you can't default earlier ones but specify later ones.\"\n\tThe patches admittedly does not tackle that. It actually makes\n\tit \"harder to solve\", because it is not anymore a matter of\n\tdefault arguments. Zero-argument push and fetch work on\n\tall remotes (suggested also by Stephen R. van der Berg in the\n\tthread), not on just one. On the other hand, it makes it\n\teasier to explain: all remotes? no need to specify anything;\n\tone remote? always specify it.\n\n\nPaolo Bonzini (7):\n add special \"matching refs\" refspec\n add push line in git-clone\n Add a --push option to \"git-remote add\"\n make \"git push\" update all push repositories.\n don't rely on zero-argument \"git fetch\" from within git pull\n warn on \"git pull\" without a given branch..remote value\n make \"git fetch\" update all fetch repositories\n\n Documentation/git-fetch.txt | 7 ++\n Documentation/git-pull.txt | 9 ++-\n Documentation/git-push.txt | 35 +++++++---\n Documentation/git-remote.txt | 31 ++++++---\n builtin-fetch.c | 109 ++++++++++++++++-------------\n builtin-push.c | 67 +++++++++++++++---\n builtin-remote.c | 32 ++++++--\n builtin-send-pack.c | 10 +++-\n git-clone.sh | 2 +\n git-parse-remote.sh | 8 ++\n git-pull.sh | 9 ++-\n remote.c | 80 ++++++++++++++-------\n remote.h | 1 +\n t/t5400-send-pack.sh | 2 +-\n t/t5505-remote.sh | 26 +++++++-\n t/t5510-fetch.sh | 19 +++++-\n t/t5511-refspec.sh | 5 +-\n t/t5515-fetch-merge-logic.sh | 8 +--\n t/t5515/fetch.br-branches-default | 8 --\n t/t5515/fetch.br-branches-default-merge | 9 ---\n t/t5515/fetch.br-branches-default-octopus | 10 ---\n t/t5515/fetch.br-branches-one | 8 --\n t/t5515/fetch.br-branches-one-merge | 9 ---\n t/t5515/fetch.br-branches-one-octopus | 9 ---\n t/t5515/fetch.br-config-explicit | 11 ---\n t/t5515/fetch.br-config-explicit-merge | 11 ---\n t/t5515/fetch.br-config-explicit-octopus | 11 ---\n t/t5515/fetch.br-config-glob | 11 ---\n t/t5515/fetch.br-config-glob-merge | 11 ---\n t/t5515/fetch.br-config-glob-octopus | 11 ---\n t/t5515/fetch.br-remote-explicit | 11 ---\n t/t5515/fetch.br-remote-explicit-merge | 11 ---\n t/t5515/fetch.br-remote-explicit-octopus | 11 ---\n t/t5515/fetch.br-remote-glob | 11 ---\n t/t5515/fetch.br-remote-glob-merge | 11 ---\n t/t5515/fetch.br-remote-glob-octopus | 11 ---\n t/t5515/fetch.br-unconfig | 11 ---\n t/t5515/fetch.master | 11 ---\n t/t5515/refs.br-branches-default | 12 ---\n t/t5515/refs.br-branches-default-merge | 12 ---\n t/t5515/refs.br-branches-default-octopus | 12 ---\n t/t5515/refs.br-branches-one | 12 ---\n t/t5515/refs.br-branches-one-merge | 12 ---\n t/t5515/refs.br-branches-one-octopus | 12 ---\n t/t5515/refs.br-config-explicit | 15 ----\n t/t5515/refs.br-config-explicit-merge | 15 ----\n t/t5515/refs.br-config-explicit-octopus | 15 ----\n t/t5515/refs.br-config-glob | 15 ----\n t/t5515/refs.br-config-glob-merge | 15 ----\n t/t5515/refs.br-config-glob-octopus | 15 ----\n t/t5515/refs.br-remote-explicit | 15 ----\n t/t5515/refs.br-remote-explicit-merge | 15 ----\n t/t5515/refs.br-remote-explicit-octopus | 15 ----\n t/t5515/refs.br-remote-glob | 15 ----\n t/t5515/refs.br-remote-glob-merge | 15 ----\n t/t5515/refs.br-remote-glob-octopus | 15 ----\n t/t5515/refs.br-unconfig | 11 ---\n t/t5515/refs.master | 11 ---\n t/t5516-fetch-push.sh | 41 +++++++++++\n t/t5517-push-mirror.sh | 84 ++++++++++++++++++++++-\n 60 files changed, 452 insertions(+), 614 deletions(-)\n delete mode 100644 t/t5515/fetch.br-branches-default\n delete mode 100644 t/t5515/fetch.br-branches-default-merge\n delete mode 100644 t/t5515/fetch.br-branches-default-octopus\n delete mode 100644 t/t5515/fetch.br-branches-one\n delete mode 100644 t/t5515/fetch.br-branches-one-merge\n delete mode 100644 t/t5515/fetch.br-branches-one-octopus\n delete mode 100644 t/t5515/fetch.br-config-explicit\n delete mode 100644 t/t5515/fetch.br-config-explicit-merge\n delete mode 100644 t/t5515/fetch.br-config-explicit-octopus\n delete mode 100644 t/t5515/fetch.br-config-glob\n delete mode 100644 t/t5515/fetch.br-config-glob-merge\n delete mode 100644 t/t5515/fetch.br-config-glob-octopus\n delete mode 100644 t/t5515/fetch.br-remote-explicit\n delete mode 100644 t/t5515/fetch.br-remote-explicit-merge\n delete mode 100644 t/t5515/fetch.br-remote-explicit-octopus\n delete mode 100644 t/t5515/fetch.br-remote-glob\n delete mode 100644 t/t5515/fetch.br-remote-glob-merge\n delete mode 100644 t/t5515/fetch.br-remote-glob-octopus\n delete mode 100644 t/t5515/fetch.br-unconfig\n delete mode 100644 t/t5515/fetch.master\n delete mode 100644 t/t5515/refs.br-branches-default\n delete mode 100644 t/t5515/refs.br-branches-default-merge\n delete mode 100644 t/t5515/refs.br-branches-default-octopus\n delete mode 100644 t/t5515/refs.br-branches-one\n delete mode 100644 t/t5515/refs.br-branches-one-merge\n delete mode 100644 t/t5515/refs.br-branches-one-octopus\n delete mode 100644 t/t5515/refs.br-config-explicit\n delete mode 100644 t/t5515/refs.br-config-explicit-merge\n delete mode 100644 t/t5515/refs.br-config-explicit-octopus\n delete mode 100644 t/t5515/refs.br-config-glob\n delete mode 100644 t/t5515/refs.br-config-glob-merge\n delete mode 100644 t/t5515/refs.br-config-glob-octopus\n delete mode 100644 t/t5515/refs.br-remote-explicit\n delete mode 100644 t/t5515/refs.br-remote-explicit-merge\n delete mode 100644 t/t5515/refs.br-remote-explicit-octopus\n delete mode 100644 t/t5515/refs.br-remote-glob\n delete mode 100644 t/t5515/refs.br-remote-glob-merge\n delete mode 100644 t/t5515/refs.br-remote-glob-octopus\n delete mode 100644 t/t5515/refs.br-unconfig\n delete mode 100644 t/t5515/refs.master\n"},{"id":"75388","messageId":"af57d23aca6137c1ae7702027ce3742433840872.1209391614.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"cover.1209391614.git.bonzini@gnu.org","subject":"[PATCH 1/7] add special \"matching refs\" refspec","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:12Z","receivedAt":"2008-04-28T15:32:12Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch provides a way to specify \"push matching heads\" using a\nspecial refspec \":\". This is used in the following patches to\nremove some of the magic behind \"origin\", but can also be useful\nindependent of those patches, because it allows \"push = +:\" as a way\nto specify that matching refs will be pushed but, in addition,\nforced updates will be allowed.\n\nAllowing +: goes in the direction of setting per-remote \"git push\"\noptions in the configuration. Previously, it was not possible to force\nupdates *and* keep the default behavior of only pushing matching refs.\n\nSigned-off-by: Paolo Bonzini \n---\n Documentation/git-push.txt | 13 ++++---\n builtin-send-pack.c | 10 +++++-\n remote.c | 80 +++++++++++++++++++++++++++++---------------\n remote.h | 1 +\n t/t5511-refspec.sh | 5 ++-\n t/t5516-fetch-push.sh | 41 ++++++++++++++++++++++\n 6 files changed, 115 insertions(+), 35 deletions(-)\n\n\tThe new code for match_refs, which does not have to distinguish\n\twhether pat is NULL or not, is much more readable IMHO.\n\tUnfortunately, diff makes a mess out of it.\n\n\tEnabling more \"git push\" options to be set in the configuration\n\twas suggested by Dscho, and is particularly useful if \"git push\"\n\tis to work on more than one repository (as is the case at the\n\tend of this series).\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex f06d94e..0cc44d7 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -46,12 +46,6 @@ specified, the same ref that referred to locally). If\n the optional leading plus `+` is used, the remote ref is updated\n even if it does not result in a fast forward update.\n +\n-Note: If no explicit refspec is found, (that is neither\n-on the command line nor in any Push line of the\n-corresponding remotes file---see below), then \"matching\" heads are\n-pushed: for every head that exists on the local side, the remote side is\n-updated if a head of the same name already exists on the remote side.\n-+\n `tag ` means the same as `refs/tags/:refs/tags/`.\n +\n A parameter without a colon pushes the from the source\n@@ -59,6 +53,13 @@ repository to the destination repository under the same name.\n +\n Pushing an empty allows you to delete the ref from\n the remote repository.\n++\n+The special refspec `:` (or `+:` to allow non-fast forward updates)\n+directs git to push \"matching\" heads: for every head that exists on\n+the local side, the remote side is updated if a head of the same name\n+already exists on the remote side. This is the default operation mode\n+if no explicit refspec is found (that is neither on the command line\n+nor in any Push line of the corresponding remotes file---see below).\n \n \\--all::\n \tInstead of naming each ref to push, specifies that all\ndiff --git a/builtin-send-pack.c b/builtin-send-pack.c\nindex 7f7bddf..8d1e7be 100644\n--- a/builtin-send-pack.c\n+++ b/builtin-send-pack.c\n@@ -642,9 +642,17 @@ static void verify_remote_names(int nr_heads, const char **heads)\n \tint i;\n \n \tfor (i = 0; i < nr_heads; i++) {\n+\t\tconst char *local = heads[i];\n \t\tconst char *remote = strrchr(heads[i], ':');\n \n-\t\tremote = remote ? (remote + 1) : heads[i];\n+\t\tif (*local == '+')\n+\t\t\tlocal++;\n+\n+\t\t/* A matching refspec is okay. */\n+\t\tif (remote == local && remote[1] == '\\0')\n+\t\t\tcontinue;\n+\n+\t\tremote = remote ? (remote + 1) : local;\n \t\tswitch (check_ref_format(remote)) {\n \t\tcase 0: /* ok */\n \t\tcase CHECK_REF_FORMAT_ONELEVEL:\ndiff --git a/remote.c b/remote.c\nindex 870d224..386213e 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -434,6 +434,14 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp\n \t\t}\n \n \t\trhs = strrchr(lhs, ':');\n+\n+\t\t/* Before going on, special case \":\" (or \"+:\") as a refspec\n+\t\t for matching refs. */\n+\t\tif (!fetch && rhs == lhs && rhs[1] == '\\0') {\n+\t\t\trs[i].matching = 1;\n+\t\t\tcontinue;\n+\t\t}\n+\n \t\tif (rhs) {\n \t\t\trhs++;\n \t\t\trlen = strlen(rhs);\n@@ -847,7 +855,7 @@ static int match_explicit(struct ref *src, struct ref *dst,\n \tconst char *dst_value = rs->dst;\n \tchar *dst_guess;\n \n-\tif (rs->pattern)\n+\tif (rs->pattern || rs->matching)\n \t\treturn errs;\n \n \tmatched_src = matched_dst = NULL;\n@@ -937,13 +945,23 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,\n \t\t\t\t\t\t const struct ref *src)\n {\n \tint i;\n+\tint matching_refs = -1;\n \tfor (i = 0; i < rs_nr; i++) {\n+\t\tif (rs[i].matching &&\n+\t\t (matching_refs == -1 || rs[i].force)) {\n+\t\t\tmatching_refs = i;\n+\t\t\tcontinue;\n+\t\t}\n+\n \t\tif (rs[i].pattern &&\n \t\t !prefixcmp(src->name, rs[i].src) &&\n \t\t src->name[strlen(rs[i].src)] == '/')\n \t\t\treturn rs + i;\n \t}\n-\treturn NULL;\n+\tif (matching_refs != -1)\n+\t\treturn rs + matching_refs;\n+\telse\n+\t\treturn NULL;\n }\n \n /*\n@@ -954,11 +972,17 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,\n int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,\n \t int nr_refspec, const char **refspec, int flags)\n {\n-\tstruct refspec *rs =\n-\t\tparse_push_refspec(nr_refspec, (const char **) refspec);\n+\tstruct refspec *rs;\n \tint send_all = flags & MATCH_REFS_ALL;\n \tint send_mirror = flags & MATCH_REFS_MIRROR;\n \n+\tstatic const char *default_refspec[] = { \":\", 0 };\n+\tif (!nr_refspec) {\n+\t\tnr_refspec = 1;\n+\t\trefspec = default_refspec;\n+\t}\n+\n+\trs = parse_push_refspec(nr_refspec, (const char **) refspec);\n \tif (match_explicit_refs(src, dst, dst_tail, rs, nr_refspec))\n \t\treturn -1;\n \n@@ -969,48 +993,50 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,\n \t\tchar *dst_name;\n \t\tif (src->peer_ref)\n \t\t\tcontinue;\n-\t\tif (nr_refspec) {\n-\t\t\tpat = check_pattern_match(rs, nr_refspec, src);\n-\t\t\tif (!pat)\n-\t\t\t\tcontinue;\n-\t\t}\n-\t\telse if (!send_mirror && prefixcmp(src->name, \"refs/heads/\"))\n+\n+\t\tpat = check_pattern_match(rs, nr_refspec, src);\n+\t\tif (!pat)\n+\t\t\tcontinue;\n+\n+\t\tif (pat->matching) {\n \t\t\t/*\n \t\t\t * \"matching refs\"; traditionally we pushed everything\n \t\t\t * including refs outside refs/heads/ hierarchy, but\n \t\t\t * that does not make much sense these days.\n \t\t\t */\n-\t\t\tcontinue;\n+\t\t\tif (!send_mirror && prefixcmp(src->name, \"refs/heads/\"))\n+\t\t\t\tcontinue;\n+\t\t\tdst_name = xstrdup(src->name);\n \n-\t\tif (pat) {\n+\t\t} else {\n \t\t\tconst char *dst_side = pat->dst ? pat->dst : pat->src;\n \t\t\tdst_name = xmalloc(strlen(dst_side) +\n \t\t\t\t\t strlen(src->name) -\n \t\t\t\t\t strlen(pat->src) + 2);\n \t\t\tstrcpy(dst_name, dst_side);\n \t\t\tstrcat(dst_name, src->name + strlen(pat->src));\n-\t\t} else\n-\t\t\tdst_name = xstrdup(src->name);\n+\t\t}\n \t\tdst_peer = find_ref_by_name(dst, dst_name);\n-\t\tif (dst_peer && dst_peer->peer_ref)\n-\t\t\t/* We're already sending something to this ref. */\n-\t\t\tgoto free_name;\n+\t\tif (dst_peer) {\n+\t\t\tif (dst_peer->peer_ref)\n+\t\t\t\t/* We're already sending something to this ref. */\n+\t\t\t\tgoto free_name;\n+\n+\t\t} else {\n+\t\t\tif (pat->matching && !(send_all || send_mirror))\n+\t\t\t\t/*\n+\t\t\t\t * Remote doesn't have it, and we have no\n+\t\t\t\t * explicit pattern, and we don't have\n+\t\t\t\t * --all nor --mirror.\n+\t\t\t\t */\n+\t\t\t\tgoto free_name;\n \n-\t\tif (!dst_peer && !nr_refspec && !(send_all || send_mirror))\n-\t\t\t/*\n-\t\t\t * Remote doesn't have it, and we have no\n-\t\t\t * explicit pattern, and we don't have\n-\t\t\t * --all nor --mirror.\n-\t\t\t */\n-\t\t\tgoto free_name;\n-\t\tif (!dst_peer) {\n \t\t\t/* Create a new one and link it */\n \t\t\tdst_peer = make_linked_ref(dst_name, dst_tail);\n \t\t\thashcpy(dst_peer->new_sha1, src->new_sha1);\n \t\t}\n \t\tdst_peer->peer_ref = src;\n-\t\tif (pat)\n-\t\t\tdst_peer->force = pat->force;\n+\t\tdst_peer->force = pat->force;\n \tfree_name:\n \t\tfree(dst_name);\n \t}\ndiff --git a/remote.h b/remote.h\nindex 6878c52..5b0a2b4 100644\n--- a/remote.h\n+++ b/remote.h\n@@ -47,6 +47,7 @@ int remote_has_url(struct remote *remote, const char *url);\n struct refspec {\n \tunsigned force : 1;\n \tunsigned pattern : 1;\n+\tunsigned matching : 1;\n \n \tchar *src;\n \tchar *dst;\ndiff --git a/t/t5511-refspec.sh b/t/t5511-refspec.sh\nindex 670a8f1..22ba380 100755\n--- a/t/t5511-refspec.sh\n+++ b/t/t5511-refspec.sh\n@@ -23,10 +23,13 @@ test_refspec () {\n }\n \n test_refspec push ''\t\t\t\t\t\tinvalid\n-test_refspec push ':'\t\t\t\t\t\tinvalid\n+test_refspec push ':'\n+test_refspec push '::'\t\t\t\t\t\tinvalid\n+test_refspec push '+:'\n \n test_refspec fetch ''\n test_refspec fetch ':'\n+test_refspec fetch '::'\t\t\t\t\t\tinvalid\n \n test_refspec push 'refs/heads/*:refs/remotes/frotz/*'\n test_refspec push 'refs/heads/*:refs/remotes/frotz'\t\tinvalid\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 0a757d5..53e47e1 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -165,6 +165,47 @@ test_expect_success 'push with matching heads' '\n \n '\n \n+test_expect_success 'push with matching heads on the command line' '\n+\n+\tmk_test heads/master &&\n+\tgit push testrepo : &&\n+\tcheck_push_result $the_commit heads/master\n+\n+'\n+\n+test_expect_success 'failed (non-fast-forward) push with matching heads' '\n+\n+\tmk_test heads/master &&\n+\tgit push testrepo : &&\n+\tgit commit --amend -massaged &&\n+\t! git push testrepo &&\n+\tcheck_push_result $the_commit heads/master &&\n+\tgit reset --hard $the_commit\n+\n+'\n+\n+test_expect_success 'push --force with matching heads' '\n+\n+\tmk_test heads/master &&\n+\tgit push testrepo : &&\n+\tgit commit --amend -massaged &&\n+\tgit push --force testrepo &&\n+\t! check_push_result $the_commit heads/master &&\n+\tgit reset --hard $the_commit\n+\n+'\n+\n+test_expect_success 'push with matching heads and forced update' '\n+\n+\tmk_test heads/master &&\n+\tgit push testrepo : &&\n+\tgit commit --amend -massaged &&\n+\tgit push testrepo +: &&\n+\t! check_push_result $the_commit heads/master &&\n+\tgit reset --hard $the_commit\n+\n+'\n+\n test_expect_success 'push with no ambiguity (1)' '\n \n \tmk_test heads/master &&\n-- \n1.5.5\n"},{"id":"75383","messageId":"ff298458e7efc14721fdc0420432bf33efd76784.1209391614.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"af57d23aca6137c1ae7702027ce3742433840872.1209391614.git.bonzini@gnu.org","subject":"[PATCH 2/7] add push line in git-clone","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:13Z","receivedAt":"2008-04-28T15:32:13Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch makes git-clone add a remote.origin.push line, using the\nnew \":\" special refspec. This is useful in the following patches that\nmodify the behavior of \"git push\"; right now, it only adds clarity.\n\nSigned-off-by: Paolo Bonzini \n---\n git-clone.sh | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 2636159..7a5570a 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -480,6 +480,8 @@ then\n \t# Set up the mappings to track the remote branches.\n \tgit config remote.\"$origin\".fetch \\\n \t\t\"+refs/heads/*:$remote_top/*\" '^$' &&\n+\tgit config remote.\"$origin\".push \\\n+\t\t\":\" '^$' &&\n \n \t# Write out remote.$origin config, and update our \"$head_points_at\".\n \tcase \"$head_points_at\" in\n-- \n1.5.5\n"},{"id":"75387","messageId":"65b938da49b447129297d4dbf20191be52d16670.1209391614.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"ff298458e7efc14721fdc0420432bf33efd76784.1209391614.git.bonzini@gnu.org","subject":"[PATCH 3/7] Add a --push option to \"git-remote add\"","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:14Z","receivedAt":"2008-04-28T15:32:14Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch adds a --push option to \"git-remote add\" which sets up a\npush refspec. This will be useful after the following patch to\n\"git-push\", which will make heavier use of push refspecs. Even now,\nhowever, the option combination \"--mirror --push\" can be used to set\nup a mirror *of this repository*, with a normal fetch refspec\n(refs/heads/*:refs/remotes/mirror/*) but with the remote..mirror\noption set.\n\nSigned-off-by: Paolo Bonzini \n---\n Documentation/git-remote.txt | 25 +++++++++++++++++++------\n builtin-remote.c | 32 ++++++++++++++++++++++++--------\n t/t5505-remote.sh | 26 +++++++++++++++++++++++++-\n t/t5517-push-mirror.sh | 2 +-\n 4 files changed, 69 insertions(+), 16 deletions(-)\n\n\tMy earlier preference for \"--mirror\" as an option for\n\tmirrored-from-here remotes is due to my earlier experience\n\twith arch (from which I migrated to git). However, I'm very\n\tfine with \"--mirror --push\" since it's consistent with the\n\tmeaning of the new option --push.\n\n\tThis patch does not depend on patch 4, on the contrary the\n\tdependency is the other way round. However, it does not make\n\tmuch sense as an independent change. That's why the documentation\n\tfor --push leaves something to be desired. It will be fixed in\n\tpatch 4, as the doc will refer to the behavior implemented there.\n\ndiff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\nindex b20e851..e779905 100644\n--- a/Documentation/git-remote.txt\n+++ b/Documentation/git-remote.txt\n@@ -10,7 +10,7 @@ SYNOPSIS\n --------\n [verse]\n 'git-remote'\n-'git-remote' add [-t ] [-m ] [-f] [--mirror] \n+'git-remote' add [-t ] [-m ] [-f] [--mirror] [--push] \n 'git-remote' rm \n 'git-remote' show \n 'git-remote' prune \n@@ -47,11 +47,24 @@ With `-m ` option, `$GIT_DIR/remotes//HEAD` is set\n up to point at remote's `` branch instead of whatever\n branch the `HEAD` at the remote repository actually points at.\n +\n-In mirror mode, enabled with `\\--mirror`, the refs will not be stored\n-in the 'refs/remotes/' namespace, but in 'refs/heads/'. This option\n-only makes sense in bare repositories. If a remote uses mirror\n-mode, furthermore, `git push` will always behave as if `\\--mirror`\n-was passed.\n+`\\--push` mode adds a `push` configuration line for the remote.\n+It also affects the operation of mirror mode.\n++\n+Mirror mode, enabled with `\\--mirror`, specifies that one of the\n+repositories (either the current one or the remote one) is giving\n+up control on its refs namespace to the other repository. If a\n+remote uses mirror mode, furthermore, `git push` will always\n+behave as if `\\--mirror` was passed.\n+\n+If `\\--mirror` is given without `\\--push`, this repository will\n+act as a mirror of the remote, and hence the remote's refs will not\n+be stored in the 'refs/remotes/' namespace, but in 'refs/heads/';\n+this only makes sense in bare repositories. If the two options\n+are given in combination, instead, the other repository will\n+act as a mirror of this one; in this case, the effect of mirror\n+mode is that `git-push` will always add any newly created local\n+refs to the remote, will force updates of locally updated refs,\n+and will remove any deleted refs from the remote too.\n \n 'rm'::\n \ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex 8b63619..759dddb 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -56,7 +56,7 @@ static int fetch_remote(const char *name)\n \n static int add(int argc, const char **argv)\n {\n-\tint fetch = 0, mirror = 0;\n+\tint fetch = 0, mirror = 0, push = 0;\n \tstruct path_list track = { NULL, 0, 0 };\n \tconst char *master = NULL;\n \tstruct remote *remote;\n@@ -71,6 +71,7 @@ static int add(int argc, const char **argv)\n \t\t\t\"branch(es) to track\", opt_parse_track),\n \t\tOPT_STRING('m', \"master\", &master, \"branch\", \"master branch\"),\n \t\tOPT_BOOLEAN(0, \"mirror\", &mirror, \"no separate remotes\"),\n+\t\tOPT_BOOLEAN(0, \"push\", &push, \"make \\\"git push\\\" work on this remote\"),\n \t\tOPT_END()\n \t};\n \n@@ -101,23 +102,38 @@ static int add(int argc, const char **argv)\n \tstrbuf_reset(&buf);\n \tstrbuf_addf(&buf, \"remote.%s.fetch\", name);\n \n-\tif (track.nr == 0)\n-\t\tpath_list_append(\"*\", &track);\n-\tfor (i = 0; i < track.nr; i++) {\n-\t\tstruct path_list_item *item = track.items + i;\n+\tfor (i = 0; i < (track.nr ? track.nr : 1); i++) {\n+\t\tconst char *path = track.nr ? track.items[i].path : \"*\";\n \n \t\tstrbuf_reset(&buf2);\n \t\tstrbuf_addch(&buf2, '+');\n-\t\tif (mirror)\n+\t\tif (mirror && !push)\n \t\t\tstrbuf_addf(&buf2, \"refs/%s:refs/%s\",\n-\t\t\t\t\titem->path, item->path);\n+\t\t\t\t\tpath, path);\n \t\telse\n \t\t\tstrbuf_addf(&buf2, \"refs/heads/%s:refs/remotes/%s/%s\",\n-\t\t\t\t\titem->path, name, item->path);\n+\t\t\t\t\tpath, name, path);\n \t\tif (git_config_set_multivar(buf.buf, buf2.buf, \"^$\", 0))\n \t\t\treturn 1;\n \t}\n \n+\tif (push) {\n+\t\tstrbuf_reset(&buf);\n+\t\tstrbuf_addf(&buf, \"remote.%s.push\", name);\n+\n+\t\tfor (i = 0; i < (track.nr ? track.nr : 1); i++) {\n+\t\t\tstrbuf_reset(&buf2);\n+\t\t\tif (track.nr) {\n+\t\t\t\tconst char *path = track.items[i].path;\n+\t\t\t\tstrbuf_addf(&buf2, \"refs/heads/%s:refs/heads/%s\",\n+\t\t\t\t\t\tpath, path);\n+\t\t\t} else\n+\t\t\t\tstrbuf_addstr(&buf2, \":\");\n+\t\t\tif (git_config_set_multivar(buf.buf, buf2.buf, \"^$\", 0))\n+\t\t\t\treturn 1;\n+\t\t}\n+\t}\n+\n \tif (mirror) {\n \t\tstrbuf_reset(&buf);\n \t\tstrbuf_addf(&buf, \"remote.%s.mirror\", name);\ndiff --git a/t/t5505-remote.sh b/t/t5505-remote.sh\nindex 48ff2d4..56e5e06 100755\n--- a/t/t5505-remote.sh\n+++ b/t/t5505-remote.sh\n@@ -28,7 +28,7 @@ tokens_match () {\n }\n \n check_remote_track () {\n-\tactual=$(git remote show \"$1\" | sed -n -e '$p') &&\n+\tactual=$(git remote show \"$1\" | sed -n -e '/Tracked/!d;n;p') &&\n \tshift &&\n \ttokens_match \"$*\" \"$actual\"\n }\n@@ -269,4 +269,28 @@ test_expect_success 'reject adding remote with an invalid name' '\n \n '\n \n+test_expect_success 'fetching from push mirror leaves refs/head intact' '\n+\n+\t(cd four && git init\n+\t >file34 &&\n+\t git add file34 &&\n+\t test_tick &&\n+\t git commit -m \"Initial alternative\")\n+\tcd one && \n+\tgit remote add --mirror --push four ../four &&\n+\tgit fetch four &&\n+\tgit rev-parse -s --verify refs/remotes/four/master\n+\t! test -f file34\n+'\n+\n+test_expect_success 'fetching from mirror overwrites refs/head' '\n+\n+\tcd four &&\n+\ttest -f file34 &&\n+\tgit remote add --mirror one ../one &&\n+\tgit fetch one &&\n+\t! git rev-parse -s --verify refs/remotes/one/master\n+\t! test -f file34\n+'\n+\n test_done\ndiff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh\nindex ea49ded..cacc08c 100755\n--- a/t/t5517-push-mirror.sh\n+++ b/t/t5517-push-mirror.sh\n@@ -25,7 +25,7 @@ mk_repo_pair () {\n \t(\n \t\tcd master &&\n \t\tgit init &&\n-\t\tgit remote add $1 up ../mirror\n+\t\tgit remote add --push $1 up ../mirror\n \t)\n }\n \n-- \n1.5.5\n"},{"id":"75384","messageId":"d941a7a16cb7d5529b22a47f1dc7b986ba66ee56.1209391615.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"65b938da49b447129297d4dbf20191be52d16670.1209391614.git.bonzini@gnu.org","subject":"[PATCH 4/7] make \"git push\" update all push repositories.","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:15Z","receivedAt":"2008-04-28T15:32:15Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch builds on the infrastructure for \"git remote add --push\"\nto make the behavior of \"git push\" more general. Because now remotes\ncan be explicitly designated for pushing (previously, you had no\nway to do this *and* keep the \"matching refspecs\" behavior of \"git push\"),\nnow \"git push\" and \"git push --mirror\" can work like this:\n\n- \"git push\" pushes to all push remotes.\n\n- \"git push --mirror\" only updates mirror repositories, without touching\n other push remotes.\n\nFurthermore, \"git push --all\" is now invalid without a repository.\nI did this because --all and --mirror are incompatible, and so the\noperation of a DWIM \"git push --all\" would probably not be what\nthe user meant.\n\nAmong the use cases of this, consider when a project has a public\nrepository managed by the integrator, but the integrator also wants to\npublish his own topic branches somewhere. In this case, the integrator can\njust do \"git push\" and push the public branches to the public repository,\nas well as his own topic branches to his own unofficial mirror.\n\nSigned-off-by: Paolo Bonzini \n---\n Documentation/git-push.txt | 22 +++++++++--\n Documentation/git-remote.txt | 10 +++---\n builtin-push.c | 67 ++++++++++++++++++++++++++++------\n t/t5400-send-pack.sh | 2 +-\n t/t5517-push-mirror.sh | 82 ++++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 161 insertions(+), 22 deletions(-)\n\n\tI think it is too early to warn if there is no push refspec for.\n\torigin (as I'll do for git-fetch in the final patch of the series).\n\tAfter all, clones made with any current version of git do *not*\n\thave a remote.origin.push refspec.\n\n\tThis changes the behavior of \"git push\" if the user has a remote\n\twith push refspecs in his configuration; in this case the user\n\tshould execute \"git config remote.origin.push :\" so that \"git\n\tpush\" considers the origin remote too. This should be written in\n\tthe release notes.\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 0cc44d7..a1436f4 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -29,6 +29,14 @@ OPTIONS\n \tThe \"remote\" repository that is destination of a push\n \toperation. See the section <> below.\n \n+\tUnless \\--all or \\--tags are given, it is possible to\n+\tomit the destination repository and refspec. In this\n+\tcase, git will push to all remotes that have a\n+\t`remote..push` configuration line. In case\n+\tgit finds none, it will push to the \"origin\" remote;\n+\tthis however is only done for backwards compatibility\n+\twith older versions of git.\n+\n ::\n \tThe canonical format of a parameter is\n \t`+?:`; that is, an optional plus `+`, followed\n@@ -71,8 +79,14 @@ nor in any Push line of the corresponding remotes file---see below).\n \tbe mirrored to the remote repository. Newly created local\n \trefs will be pushed to the remote end, locally updated refs\n \twill be force updated on the remote end, and deleted refs\n-\twill be removed from the remote end. This is the default\n-\tif the configuration option `remote..mirror` is\n+\twill be removed from the remote end.\n+\n+\tFor every repository that git tries as a destination, it will\n+\talso look up the corresponding configuration option\n+\t`remote..mirror` and enables mirror mode\n+\tif it is set. Furthermore, if `git push --mirror` is used\n+\twithout specifying a destination repository, git will\n+\tonly push to those remotes that have the configuration option\n \tset.\n \n \\--dry-run::\n@@ -99,8 +113,8 @@ nor in any Push line of the corresponding remotes file---see below).\n \tremote repository to lose commits; use it with care.\n \n \\--repo=::\n-\tWhen no repository is specified the command defaults to\n-\t\"origin\"; this overrides it.\n+\tOverrides the default behavior of the command when no repository\n+\tis specified, so that is used as the destination repository.\n \n \\--thin, \\--no-thin::\n \tThese options are passed to `git-send-pack`. Thin\ndiff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\nindex e779905..d313a2f 100644\n--- a/Documentation/git-remote.txt\n+++ b/Documentation/git-remote.txt\n@@ -47,8 +47,9 @@ With `-m ` option, `$GIT_DIR/remotes//HEAD` is set\n up to point at remote's `` branch instead of whatever\n branch the `HEAD` at the remote repository actually points at.\n +\n-`\\--push` mode adds a `push` configuration line for the remote.\n-It also affects the operation of mirror mode.\n+`\\--push` mode configures the remote so that `git push` with\n+no arguments will attempt pushing to it. It also affects the\n+operation of `\\--mirror`.\n +\n Mirror mode, enabled with `\\--mirror`, specifies that one of the\n repositories (either the current one or the remote one) is giving\n@@ -102,9 +103,8 @@ be updated. (See linkgit:git-config[1]).\n DISCUSSION\n ----------\n \n-The remote configuration is achieved using the `remote.origin.url` and\n-`remote.origin.fetch` configuration variables. (See\n-linkgit:git-config[1]).\n+The remote configuration is achieved using the `remote..*`\n+configuration variables. (See linkgit:git-config[1]).\n \n Examples\n --------\ndiff --git a/builtin-push.c b/builtin-push.c\nindex b35aad6..f877e49 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -48,14 +48,12 @@ static void set_refspecs(const char **refs, int nr)\n \t}\n }\n \n-static int do_push(const char *repo, int flags)\n+static int do_push(struct remote *remote, int flags)\n {\n \tint i, errs;\n-\tstruct remote *remote = remote_get(repo);\n-\n-\tif (!remote)\n-\t\tdie(\"bad repository '%s'\", repo);\n-\n+\tconst char **push_refspec = refspec;\n+\tint push_refspec_nr = refspec_nr;\n+\n \tif (remote->mirror)\n \t\tflags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);\n \n@@ -70,8 +68,8 @@ static int do_push(const char *repo, int flags)\n \tif (!refspec\n \t\t&& !(flags & TRANSPORT_PUSH_ALL)\n \t\t&& remote->push_refspec_nr) {\n-\t\trefspec = remote->push_refspec;\n-\t\trefspec_nr = remote->push_refspec_nr;\n+\t\tpush_refspec = remote->push_refspec;\n+\t\tpush_refspec_nr = remote->push_refspec_nr;\n \t}\n \terrs = 0;\n \tfor (i = 0; i < remote->url_nr; i++) {\n@@ -86,7 +84,7 @@ static int do_push(const char *repo, int flags)\n \n \t\tif (verbose)\n \t\t\tfprintf(stderr, \"Pushing to %s\\n\", remote->url[i]);\n-\t\terr = transport_push(transport, refspec_nr, refspec, flags);\n+\t\terr = transport_push(transport, push_refspec_nr, push_refspec, flags);\n \t\terr |= transport_disconnect(transport);\n \n \t\tif (!err)\n@@ -98,6 +96,27 @@ static int do_push(const char *repo, int flags)\n \treturn !!errs;\n }\n \n+static int num_push_remotes;\n+\n+static int push_to_remote(struct remote *remote, void *priv)\n+{\n+\tint *p_flags = priv;\n+\tint rc;\n+\n+\t/* With \"git-push --mirror\", only push to mirrors. */\n+\tif ((*p_flags & TRANSPORT_PUSH_MIRROR) && !remote->mirror)\n+\t\treturn 0;\n+\tif (!remote->push_refspec_nr)\n+\t\treturn 0;\n+\n+\tnum_push_remotes++;\n+\trc = do_push (remote, *p_flags);\n+\n+\t/* No command-line errors should occur. */\n+\tassert (rc != -1);\n+\treturn rc;\n+}\n+\n int cmd_push(int argc, const char **argv, const char *prefix)\n {\n \tint flags = 0;\n@@ -108,6 +127,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \tint tags = 0;\n \tint rc;\n \tconst char *repo = NULL;\t/* default repository */\n+\tstruct remote *remote;\n \n \tstruct option options[] = {\n \t\tOPT__VERBOSE(&verbose),\n@@ -143,9 +163,32 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tset_refspecs(argv + 1, argc - 1);\n \t}\n \n-\trc = do_push(repo, flags);\n+\tif (!repo) {\n+\t\t/* Don't attempt to figure DWIM behavior when refspecs are\n+\t\t provided. */\n+\t\tif (all || tags)\n+\t\t\tdie(\"please specify destination repository together \"\n+\t\t\t \"with --all or --tags\");\n+\n+\t\tassert (!refspec);\n+\t\trc = for_each_remote (push_to_remote, &flags);\n+\t\tif (rc)\n+\t\t\treturn rc;\n+\t\tif (num_push_remotes)\n+\t\t\treturn 0;\n+\n+\t\t/* Fallback: use origin, but not for \"git push --mirror\". */\n+\t\tif (mirror)\n+\t\t\tdie(\"no mirrors configured, use git-push --mirror to force operation\");\n+\t}\n+\n+\tremote = remote_get(repo);\n+\tif (!remote)\n+\t\tdie(\"bad repository '%s'\", repo);\n+\n+\trc = do_push(remote, flags);\n \tif (rc == -1)\n \t\tusage_with_options(push_usage, options);\n-\telse\n-\t\treturn rc;\n+\n+\treturn rc;\n }\ndiff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh\nindex 2b6b6e3..ab01b2a 100755\n--- a/t/t5400-send-pack.sh\n+++ b/t/t5400-send-pack.sh\n@@ -118,7 +118,7 @@ test_expect_success \\\n \tmkdir parent && cd parent &&\n \tgit-init && touch file && git-add file && git-commit -m add &&\n \tcd .. &&\n-\tgit-clone parent child && cd child && git-push --all &&\n+\tgit-clone parent child && cd child && git-push --all origin &&\n \tcd ../parent &&\n \tgit-branch -a >branches && ! grep origin/master branches\n '\ndiff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh\nindex cacc08c..9afa741 100755\n--- a/t/t5517-push-mirror.sh\n+++ b/t/t5517-push-mirror.sh\n@@ -29,6 +29,26 @@ mk_repo_pair () {\n \t)\n }\n \n+# a more complicated setup where we have also an origin repo\n+mk_repo_three () {\n+\trm -rf master mirror origin &&\n+\tmkdir mirror &&\n+\t(\n+\t\tcd mirror &&\n+\t\tgit init\n+\t) &&\n+\tmkdir origin &&\n+\t(\n+\t\tcd origin &&\n+\t\tgit init\n+\t\techo one >foo && git add foo && git commit -m one\n+\t) &&\n+\tgit clone origin master &&\n+\t(\n+\t\tcd master &&\n+\t\tgit remote add --push --mirror up ../mirror\n+\t)\n+}\n \n # BRANCH tests\n test_expect_success 'push mirror creates new branches' '\n@@ -264,4 +284,66 @@ test_expect_success 'remote.foo.mirror=no has no effect' '\n \n '\n \n+test_expect_success 'mirrors are updated by \"git push\"' '\n+\n+\tmk_repo_three &&\n+\t(\n+\t\tcd master &&\n+\t\tgit branch keep master &&\n+\t\tgit branch remove master &&\n+\t\tgit push &&\n+\t\tgit branch -D remove\n+\t\tgit push\n+\t) &&\n+\t(\n+\t\tcd mirror &&\n+\t\tgit show-ref -s --verify refs/heads/keep &&\n+\t\tinvert git show-ref -s --verify refs/heads/remove\n+\t) &&\n+\t(\n+\t\tcd origin &&\n+\t\tinvert git show-ref -s --verify refs/heads/keep &&\n+\t\tinvert git show-ref -s --verify refs/heads/remove\n+\t)\n+\n+'\n+\n+test_expect_success '\"git push --all mirror\" fails and does not leave half updates' '\n+\n+\tmk_repo_three &&\n+\t(\n+\t\tcd master &&\n+\t\tgit branch b1 master &&\n+\t\tinvert git push --all mirror\n+\t) &&\n+\t(\n+\t\tcd mirror &&\n+\t\tinvert git show-ref -s --verify refs/heads/b1\n+\t)\n+\n+'\n+\n+test_expect_success 'mirrors are not updated by \"git push --repo\" or \"git push \"' '\n+\n+\tmk_repo_three &&\n+\t(\n+\t\tcd master &&\n+\t\tgit branch b1 master &&\n+\t\tgit push origin\n+\t\tgit branch b2 master &&\n+\t\tgit push --repo=origin\n+\t) &&\n+\t(\n+\t\tcd mirror &&\n+\t\tinvert git show-ref -s --verify refs/heads/b1 &&\n+\t\tinvert git show-ref -s --verify refs/heads/b2\n+\t) &&\n+\t(\n+\t\tcd origin &&\n+\t\tinvert git show-ref -s --verify refs/heads/b1 &&\n+\t\tinvert git show-ref -s --verify refs/heads/b2\n+\t)\n+\n+'\n+\n test_done\n-- \n1.5.5\n"},{"id":"75390","messageId":"b5b9b866e5f942d024831d528ae599e3e6ce31da.1209391615.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"d941a7a16cb7d5529b22a47f1dc7b986ba66ee56.1209391615.git.bonzini@gnu.org","subject":"[PATCH 5/7] don't rely on zero-argument \"git fetch\" from within git pull","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:16Z","receivedAt":"2008-04-28T15:32:16Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Since the series will change the meaning of zero-argument\n\"git fetch\", it is necessary that git pull does not rely on it.\nInstead, it resolves it using git-parse-remote, which will\nreturn either branch.*.remote or \"origin\" (at the end of the\nseries, the latter will throw out a big deprecation warning).\n\nSigned-off-by: Paolo Bonzini \n---\n git-pull.sh | 9 ++++++---\n 1 files changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex bf0c298..5dec4cf 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -106,10 +106,13 @@ error_on_no_merge_candidates () {\n \texit 1\n }\n \n+. git-parse-remote\n+if test $# = 0; then\n+\tset x $(get_default_remote); shift\n+fi\n+\n+origin=\"$1\"\n test true = \"$rebase\" && {\n-\t. git-parse-remote &&\n-\torigin=\"$1\"\n-\ttest -z \"$origin\" && origin=$(get_default_remote)\n \treflist=\"$(get_remote_refs_for_fetch \"$@\" 2>/dev/null |\n \t\tsed \"s|refs/heads/\\(.*\\):|\\1|\")\" &&\n \toldremoteref=\"$(git rev-parse --verify \\\n-- \n1.5.5\n"},{"id":"75389","messageId":"22f5914b1ffff814fa2387ff5cb762e0099aaa6b.1209391615.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"b5b9b866e5f942d024831d528ae599e3e6ce31da.1209391615.git.bonzini@gnu.org","subject":"[PATCH 6/7] warn on \"git pull\" without a given branch..remote value","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:17Z","receivedAt":"2008-04-28T15:32:17Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch deprecates the behavior of \"git pull\" without a\nbranch..remote value in the configuration. The value\n\"origin\" will be used, but a warning will be printed too.\n\nSigned-off-by: Paolo Bonzini \n---\n Documentation/git-pull.txt | 9 +++++----\n git-parse-remote.sh | 8 ++++++++\n 2 files changed, 13 insertions(+), 4 deletions(-)\n\n\tIn this case, I think we can warn because branch.*.remote\n\tlines are created by checkouts made with 1.5 or later.\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 3405ca0..18898f6 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -58,10 +58,11 @@ DEFAULT BEHAVIOUR\n -----------------\n \n Often people use `git pull` without giving any parameter.\n-Traditionally, this has been equivalent to saying `git pull\n-origin`. However, when configuration `branch..remote` is\n-present while on branch ``, that value is used instead of\n-`origin`.\n+While on branch ``, this will use the value of configuration\n+`branch..remote` as the branch to pull from. If the\n+value is not present, it will be implicitly considered to be\n+`origin`; however, this is deprecated and you consider\n+writing the value explicitly in the configuration file.\n \n In order to determine what URL to use to fetch from, the value\n of the configuration `remote..url` is consulted\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex 695a409..eddb593 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -54,9 +54,17 @@ get_remote_url () {\n \tesac\n }\n \n+warned_about_default_remote=no\n get_default_remote () {\n \tcurr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')\n \torigin=$(git config --get \"branch.$curr_branch.remote\")\n+\tif test -z \"$origin\" && test \"$warned_about_default_remote\" = no; then\n+\t echo \"warning: you asked me to pull without telling me which repository\"\n+\t echo \"warning: you want to pull from, and 'branch.${curr_branch}.remote'\"\n+\t echo \"warning: in your configuration file does not tell me either.\"\n+\t echo \"warning: proceeding with 'origin'.\"\n+\t\twarned_about_default_remote=yes\n+\tfi\n \techo ${origin:-origin}\n }\n \n-- \n1.5.5\n"},{"id":"75385","messageId":"55a4068681841e6c3579f4183b469fc7aa4de266.1209391615.git.bonzini@gnu.org","threadId":"13265","inReplyTo":"22f5914b1ffff814fa2387ff5cb762e0099aaa6b.1209391615.git.bonzini@gnu.org","subject":"[PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T15:32:18Z","receivedAt":"2008-04-28T15:32:18Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"This patch parallels what a previous patch did to \"git push\".\nIt makes \"git fetch\" with no repository argument similar to\n\"git remote update\" with no default group set. Of course,\n\"git fetch\" with no arguments honors skipDefaultUpdate too.\n\nThe patch also modifies the existing tests so that they do not execute\ngit-fetch without arguments. In the case of t5515, tests that executed\ngit-fetch without arguments are removed completely. A new test is\nadded to t5510 that tests the new operation mode.\n\nSigned-off-by: Paolo Bonzini \n---\n Documentation/git-fetch.txt | 7 ++\n builtin-fetch.c | 109 ++++++++++++++++-------------\n t/t5510-fetch.sh | 19 +++++-\n t/t5515-fetch-merge-logic.sh | 8 +--\n t/t5515/fetch.br-branches-default | 8 --\n t/t5515/fetch.br-branches-default-merge | 9 ---\n t/t5515/fetch.br-branches-default-octopus | 10 ---\n t/t5515/fetch.br-branches-one | 8 --\n t/t5515/fetch.br-branches-one-merge | 9 ---\n t/t5515/fetch.br-branches-one-octopus | 9 ---\n t/t5515/fetch.br-config-explicit | 11 ---\n t/t5515/fetch.br-config-explicit-merge | 11 ---\n t/t5515/fetch.br-config-explicit-octopus | 11 ---\n t/t5515/fetch.br-config-glob | 11 ---\n t/t5515/fetch.br-config-glob-merge | 11 ---\n t/t5515/fetch.br-config-glob-octopus | 11 ---\n t/t5515/fetch.br-remote-explicit | 11 ---\n t/t5515/fetch.br-remote-explicit-merge | 11 ---\n t/t5515/fetch.br-remote-explicit-octopus | 11 ---\n t/t5515/fetch.br-remote-glob | 11 ---\n t/t5515/fetch.br-remote-glob-merge | 11 ---\n t/t5515/fetch.br-remote-glob-octopus | 11 ---\n t/t5515/fetch.br-unconfig | 11 ---\n t/t5515/fetch.master | 11 ---\n t/t5515/refs.br-branches-default | 12 ---\n t/t5515/refs.br-branches-default-merge | 12 ---\n t/t5515/refs.br-branches-default-octopus | 12 ---\n t/t5515/refs.br-branches-one | 12 ---\n t/t5515/refs.br-branches-one-merge | 12 ---\n t/t5515/refs.br-branches-one-octopus | 12 ---\n t/t5515/refs.br-config-explicit | 15 ----\n t/t5515/refs.br-config-explicit-merge | 15 ----\n t/t5515/refs.br-config-explicit-octopus | 15 ----\n t/t5515/refs.br-config-glob | 15 ----\n t/t5515/refs.br-config-glob-merge | 15 ----\n t/t5515/refs.br-config-glob-octopus | 15 ----\n t/t5515/refs.br-remote-explicit | 15 ----\n t/t5515/refs.br-remote-explicit-merge | 15 ----\n t/t5515/refs.br-remote-explicit-octopus | 15 ----\n t/t5515/refs.br-remote-glob | 15 ----\n t/t5515/refs.br-remote-glob-merge | 15 ----\n t/t5515/refs.br-remote-glob-octopus | 15 ----\n t/t5515/refs.br-unconfig | 11 ---\n t/t5515/refs.master | 11 ---\n 44 files changed, 88 insertions(+), 536 deletions(-)\n delete mode 100644 t/t5515/fetch.br-branches-default\n delete mode 100644 t/t5515/fetch.br-branches-default-merge\n delete mode 100644 t/t5515/fetch.br-branches-default-octopus\n delete mode 100644 t/t5515/fetch.br-branches-one\n delete mode 100644 t/t5515/fetch.br-branches-one-merge\n delete mode 100644 t/t5515/fetch.br-branches-one-octopus\n delete mode 100644 t/t5515/fetch.br-config-explicit\n delete mode 100644 t/t5515/fetch.br-config-explicit-merge\n delete mode 100644 t/t5515/fetch.br-config-explicit-octopus\n delete mode 100644 t/t5515/fetch.br-config-glob\n delete mode 100644 t/t5515/fetch.br-config-glob-merge\n delete mode 100644 t/t5515/fetch.br-config-glob-octopus\n delete mode 100644 t/t5515/fetch.br-remote-explicit\n delete mode 100644 t/t5515/fetch.br-remote-explicit-merge\n delete mode 100644 t/t5515/fetch.br-remote-explicit-octopus\n delete mode 100644 t/t5515/fetch.br-remote-glob\n delete mode 100644 t/t5515/fetch.br-remote-glob-merge\n delete mode 100644 t/t5515/fetch.br-remote-glob-octopus\n delete mode 100644 t/t5515/fetch.br-unconfig\n delete mode 100644 t/t5515/fetch.master\n delete mode 100644 t/t5515/refs.br-branches-default\n delete mode 100644 t/t5515/refs.br-branches-default-merge\n delete mode 100644 t/t5515/refs.br-branches-default-octopus\n delete mode 100644 t/t5515/refs.br-branches-one\n delete mode 100644 t/t5515/refs.br-branches-one-merge\n delete mode 100644 t/t5515/refs.br-branches-one-octopus\n delete mode 100644 t/t5515/refs.br-config-explicit\n delete mode 100644 t/t5515/refs.br-config-explicit-merge\n delete mode 100644 t/t5515/refs.br-config-explicit-octopus\n delete mode 100644 t/t5515/refs.br-config-glob\n delete mode 100644 t/t5515/refs.br-config-glob-merge\n delete mode 100644 t/t5515/refs.br-config-glob-octopus\n delete mode 100644 t/t5515/refs.br-remote-explicit\n delete mode 100644 t/t5515/refs.br-remote-explicit-merge\n delete mode 100644 t/t5515/refs.br-remote-explicit-octopus\n delete mode 100644 t/t5515/refs.br-remote-glob\n delete mode 100644 t/t5515/refs.br-remote-glob-merge\n delete mode 100644 t/t5515/refs.br-remote-glob-octopus\n delete mode 100644 t/t5515/refs.br-unconfig\n delete mode 100644 t/t5515/refs.master\n\n\tThe patch is a little more complicated than necessary because\n\tsome global variables were shadowed by locals. That's a useful\n\tcleanup of its own.\n\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex d982f96..f212d89 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -31,6 +31,13 @@ branches you are not interested in, you will not get them.\n \n OPTIONS\n -------\n+::\n+ The \"remote\" repository whose updates are to be\n+\tfetched. If no repository is specified, all remotes\n+\twhich do not have the configuration parameter\n+\tremote..skipDefaultUpdate set to true will\n+\tbe updated. (See linkgit:git-config[1])\n+\n include::fetch-options.txt[]\n \n include::pull-fetch-param.txt[]\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex e4486e4..d4aaf67 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -23,11 +23,13 @@ enum {\n };\n \n static int append, force, keep, update_head_ok, verbose, quiet;\n-static int tags = TAGS_DEFAULT;\n+static int fetch_tags = TAGS_DEFAULT;\n static const char *depth;\n static const char *upload_pack;\n static struct strbuf default_rla = STRBUF_INIT;\n static struct transport *transport;\n+static struct refspec *refs;\n+static int ref_count = 0;\n \n static struct option builtin_fetch_options[] = {\n \tOPT__QUIET(&quiet),\n@@ -38,9 +40,9 @@ static struct option builtin_fetch_options[] = {\n \t\t \"path to upload pack on remote end\"),\n \tOPT_BOOLEAN('f', \"force\", &force,\n \t\t \"force overwrite of local branch\"),\n-\tOPT_SET_INT('t', \"tags\", &tags,\n+\tOPT_SET_INT('t', \"tags\", &fetch_tags,\n \t\t \"fetch all tags and associated objects\", TAGS_SET),\n-\tOPT_SET_INT('n', NULL, &tags,\n+\tOPT_SET_INT('n', NULL, &fetch_tags,\n \t\t \"do not fetch all tags (--no-tags)\", TAGS_UNSET),\n \tOPT_BOOLEAN('k', \"keep\", &keep, \"keep downloaded pack\"),\n \tOPT_BOOLEAN('u', \"update-head-ok\", &update_head_ok,\n@@ -523,15 +525,44 @@ static void find_non_local_tags(struct transport *transport,\n \tpath_list_clear(&new_refs, 0);\n }\n \n-static int do_fetch(struct transport *transport,\n-\t\t struct refspec *refs, int ref_count)\n+static void set_option(const char *name, const char *value)\n+{\n+\tint r = transport_set_option(transport, name, value);\n+\tif (r < 0)\n+\t\tdie(\"Option \\\"%s\\\" value \\\"%s\\\" is not valid for %s\\n\",\n+\t\t\tname, value, transport->url);\n+\tif (r > 0)\n+\t\twarning(\"Option \\\"%s\\\" is ignored for %s\\n\",\n+\t\t\tname, transport->url);\n+}\n+\n+\n+static int do_fetch(struct remote *remote)\n {\n \tstruct ref *ref_map;\n \tstruct ref *rm;\n-\tint autotags = (transport->remote->fetch_tags == 1);\n-\tif (transport->remote->fetch_tags == 2 && tags != TAGS_UNSET)\n+\tint autotags = (remote->fetch_tags == 1);\n+\tint tags = fetch_tags;\n+\n+\tif (!remote->url_nr)\n+\t\tdie(\"Where do you want to fetch from today?\");\n+\n+\ttransport = transport_get(remote, remote->url[0]);\n+\tassert (transport->url);\n+\tif (verbose >= 2)\n+\t\ttransport->verbose = 1;\n+\tif (quiet)\n+\t\ttransport->verbose = -1;\n+\tif (upload_pack)\n+\t\tset_option(TRANS_OPT_UPLOADPACK, upload_pack);\n+\tif (keep)\n+\t\tset_option(TRANS_OPT_KEEP, \"yes\");\n+\tif (depth)\n+\t\tset_option(TRANS_OPT_DEPTH, depth);\n+\n+\tif (remote->fetch_tags == 2 && tags != TAGS_UNSET)\n \t\ttags = TAGS_SET;\n-\tif (transport->remote->fetch_tags == -1)\n+\tif (remote->fetch_tags == -1)\n \t\ttags = TAGS_UNSET;\n \n \tif (!transport->get_refs_list || !transport->fetch)\n@@ -544,6 +575,7 @@ static int do_fetch(struct transport *transport,\n \t\tif (!fp)\n \t\t\treturn error(\"cannot open %s: %s\\n\", filename, strerror(errno));\n \t\tfclose(fp);\n+\t\tappend = 1;\n \t}\n \n \tref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);\n@@ -557,7 +589,7 @@ static int do_fetch(struct transport *transport,\n \t\ttransport_set_option(transport, TRANS_OPT_FOLLOWTAGS, \"1\");\n \tif (fetch_refs(transport, ref_map)) {\n \t\tfree_refs(ref_map);\n-\t\treturn 1;\n+\t\tgoto error;\n \t}\n \tfree_refs(ref_map);\n \n@@ -576,27 +608,26 @@ static int do_fetch(struct transport *transport,\n \t}\n \n \ttransport_disconnect(transport);\n-\n \treturn 0;\n+\n+error:\n+\tunlock_pack ();\n+\treturn 1;\n }\n \n-static void set_option(const char *name, const char *value)\n+static int fetch_one_remote(struct remote *remote, void *unused)\n {\n-\tint r = transport_set_option(transport, name, value);\n-\tif (r < 0)\n-\t\tdie(\"Option \\\"%s\\\" value \\\"%s\\\" is not valid for %s\\n\",\n-\t\t\tname, value, transport->url);\n-\tif (r > 0)\n-\t\twarning(\"Option \\\"%s\\\" is ignored for %s\\n\",\n-\t\t\tname, transport->url);\n+\tif (remote->skip_default_update || !remote->url_nr)\n+\t\treturn 0;\n+\n+\tdo_fetch (remote);\n }\n \n int cmd_fetch(int argc, const char **argv, const char *prefix)\n {\n \tstruct remote *remote;\n \tint i;\n-\tstatic const char **refs = NULL;\n-\tint ref_nr = 0;\n+\tstatic const char **arg_refs = NULL;\n \n \t/* Record the command line for the reflog */\n \tstrbuf_addstr(&default_rla, \"fetch\");\n@@ -606,29 +637,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)\n \targc = parse_options(argc, argv,\n \t\t\t builtin_fetch_options, builtin_fetch_usage, 0);\n \n-\tif (argc == 0)\n-\t\tremote = remote_get(NULL);\n-\telse\n-\t\tremote = remote_get(argv[0]);\n-\n-\ttransport = transport_get(remote, remote->url[0]);\n-\tif (verbose >= 2)\n-\t\ttransport->verbose = 1;\n-\tif (quiet)\n-\t\ttransport->verbose = -1;\n-\tif (upload_pack)\n-\t\tset_option(TRANS_OPT_UPLOADPACK, upload_pack);\n-\tif (keep)\n-\t\tset_option(TRANS_OPT_KEEP, \"yes\");\n-\tif (depth)\n-\t\tset_option(TRANS_OPT_DEPTH, depth);\n-\n-\tif (!transport->url)\n-\t\tdie(\"Where do you want to fetch from today?\");\n-\n \tif (argc > 1) {\n \t\tint j = 0;\n-\t\trefs = xcalloc(argc + 1, sizeof(const char *));\n+\t\targ_refs = xcalloc(argc + 1, sizeof(const char *));\n \t\tfor (i = 1; i < argc; i++) {\n \t\t\tif (!strcmp(argv[i], \"tag\")) {\n \t\t\t\tchar *ref;\n@@ -640,16 +651,18 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)\n \t\t\t\tstrcat(ref, argv[i]);\n \t\t\t\tstrcat(ref, \":refs/tags/\");\n \t\t\t\tstrcat(ref, argv[i]);\n-\t\t\t\trefs[j++] = ref;\n+\t\t\t\targ_refs[j++] = ref;\n \t\t\t} else\n-\t\t\t\trefs[j++] = argv[i];\n+\t\t\t\targ_refs[j++] = argv[i];\n \t\t}\n-\t\trefs[j] = NULL;\n-\t\tref_nr = j;\n+\t\targ_refs[j] = NULL;\n+\t\tref_count = j;\n \t}\n+\trefs = parse_fetch_refspec(ref_count, arg_refs);\n \n \tsignal(SIGINT, unlock_pack_on_signal);\n-\tatexit(unlock_pack);\n-\treturn do_fetch(transport,\n-\t\t\tparse_fetch_refspec(ref_nr, refs), ref_nr);\n+\tif (argc == 0)\n+\t\treturn for_each_remote (fetch_one_remote, NULL);\n+\telse\n+\t\treturn do_fetch (remote_get(argv[0]));\n }\ndiff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh\nindex 6946557..28da6bd 100755\n--- a/t/t5510-fetch.sh\n+++ b/t/t5510-fetch.sh\n@@ -45,7 +45,7 @@ test_expect_success \"fetch test\" '\n \techo >file updated by origin &&\n \tgit commit -a -m \"updated by origin\" &&\n \tcd two &&\n-\tgit fetch &&\n+\tgit fetch one &&\n \ttest -f .git/refs/heads/one &&\n \tmine=`git rev-parse refs/heads/one` &&\n \this=`cd ../one && git rev-parse refs/heads/master` &&\n@@ -55,12 +55,29 @@ test_expect_success \"fetch test\" '\n test_expect_success \"fetch test for-merge\" '\n \tcd \"$D\" &&\n \tcd three &&\n+\tgit fetch two &&\n+\ttest -f .git/refs/heads/two &&\n+\ttest -f .git/refs/heads/one &&\n+\tmaster_in_two=`cd ../two && git rev-parse master` &&\n+\tone_in_two=`cd ../two && git rev-parse one` &&\n+\t{\n+\t\techo \"$master_in_two\tnot-for-merge\"\n+\t\techo \"$one_in_two\t\"\n+\t} >expected &&\n+\tcut -f -2 .git/FETCH_HEAD >actual &&\n+\tdiff expected actual'\n+\n+test_expect_success \"fetch all remotes\" '\n+\tcd \"$D\" &&\n+\tcd three &&\n \tgit fetch &&\n \ttest -f .git/refs/heads/two &&\n \ttest -f .git/refs/heads/one &&\n+\tmaster_in_origin=`cd .. && git rev-parse master` &&\n \tmaster_in_two=`cd ../two && git rev-parse master` &&\n \tone_in_two=`cd ../two && git rev-parse one` &&\n \t{\n+\t\techo \"$master_in_origin\tnot-for-merge\"\n \t\techo \"$master_in_two\tnot-for-merge\"\n \t\techo \"$one_in_two\t\"\n \t} >expected &&\ndiff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh\nindex 65c3774..8568b4b 100755\n--- a/t/t5515-fetch-merge-logic.sh\n+++ b/t/t5515-fetch-merge-logic.sh\n@@ -91,10 +91,7 @@ test_expect_success setup '\n # Merge logic depends on branch properties and Pull: or .fetch lines\n for remote in $remotes ; do\n for branch in \"\" \"-merge\" \"-octopus\" ; do\n-cat < tests\n \n@@ -103,7 +100,6 @@ done > tests\n # Use two branches completely unrelated from the arguments,\n # the clone default and one without branch properties\n for branch in master br-unconfig ; do\n- echo $branch\n for remote in $remotes ; do\n \techo $branch $remote\n done\n@@ -140,7 +136,7 @@ do\n \t\t{\n \t\t\techo \"# $cmd\"\n \t\t\tset x $cmd; shift\n-\t\t\tgit symbolic-ref HEAD refs/heads/$1 ; shift\n+\t\t\tgit symbolic-ref HEAD refs/heads/$1; shift\n \t\t\trm -f .git/FETCH_HEAD\n \t\t\trm -f .git/refs/heads/*\n \t\t\trm -f .git/refs/remotes/rem/*\ndiff --git a/t/t5515/fetch.br-branches-default b/t/t5515/fetch.br-branches-default\ndeleted file mode 100644\nindex 2e0414f..0000000\n--- a/t/t5515/fetch.br-branches-default\n+++ /dev/null\n@@ -1,8 +0,0 @@\n-# br-branches-default\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\tbranch 'master' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-branches-default-merge b/t/t5515/fetch.br-branches-default-merge\ndeleted file mode 100644\nindex ca2cc1d..0000000\n--- a/t/t5515/fetch.br-branches-default-merge\n+++ /dev/null\n@@ -1,9 +0,0 @@\n-# br-branches-default-merge\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\t\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-branches-default-octopus b/t/t5515/fetch.br-branches-default-octopus\ndeleted file mode 100644\nindex ec39c54..0000000\n--- a/t/t5515/fetch.br-branches-default-octopus\n+++ /dev/null\n@@ -1,10 +0,0 @@\n-# br-branches-default-octopus\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-branches-one b/t/t5515/fetch.br-branches-one\ndeleted file mode 100644\nindex 12ac8d2..0000000\n--- a/t/t5515/fetch.br-branches-one\n+++ /dev/null\n@@ -1,8 +0,0 @@\n-# br-branches-one\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-branches-one-merge b/t/t5515/fetch.br-branches-one-merge\ndeleted file mode 100644\nindex b4b3b35..0000000\n--- a/t/t5515/fetch.br-branches-one-merge\n+++ /dev/null\n@@ -1,9 +0,0 @@\n-# br-branches-one-merge\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\t\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-branches-one-octopus b/t/t5515/fetch.br-branches-one-octopus\ndeleted file mode 100644\nindex 96e3029..0000000\n--- a/t/t5515/fetch.br-branches-one-octopus\n+++ /dev/null\n@@ -1,9 +0,0 @@\n-# br-branches-one-octopus\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-config-explicit b/t/t5515/fetch.br-config-explicit\ndeleted file mode 100644\nindex e2fa9c8..0000000\n--- a/t/t5515/fetch.br-config-explicit\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-config-explicit\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-config-explicit-merge b/t/t5515/fetch.br-config-explicit-merge\ndeleted file mode 100644\nindex ec1a723..0000000\n--- a/t/t5515/fetch.br-config-explicit-merge\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-config-explicit-merge\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\t\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-config-explicit-octopus b/t/t5515/fetch.br-config-explicit-octopus\ndeleted file mode 100644\nindex 7011dfc..0000000\n--- a/t/t5515/fetch.br-config-explicit-octopus\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-config-explicit-octopus\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\tbranch 'two' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-config-glob b/t/t5515/fetch.br-config-glob\ndeleted file mode 100644\nindex e75ec2f..0000000\n--- a/t/t5515/fetch.br-config-glob\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-config-glob\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-config-glob-merge b/t/t5515/fetch.br-config-glob-merge\ndeleted file mode 100644\nindex ce8f739..0000000\n--- a/t/t5515/fetch.br-config-glob-merge\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-config-glob-merge\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\t\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-config-glob-octopus b/t/t5515/fetch.br-config-glob-octopus\ndeleted file mode 100644\nindex 938e532..0000000\n--- a/t/t5515/fetch.br-config-glob-octopus\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-config-glob-octopus\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-remote-explicit b/t/t5515/fetch.br-remote-explicit\ndeleted file mode 100644\nindex 83534d2..0000000\n--- a/t/t5515/fetch.br-remote-explicit\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-remote-explicit\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\t\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-remote-explicit-merge b/t/t5515/fetch.br-remote-explicit-merge\ndeleted file mode 100644\nindex a9064dd..0000000\n--- a/t/t5515/fetch.br-remote-explicit-merge\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-remote-explicit-merge\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\t\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-remote-explicit-octopus b/t/t5515/fetch.br-remote-explicit-octopus\ndeleted file mode 100644\nindex ecf020d..0000000\n--- a/t/t5515/fetch.br-remote-explicit-octopus\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-remote-explicit-octopus\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\tbranch 'two' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-remote-glob b/t/t5515/fetch.br-remote-glob\ndeleted file mode 100644\nindex 94e6ad3..0000000\n--- a/t/t5515/fetch.br-remote-glob\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-remote-glob\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-remote-glob-merge b/t/t5515/fetch.br-remote-glob-merge\ndeleted file mode 100644\nindex 09362e2..0000000\n--- a/t/t5515/fetch.br-remote-glob-merge\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-remote-glob-merge\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\t\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-remote-glob-octopus b/t/t5515/fetch.br-remote-glob-octopus\ndeleted file mode 100644\nindex b08e046..0000000\n--- a/t/t5515/fetch.br-remote-glob-octopus\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-remote-glob-octopus\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\t\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\t\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.br-unconfig b/t/t5515/fetch.br-unconfig\ndeleted file mode 100644\nindex 65ce6d9..0000000\n--- a/t/t5515/fetch.br-unconfig\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# br-unconfig\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/fetch.master b/t/t5515/fetch.master\ndeleted file mode 100644\nindex 950fd07..0000000\n--- a/t/t5515/fetch.master\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-# master\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\tbranch 'master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\tbranch 'one' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\tbranch 'three' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\tbranch 'two' of ../\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f\tnot-for-merge\ttag 'tag-master' of ../\n-8e32a6d901327a23ef831511badce7bf3bf46689\tnot-for-merge\ttag 'tag-one' of ../\n-22feea448b023a2d864ef94b013735af34d238ba\tnot-for-merge\ttag 'tag-one-tree' of ../\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b\tnot-for-merge\ttag 'tag-three' of ../\n-0e3b14047d3ee365f4f2a1b673db059c3972589c\tnot-for-merge\ttag 'tag-three-file' of ../\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8\tnot-for-merge\ttag 'tag-two' of ../\ndiff --git a/t/t5515/refs.br-branches-default b/t/t5515/refs.br-branches-default\ndeleted file mode 100644\nindex 21917c1..0000000\n--- a/t/t5515/refs.br-branches-default\n+++ /dev/null\n@@ -1,12 +0,0 @@\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/heads/branches-default\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-branches-default-merge b/t/t5515/refs.br-branches-default-merge\ndeleted file mode 100644\nindex 21917c1..0000000\n--- a/t/t5515/refs.br-branches-default-merge\n+++ /dev/null\n@@ -1,12 +0,0 @@\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/heads/branches-default\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-branches-default-octopus b/t/t5515/refs.br-branches-default-octopus\ndeleted file mode 100644\nindex 21917c1..0000000\n--- a/t/t5515/refs.br-branches-default-octopus\n+++ /dev/null\n@@ -1,12 +0,0 @@\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/heads/branches-default\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-branches-one b/t/t5515/refs.br-branches-one\ndeleted file mode 100644\nindex 8a705a5..0000000\n--- a/t/t5515/refs.br-branches-one\n+++ /dev/null\n@@ -1,12 +0,0 @@\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/heads/branches-one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-branches-one-merge b/t/t5515/refs.br-branches-one-merge\ndeleted file mode 100644\nindex 8a705a5..0000000\n--- a/t/t5515/refs.br-branches-one-merge\n+++ /dev/null\n@@ -1,12 +0,0 @@\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/heads/branches-one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-branches-one-octopus b/t/t5515/refs.br-branches-one-octopus\ndeleted file mode 100644\nindex 8a705a5..0000000\n--- a/t/t5515/refs.br-branches-one-octopus\n+++ /dev/null\n@@ -1,12 +0,0 @@\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/heads/branches-one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-config-explicit b/t/t5515/refs.br-config-explicit\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-config-explicit\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-config-explicit-merge b/t/t5515/refs.br-config-explicit-merge\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-config-explicit-merge\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-config-explicit-octopus b/t/t5515/refs.br-config-explicit-octopus\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-config-explicit-octopus\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-config-glob b/t/t5515/refs.br-config-glob\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-config-glob\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-config-glob-merge b/t/t5515/refs.br-config-glob-merge\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-config-glob-merge\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-config-glob-octopus b/t/t5515/refs.br-config-glob-octopus\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-config-glob-octopus\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-remote-explicit b/t/t5515/refs.br-remote-explicit\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-remote-explicit\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-remote-explicit-merge b/t/t5515/refs.br-remote-explicit-merge\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-remote-explicit-merge\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-remote-explicit-octopus b/t/t5515/refs.br-remote-explicit-octopus\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-remote-explicit-octopus\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-remote-glob b/t/t5515/refs.br-remote-glob\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-remote-glob\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-remote-glob-merge b/t/t5515/refs.br-remote-glob-merge\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-remote-glob-merge\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-remote-glob-octopus b/t/t5515/refs.br-remote-glob-octopus\ndeleted file mode 100644\nindex 9bbbfd9..0000000\n--- a/t/t5515/refs.br-remote-glob-octopus\n+++ /dev/null\n@@ -1,15 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/rem/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/rem/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/rem/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/rem/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.br-unconfig b/t/t5515/refs.br-unconfig\ndeleted file mode 100644\nindex 13e4ad2..0000000\n--- a/t/t5515/refs.br-unconfig\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\ndiff --git a/t/t5515/refs.master b/t/t5515/refs.master\ndeleted file mode 100644\nindex 13e4ad2..0000000\n--- a/t/t5515/refs.master\n+++ /dev/null\n@@ -1,11 +0,0 @@\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/HEAD\n-754b754407bf032e9a2f9d5a9ad05ca79a6b228f refs/remotes/origin/master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/remotes/origin/one\n-0567da4d5edd2ff4bb292a465ba9e64dcad9536b refs/remotes/origin/three\n-6134ee8f857693b96ff1cc98d3e2fd62b199e5a8 refs/remotes/origin/two\n-6c9dec2b923228c9ff994c6cfe4ae16c12408dc5 refs/tags/tag-master\n-8e32a6d901327a23ef831511badce7bf3bf46689 refs/tags/tag-one\n-22feea448b023a2d864ef94b013735af34d238ba refs/tags/tag-one-tree\n-c61a82b60967180544e3c19f819ddbd0c9f89899 refs/tags/tag-three\n-0e3b14047d3ee365f4f2a1b673db059c3972589c refs/tags/tag-three-file\n-525b7fb068d59950d185a8779dc957c77eed73ba refs/tags/tag-two\n-- \n1.5.5\n"},{"id":"75419","messageId":"20080428181012.GB6710@steel.home","threadId":"13265","inReplyTo":"55a4068681841e6c3579f4183b469fc7aa4de266.1209391615.git.bonzini@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-28T18:10:12Z","receivedAt":"2008-04-28T18:10:12Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Mon, Apr 28, 2008 17:32:18 +0200:\n> This patch parallels what a previous patch did to \"git push\".\n> It makes \"git fetch\" with no repository argument similar to\n> \"git remote update\" with no default group set. Of course,\n> \"git fetch\" with no arguments honors skipDefaultUpdate too.\n\nYou may consider to update \"git remote add\" to make all new remotes\n.skipDefaultUpdate. And otherwise, I promise to hate your patch\neverytime when I mindlessly type \"git fetch\" in, for instance, my v4l2\nrepo (which is a pretty collection of all kinds of remotes). All of\nsudden it starts updating them and losing old references. And that\nwithout me even touching configuration.\n\nPlease, consider making this behaviour non-default. Just because the\nall current repos suddenly start updating itself where they didn't\nbefore. Same goes for you \"git push\" patch.\n"},{"id":"75427","messageId":"48161544.90500@gnu.org","threadId":"13265","inReplyTo":"20080428181012.GB6710@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T18:19:48Z","receivedAt":"2008-04-28T18:19:48Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> my v4l2\n> repo (which is a pretty collection of all kinds of remotes)\n\nI can add a global boolean configuration to change the default value of \nskipDefaultRemote.\n\nPaolo\n"},{"id":"75466","messageId":"20080428213339.GC10600@steel.home","threadId":"13265","inReplyTo":"48161544.90500@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-28T21:33:39Z","receivedAt":"2008-04-28T21:33:39Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:\n>> my v4l2\n>> repo (which is a pretty collection of all kinds of remotes)\n>\n> I can add a global boolean configuration to change the default value of \n> skipDefaultRemote.\n>\n\nWith the default NOT so that current behaviour stays?\nAnd \"git remote add\" update?\n"},{"id":"75488","messageId":"4816A989.2010204@gnu.org","threadId":"13265","inReplyTo":"20080428213339.GC10600@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T04:52:25Z","receivedAt":"2008-04-29T04:52:25Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Alex Riesen wrote:\n> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:\n>>> my v4l2\n>>> repo (which is a pretty collection of all kinds of remotes)\n>> I can add a global boolean configuration to change the default value of \n>> skipDefaultRemote.\n>>\n> \n> With the default NOT so that current behaviour stays?\n\nNo, absolutely. In fact if I were you I would set skipDefaultUpdate \n*now* on the remotes of that repo.\n\nPaolo\n"},{"id":"75491","messageId":"20080429053814.GA3332@steel.home","threadId":"13265","inReplyTo":"4816A989.2010204@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T05:38:14Z","receivedAt":"2008-04-29T05:38:14Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:\n> Alex Riesen wrote:\n>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:\n>>>> my v4l2\n>>>> repo (which is a pretty collection of all kinds of remotes)\n>>> I can add a global boolean configuration to change the default value \n>>> of skipDefaultRemote.\n>>>\n>>\n>> With the default NOT so that current behaviour stays?\n>\n> No, absolutely. In fact if I were you I would set skipDefaultUpdate \n> *now* on the remotes of that repo.\n\nAnd all the others, who don't read this discussion, are just expected\nto adapt?\n"},{"id":"75492","messageId":"4816BAB1.7080601@op5.se","threadId":"13265","inReplyTo":"20080429053814.GA3332@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-04-29T06:05:37Z","receivedAt":"2008-04-29T06:05:37Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n> Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:\n>> Alex Riesen wrote:\n>>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:\n>>>>> my v4l2\n>>>>> repo (which is a pretty collection of all kinds of remotes)\n>>>> I can add a global boolean configuration to change the default value \n>>>> of skipDefaultRemote.\n>>>>\n>>> With the default NOT so that current behaviour stays?\n>> No, absolutely. In fact if I were you I would set skipDefaultUpdate \n>> *now* on the remotes of that repo.\n> \n> And all the others, who don't read this discussion, are just expected\n> to adapt?\n> \n\nOne for Alex's side here. I have several remotes in many of the repos\nI'm using. Some of them point to my colleagues laptops, where temporary\ngit-daemons sometimes serve content, and sometimes it doesn't.\n\nFor me no refs would be updated, but they would generate errors which\nwould make real errors harder to see.\n\nIf you're gonna change the default of something, make really sure it\ndoesn't ever destroy anything for anybody. Otherwise, make it configurable\nand off by default.\n\nHow about renaming \"skipDefaultUpdate\" to \"fetch.fetchAllRemotes\" and\nlet it default to false?\n\nAlthough when I come to think about it, you'd probably want to mark\nsome remotes for auto-fetching while keeping others on \"manual\" fetch.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"75497","messageId":"4816C527.4000406@gnu.org","threadId":"13265","inReplyTo":"20080429053814.GA3332@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T06:50:15Z","receivedAt":"2008-04-29T06:50:15Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Alex Riesen wrote:\n> Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:\n>> Alex Riesen wrote:\n>>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:\n>>>>> my v4l2\n>>>>> repo (which is a pretty collection of all kinds of remotes)\n>>>> I can add a global boolean configuration to change the default value \n>>>> of skipDefaultRemote.\n>>>>\n>>> With the default NOT so that current behaviour stays?\n>> No, absolutely. In fact if I were you I would set skipDefaultUpdate \n>> *now* on the remotes of that repo.\n> \n> And all the others, who don't read this discussion, are just expected\n> to adapt?\n\nMan, that's what release notes are for. You are expected to read those.\n\nPaolo\n"},{"id":"75498","messageId":"4816C67E.8010600@gnu.org","threadId":"13265","inReplyTo":"4816BAB1.7080601@op5.se","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T06:55:58Z","receivedAt":"2008-04-29T06:55:58Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> Some of them point to my colleagues laptops, where temporary\n> git-daemons sometimes serve content, and sometimes it doesn't.\n\nAgain, you should probably have skipDefaultUpdate set on those remotes \neven now! A patch that makes a \"wrong\" (or incomplete) configuration \nmore apparent, is not necessarily wrong in itself. (I was sort of \nexpecting these objections -- the patches are designed to make the \ncommon use cases easier, and of course on this list you will find \nexperts with less common scenarios).\n\nIn case it was not clear: it's not like the fetch command will *always* \nupdate all repositories. Only the zero-argument variation will.\n\n> How about renaming \"skipDefaultUpdate\" to \"fetch.fetchAllRemotes\" and\n> let it default to false?\n\nRenaming can be done (as a followup preferably, the patch series touches \nenough places like this). But not setting the default, as that would \ndestroy the \"base case\" where \"git fetch\" just fetches from origin.\n\nPaolo\n"},{"id":"75506","messageId":"4816CB46.1050100@op5.se","threadId":"13265","inReplyTo":"4816C527.4000406@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-04-29T07:16:22Z","receivedAt":"2008-04-29T07:16:22Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Paolo Bonzini wrote:\n> Alex Riesen wrote:\n>> Paolo Bonzini, Tue, Apr 29, 2008 06:52:25 +0200:\n>>> Alex Riesen wrote:\n>>>> Paolo Bonzini, Mon, Apr 28, 2008 20:19:48 +0200:\n>>>>>> my v4l2\n>>>>>> repo (which is a pretty collection of all kinds of remotes)\n>>>>> I can add a global boolean configuration to change the default \n>>>>> value of skipDefaultRemote.\n>>>>>\n>>>> With the default NOT so that current behaviour stays?\n>>> No, absolutely. In fact if I were you I would set skipDefaultUpdate \n>>> *now* on the remotes of that repo.\n>>\n>> And all the others, who don't read this discussion, are just expected\n>> to adapt?\n> \n> Man, that's what release notes are for. You are expected to read those.\n> \n\nSo you actually read the release-notes for every application you have\ninstalled? Remind me to never employ you. I doubt you'd ever get any\nwork done.\n\nFailing that, would you get slightly annoyed, or perhaps even quite\nvexed if you find out that insert-program-used-to-do-some-work-with-here\ndid omething stupid that made you lose some of your work?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"75510","messageId":"4816D505.1000208@gnu.org","threadId":"13265","inReplyTo":"4816CB46.1050100@op5.se","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T07:57:57Z","receivedAt":"2008-04-29T07:57:57Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> Man, that's what release notes are for. You are expected to read those.\n> \n> So you actually read the release-notes for every application you have\n> installed?\n\nNot for every one, but I do for some applications. Right now only git \nand autoconf come to mind. Especially searching for the magic words \n\"backwards incompatible\" -- the more \"power user\" you are of an \napplication, the more you should read the release notes. And in the \ncase of git I don't consider myself a power user but I learnt quite a \nfew tricks from the release notes.\n\n> Remind me to never employ you. I doubt you'd ever get any\n> work done.\n\nWell, the same should apply to reading mailing lists...\n\n> Failing that, would you get slightly annoyed, or perhaps even quite\n> vexed if you find out that insert-program-used-to-do-some-work-with-here\n> did omething stupid that made you lose some of your work?\n\nSorry, how does the patch make you lose some of your work (as opposed to \nsome of your time, which is possible as is the case for every backwards \nincompatible change)?\n\n1) what about the reflog?\n\n2) the patch does not touch refs/heads/* unless you are tweaking your \nconfiguration (and quite heavily so). IMHO that's using enough rope \nthat you really ought to know about the reflog and... look for backwards \nincompatible changes in the release notes!\n\n3) your complaint was that it gave errors. Alex did talk about losing \nhis work, but questions 1 and 2 would apply to him too.\n\n4) one man's stupidity is another man's... [fill in] In particular, did \nyou understand the rationale for this change? Do you have any \nalternative ideas?\n\nPaolo\n"},{"id":"75513","messageId":"4816E0F6.3030302@op5.se","threadId":"13265","inReplyTo":"4816D505.1000208@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-04-29T08:48:54Z","receivedAt":"2008-04-29T08:48:54Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Paolo Bonzini wrote:\n> \n>>> Man, that's what release notes are for. You are expected to read those.\n>>\n>> So you actually read the release-notes for every application you have\n>> installed?\n> \n> Not for every one, but I do for some applications. Right now only git \n> and autoconf come to mind. Especially searching for the magic words \n> \"backwards incompatible\" -- the more \"power user\" you are of an \n> application, the more you should read the release notes. And in the \n> case of git I don't consider myself a power user but I learnt quite a \n> few tricks from the release notes.\n> \n>> Remind me to never employ you. I doubt you'd ever get any\n>> work done.\n> \n> Well, the same should apply to reading mailing lists...\n> \n>> Failing that, would you get slightly annoyed, or perhaps even quite\n>> vexed if you find out that insert-program-used-to-do-some-work-with-here\n>> did omething stupid that made you lose some of your work?\n> \n> Sorry, how does the patch make you lose some of your work (as opposed to \n> some of your time, which is possible as is the case for every backwards \n> incompatible change)?\n> \n\nBecause I will lose some of the refs and then have to dig them up in the\nreflog.\n\n> 1) what about the reflog?\n> \n\nI'm not comfortable with the reflog. I appreciate its usefulness, but I'm\nthoroughly unhappy when I'm forced to use it.\n\n> 2) the patch does not touch refs/heads/* unless you are tweaking your \n> configuration (and quite heavily so). IMHO that's using enough rope \n> that you really ought to know about the reflog and... look for backwards \n> incompatible changes in the release notes!\n> \n\nNo, but it does touch refs/remotes/*/heads\n\n> 3) your complaint was that it gave errors. Alex did talk about losing \n> his work, but questions 1 and 2 would apply to him too.\n> \n> 4) one man's stupidity is another man's... [fill in] In particular, did \n> you understand the rationale for this change? Do you have any \n> alternative ideas?\n> \n\nYes, I understand the rationale, and I do have an alternative idea, which\nis to make it configurable. Now that I think about it, it's probably useful\nto have it togglable via command-line switch as well. Something along the\nlines of \"git fetch --all-remotes\", perhaps. I'm not against the idea as\nsuch. I'm against making it the default.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"75515","messageId":"4816E40A.4020700@gnu.org","threadId":"13265","inReplyTo":"4816E0F6.3030302@op5.se","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T09:02:02Z","receivedAt":"2008-04-29T09:02:02Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> Sorry, how does the patch make you lose some of your work (as opposed \n>> to some of your time, which is possible as is the case for every \n>> backwards incompatible change)?\n> \n> Because I will lose some of the refs and then have to dig them up in the\n> reflog.\n> \n> I'm not comfortable with the reflog. I appreciate its usefulness, but I'm\n> thoroughly unhappy when I'm forced to use it.\n\nSo am I, but still it would lose time (to dig refs up in the reflog), \nnot work (e.g. having to rewrite code). I think we're in agreement on \nthis part.\n\n> Yes, I understand the rationale, and I do have an alternative idea, which\n> is to make it configurable.\n\nThen sorry, but I think you don't understand the rationale. The cover \nletter has excerpts from other git hackers' e-mails that explain it \nbetter than I can. But shortly speaking, the point of the patch is to \nremove the \"magic\" operation of \"git fetch\" as \"git fetch origin\". \nRemoving is quite the opposite of \"add a configuration option that \ndisables it, but leave the old behavior as default\".\n\n> Now that I think about it, it's probably useful to have it\n> togglable via command-line switch as well. Something along the\n> lines of \"git fetch --all-remotes\", perhaps.\n\nMaking it accessible via a command-line switch is pointless, as we \nalready have \"git remote update\" for that.\n\nPaolo\n"},{"id":"75542","messageId":"alpine.DEB.1.00.0804291711450.27457@eeepc-johanness","threadId":"13265","inReplyTo":"4816C67E.8010600@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-29T16:13:55Z","receivedAt":"2008-04-29T16:13:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Apr 2008, Paolo Bonzini wrote:\n\n> > Some of them point to my colleagues laptops, where temporary\n> > git-daemons sometimes serve content, and sometimes it doesn't.\n> \n> Again, you should probably have skipDefaultUpdate set on those remotes even\n> now!\n\nUmm, why?\n\n> A patch that makes a \"wrong\" (or incomplete) configuration more\n> apparent, is not necessarily wrong in itself.\n\nYour suggested changes are actively _making_ them wrong. They are not \nwrong now.\n\nHappily, I am quite certain that Junio will not allow such dramatic \nchanges into Git, at least not without a long, long time of warning, \nduring which I can safely undo the changes in my personal branch.\n\nBecause I do like to call \"git remote update\" from time to time, and I \nabsolutely hate the idea of \"origin\" _not_ being special.\n\nCiao,\nDscho\n"},{"id":"75547","messageId":"48174F78.7020400@gnu.org","threadId":"13265","inReplyTo":"alpine.DEB.1.00.0804291711450.27457@eeepc-johanness","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T16:40:24Z","receivedAt":"2008-04-29T16:40:24Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>>> Some of them point to my colleagues laptops, where temporary\n>>> git-daemons sometimes serve content, and sometimes it doesn't.\n>> Again, you should probably have skipDefaultUpdate set on those remotes even\n>> now!\n> \n> Umm, why?\n\nBecause I don't want to make sure my colleagues *all* have their laptops \nturned on when I run \"git remote update\" (on the default group). Those \nremotes should be fetched individually as the need arises, or maybe with \na special group, but not by default.\n\n>> A patch that makes a \"wrong\" (or incomplete) configuration more\n>> apparent, is not necessarily wrong in itself.\n> \n> Your suggested changes are actively _making_ them wrong. They are not \n> wrong now.\n\nSure, you can consider a configuration that affects \"git remote update\" \nto be correct if you're not using \"git remote update\" at all. But a \nwrong you never saw/experienced is not a right. My changes are actively \nmaking the wrongness apply more broadly, that's clear.\n\n> Happily, I am quite certain that Junio will not allow such dramatic \n> changes into Git, at least not without a long, long time of warning, \n> during which I can safely undo the changes in my personal branch.\n\nI wouldn't be surprised if it didn't go in 1.5.6 -- indeed.\n\nActually I think the \"git pull\" changes (patches 5 and 6) and the \nmatching refs refspec (patches 1 and 2) can go in sooner, but I sort of \nexpect the other 3 patches to lie in limbo for a longer time.\n\n> I absolutely hate the idea of \"origin\" _not_ being special.\n\nWell, Junio and Shawn convinced me of the contrary, so I guess they \ndisagree with you on this one...\n\nPaolo\n"},{"id":"75563","messageId":"20080429193536.GA19340@sigill.intra.peff.net","threadId":"13265","inReplyTo":"cover.1209391614.git.bonzini@gnu.org","subject":"Re: [PATCH 0/7] limit the usage of the default remote \"origin\" to the minimum","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-29T19:35:36Z","receivedAt":"2008-04-29T19:35:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 28, 2008 at 05:23:53PM +0200, Paolo Bonzini wrote:\n\n> Patches 1 to 4 deal with \"git push\". The problem here is that the\n> \"magic\" default operation (\"git push sends to origin all refs that\n> are already present there\"), as of new, cannot be explained in the\n> configuration, and this is fixed by patches 1 and 2. Patch 1 adds a\n> special push refspec meaning \"consider all refs already on the remote\",\n> and patch 2 makes git-clone add one such line when it creates the\n> origin remote.\n\nI like patches 1 and 2. The principle of \"remove defaults from code, and\nput them into the automatically generated config file\" makes sense to\nme. It gives users an easy place to look to understand and change such\nbehavior. So even without the rest of the patches, I think this is an\nimprovement.\n\n> Patch 3 could also be split out of this series. It adds to \"git-remote\n> add\" a new --push option, that sets up a push refspec for the newly\n> created remote.\n\nThis feels a little wrong, since we treat push and fetch lines\ndifferently. That is, I can add just a fetch (\"git remote add\"), or both\n(\"git remote add --push\"), but not just a push. It seems like the\nconcepts should be orthogonal to \"git remote\" (as they are in the config\nfile).\n\n> Patch 4 is a reworking of my previous patch. Instead of having \"git\n> push\" push to \"all mirrors plus the magic origin branch\", it will\n> push to \"all remotes having a push refspec\". In the future, this\n> will always include the origin branch because of patch 2, while\n> right now the origin branch is still used if no remote has a\n> push refspec (for backwards compatibility -- more discussion in the\n> patch log message).\n>\n> This patch may cause incompatibilities to be warned about in\n> the release notes. Luckily, these incompatibilities only affect\n> users that already know their way in .git/config, because no porcelain\n> command creates push refspecs.\n\nI think you understand the compatibility issues, but I think it needs to\nbe not \"warned in the release notes\" but \"warned in the release notes,\nfollowed by a period of adjustment, and then the change\". And maybe it\nwould even make sense to wait for a larger-number version change (like\n1.6.0).\n\n> Patches 5 and 6 affect \"git pull\". Pulling uses the magic origin branch\n> less often, because branch.*.remote already establishes a saner default.\n> Therefore, here we can actually warn and deprecate the misfeature for\n> real (patch 6). Patch 5 however is still needed, so that \"git pull\"\n> itself decides when to use the magic \"origin\" branch instead of making\n> the decision in \"git fetch\".\n\nI agree that patch 5 is a reasonable cleanup, regardless.\n\nI'm not sure about patch 6. What are the cases that can trigger this? I\nassume people still with ancient .git/remotes files? Are those actually\ndeprecated?\n\n> Finally, patch 7 affects \"git fetch\". As hinted earlier, I chose to\n> duplicate the functionality already present in \"git remote update\"\n> (for the case where remotes are not grouped), but the code is much\n> simpler so there is no incentive (at least for now) in borrowing code\n> from \"git remote update\" into \"git fetch\"---actually, as a cleanup\n> it is maybe possible to borrow code in the other direction.\n\nAgain, I like this behavior just fine, but it probably needs a warning\nperiod and a major version bump.\n\n> \"BTW, I find myself decreasingly using \"git fetch\" in favor of \"git\n> remote update\" which handles fetching from multiple remotes.\"\n> \tThe series remove the need to switch from \"git fetch\" to\n> \t\"git remote update\" as one learns the power of DVCS.\n\nThis was from me, and I do like this behavior better.\n\n-Peff\n"},{"id":"75569","messageId":"20080429202429.GA6301@steel.home","threadId":"13265","inReplyTo":"4816C527.4000406@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T20:24:29Z","receivedAt":"2008-04-29T20:24:29Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Tue, Apr 29, 2008 08:50:15 +0200:\n>>>>> I can add a global boolean configuration to change the default\n>>>>> value of skipDefaultRemote.\n>>>>>\n>>>> With the default NOT so that current behaviour stays?\n>>> No, absolutely. In fact if I were you I would set\n>>> skipDefaultUpdate *now* on the remotes of that repo.\n>>\n>> And all the others, who don't read this discussion, are just\n>> expected to adapt?\n>\n> Man, that's what release notes are for. You are expected to read those.\n>\n\nSo, a sysadm of a big development site reads them... and faces a big\nupdate in all the hundreds of repos (which exists since git-1.4 and\nwere good all this time, BTW). Besides, he faces a need to explain the\nneed for this behavioural change in a really core tool. And, being\nnot really convinced himself that it was needed (I, for one, am not\nconvinced), he finds it real hard.\n\nNo, I don't have hundreds of repos. Just around 30. And I am (mostly)\nalone working with them. I still don't like the idea of updating them.\n"},{"id":"75571","messageId":"20080429203442.GB6301@steel.home","threadId":"13265","inReplyTo":"48174F78.7020400@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T20:34:42Z","receivedAt":"2008-04-29T20:34:42Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Tue, Apr 29, 2008 18:40:24 +0200:\n>> Happily, I am quite certain that Junio will not allow such dramatic \n>> changes into Git, at least not without a long, long time of warning, \n>> during which I can safely undo the changes in my personal branch.\n>\n> I wouldn't be surprised if it didn't go in 1.5.6 -- indeed.\n>\n\nI hope it wont go in till 1.6 (like in many months). And long before\nthere will be a change in \"git remote add\" which sets\nskipDefaultUpdate to true. And there will be a change in \"git fetch\"\nwhich will warn the user in legacy repositories which have no\nskipDefaultUpdate at all.\n"},{"id":"75572","messageId":"20080429204417.GC6301@steel.home","threadId":"13265","inReplyTo":"4816D505.1000208@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T20:44:17Z","receivedAt":"2008-04-29T20:44:17Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:\n>> Failing that, would you get slightly annoyed, or perhaps even quite\n>> vexed if you find out that insert-program-used-to-do-some-work-with-here\n>> did omething stupid that made you lose some of your work?\n>\n> Sorry, how does the patch make you lose some of your work (as opposed to \n> some of your time, which is possible as is the case for every backwards \n> incompatible change)?\n>\n> 1) what about the reflog?\n\nIt could not be enabled in repos before May 2006 (as the feature did\nnot exist back than).\n\n> 2) the patch does not touch refs/heads/* unless you are tweaking your \n> configuration (and quite heavily so). IMHO that's using enough rope \n> that you really ought to know about the reflog and... look for backwards \n> incompatible changes in the release notes!\n\nSince when do you depend on people reading release notes and\nimmediately and correctly changing their behaviour?\n\n> 3) your complaint was that it gave errors. Alex did talk about losing \n> his work, but questions 1 and 2 would apply to him too.\n\nYes. And I can loose my work if \"git fetch\" (which I type without\nthinking) will now update some remote I didn't mean it to.\nRemote references can be shared - updated from different sites (think\nmirros like kernel.org and repo.or.cz). Setups like this are used\nelsewhere too (I use them).\n\n> 4) one man's stupidity is another man's... [fill in] In particular, did \n> you understand the rationale for this change? Do you have any \n> alternative ideas?\n\nDo you have a convincing one by now? And an acceptable transition plan?\n(\"Read RelNotes!\", yes, you mentioned. Another one?)\n"},{"id":"75576","messageId":"200804292108.m3TL8moS011790@mi1.bluebottle.com","threadId":"13265","inReplyTo":"4816E40A.4020700@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-04-29T21:08:03Z","receivedAt":"2008-04-29T21:08:03Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Paolo Bonzini :\n\n>>> Sorry, how does the patch make you lose some of your work (as\n>>> opposed to some of your time, which is possible as is the case for\n>>> every backwards incompatible change)?\n>>\n>> Because I will lose some of the refs and then have to dig them up in the\n>> reflog.\n>>\n>> I'm not comfortable with the reflog. I appreciate its usefulness, but I'm\n>> thoroughly unhappy when I'm forced to use it.\n>\n> So am I, but still it would lose time (to dig refs up in the reflog),\n> not work (e.g. having to rewrite code). I think we're in agreement on\n> this part.\n>\n>> Yes, I understand the rationale, and I do have an alternative idea, which\n>> is to make it configurable.\n>\n> Then sorry, but I think you don't understand the rationale. The cover\n> letter has excerpts from other git hackers' e-mails that explain it\n> better than I can. But shortly speaking, the point of the patch is to\n> remove the \"magic\" operation of \"git fetch\" as \"git fetch\n> origin\". Removing is quite the opposite of \"add a configuration option\n> that disables it, but leave the old behavior as default\".\n>\n>> Now that I think about it, it's probably useful to have it\n>> togglable via command-line switch as well. Something along the\n>> lines of \"git fetch --all-remotes\", perhaps.\n>\n> Making it accessible via a command-line switch is pointless, as we\n> already have \"git remote update\" for that.\n>\n> Paolo\n\nSorry but then why does this patch have to even touch \"git fetch\"? Isn't it enough to run \"git remote update\"?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nGet a free email account with anti spam protection.\nhttp://www.bluebottle.com/tag/2\n"},{"id":"75578","messageId":"48178FD6.90104@gnu.org","threadId":"13265","inReplyTo":"20080429204417.GC6301@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T21:15:02Z","receivedAt":"2008-04-29T21:15:02Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":">> 2) the patch does not touch refs/heads/* unless you are tweaking your \n>> configuration (and quite heavily so). IMHO that's using enough rope \n>> that you really ought to know about the reflog and... look for backwards \n>> incompatible changes in the release notes!\n> \n> Since when do you depend on people reading release notes and\n> immediately and correctly changing their behaviour?\n\nI don't, that's why I never expected all patches to go in 1.5.6.\n\nI sent them together to provide a single coherent series and an aim for \na transition plan -- which I'd prefer to work out with the git \ncommunity, who knows the release mechanics much better than I do. Jeff \nKing's reply to the cover letter is a start towards that; your e-mails \nare also a start towards that, even though I don't think your transition \nplan is feasible (also because it would break \"git remote update\" \ncompletely).\n\n>> 4) one man's stupidity is another man's... [fill in] In particular, did \n>> you understand the rationale for this change? Do you have any \n>> alternative ideas?\n> \n> Do you have a convincing one by now?\n\nSee the (long) cover letter.\n\n> And an acceptable transition plan?\n> (\"Read RelNotes!\", yes, you mentioned. Another one?)\n\nSee above.\n\nPaolo\n"},{"id":"75581","messageId":"4817915C.6060009@gnu.org","threadId":"13265","inReplyTo":"200804292108.m3TL8moV011790@mi1.bluebottle.com","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T21:21:32Z","receivedAt":"2008-04-29T21:21:32Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> Sorry but then why does this patch have to even touch \"git fetch\"? \n> Isn't it enough to run \"git remote update\"?\n\nI'm tired of answering. Please read the cover letter. It's not about \nadding new features (it does in patches 1 to 3, but only as means to an \nend). It's about rationalizing existing behavior so that \"newbie usage \npatterns\" generalize better, and patches 4 and 7 are the most important \n(and the most controversial) in this respect.\n\nPaolo\n"},{"id":"75584","messageId":"20080429213323.GA2413@steel.home","threadId":"13265","inReplyTo":"48178FD6.90104@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T21:33:23Z","receivedAt":"2008-04-29T21:33:23Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Tue, Apr 29, 2008 23:15:02 +0200:\n>>> 2) the patch does not touch refs/heads/* unless you are tweaking your \n>>> configuration (and quite heavily so). IMHO that's using enough rope \n>>> that you really ought to know about the reflog and... look for \n>>> backwards incompatible changes in the release notes!\n>>\n>> Since when do you depend on people reading release notes and\n>> immediately and correctly changing their behaviour?\n>\n> I don't, that's why I never expected all patches to go in 1.5.6.\n>\n\nOh, the next minor release...\n\n> I sent them together to provide a single coherent series and an aim for \n> a transition plan -- which I'd prefer to work out with the git \n> community, who knows the release mechanics much better than I do. Jeff \n> King's reply to the cover letter is a start towards that; your e-mails \n\nHmm... Which one do you mean? I cannot find his reply to message-id\n\n\n> are also a start towards that, even though I don't think your transition \n> plan is feasible (also because it would break \"git remote update\" \n> completely).\n\nWhich part of \"warn people in git-fetch\" will break \"git remote update\"?\nOr what will break after the \"git remote add\" start setting\nskipDefaultUpdate?\n\n>>> 4) one man's stupidity is another man's... [fill in] In particular, \n>>> did you understand the rationale for this change? Do you have any \n>>> alternative ideas?\n>>\n>> Do you have a convincing one by now?\n>\n> See the (long) cover letter.\n>\n\nIt is not. It seem to propose, instead of fixing existing behaviour,\nchange it incompatibly. And dangerously, I believe.\n"},{"id":"75586","messageId":"alpine.DEB.1.00.0804292236380.13650@eeepc-johanness","threadId":"13265","inReplyTo":"20080429204417.GC6301@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-29T21:39:31Z","receivedAt":"2008-04-29T21:39:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Apr 2008, Alex Riesen wrote:\n\n> Paolo Bonzini, Tue, Apr 29, 2008 09:57:57 +0200:\n>\n> > 3) your complaint was that it gave errors. Alex did talk about losing \n> > his work, but questions 1 and 2 would apply to him too.\n> \n> Yes. And I can loose my work if \"git fetch\" (which I type without \n> thinking) will now update some remote I didn't mean it to. Remote \n> references can be shared - updated from different sites (think mirros \n> like kernel.org and repo.or.cz). Setups like this are used elsewhere too \n> (I use them).\n\nLike I said, I think this change affects too many existing users in a very \nnegative way.\n\nBut then, I respect Junio's very careful way of dealing with such issues, \nand am not really doubting that it will take a long, long time to change \nthe default behaviour of Git, if at all. Which is a good thing.\n\nAnd I am certain that Paolo does not believe his release notes argument \neither. Not seriously, anyway.\n\nCiao,\nDscho\n"},{"id":"75590","messageId":"48179625.3050704@gnu.org","threadId":"13265","inReplyTo":"20080429213323.GA2413@steel.home","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-29T21:41:57Z","receivedAt":"2008-04-29T21:41:57Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> I sent them together to provide a single coherent series and an aim for \n>> a transition plan -- which I'd prefer to work out with the git \n>> community, who knows the release mechanics much better than I do. Jeff \n>> King's reply to the cover letter is a start towards that; your e-mails \n> \n> Hmm... Which one do you mean? I cannot find his reply to message-id\n> \n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/80720\n\n>> are also a start towards that, even though I don't think your transition \n>> plan is feasible (also because it would break \"git remote update\" \n>> completely).\n> \n> Which part of \"warn people in git-fetch\" will break \"git remote update\"?\n> Or what will break after the \"git remote add\" start setting\n> skipDefaultUpdate?\n\nPeople will expect the new remotes to be, ehm, updated by \"git remote \nupdate\".\n\n> It is not. It seem to propose, instead of fixing existing behaviour,\n\nDo you know how to \"fix\" existing behavior?\n\nI mean, I just wonder why as long as I had one remote only, I could \nwrite \"git push\", while now I have to write \"git push origin && git push \nmirror\". The patch to \"git fetch\" comes from this observation too, and \nI think it is a good idea, even though I'm less attached to it and it \nwould influence my workflow much less.\n\nPaolo\n"},{"id":"75591","messageId":"20080429214210.GB2413@steel.home","threadId":"13265","inReplyTo":"20080429193536.GA19340@sigill.intra.peff.net","subject":"Re: [PATCH 0/7] limit the usage of the default remote \"origin\" to the minimum","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T21:42:10Z","receivedAt":"2008-04-29T21:42:10Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jeff King, Tue, Apr 29, 2008 21:35:36 +0200:\n> On Mon, Apr 28, 2008 at 05:23:53PM +0200, Paolo Bonzini wrote:\n> > This patch may cause incompatibilities to be warned about in\n> > the release notes. Luckily, these incompatibilities only affect\n> > users that already know their way in .git/config, because no porcelain\n> > command creates push refspecs.\n> \n> I think you understand the compatibility issues, but I think it needs to\n> be not \"warned in the release notes\" but \"warned in the release notes,\n> followed by a period of adjustment, and then the change\". And maybe it\n> would even make sense to wait for a larger-number version change (like\n> 1.6.0).\n\nBut please, make this \"period of adjustment\" actually visible to the\nUSER WHO DOES NOT READ RELEASE NOTES. Say loud and clear when you do\nsomething different. And better yet - do not do anything unexpected\njust yet. Describe it, print instructions about changing\nconfiguration. So that next less-minor-release with changed behavior\n(but the warning still in place) is less of a surprise.\n"},{"id":"75593","messageId":"20080429215311.GC2413@steel.home","threadId":"13265","inReplyTo":"48179625.3050704@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-04-29T21:53:11Z","receivedAt":"2008-04-29T21:53:11Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paolo Bonzini, Tue, Apr 29, 2008 23:41:57 +0200:\n>> Hmm... Which one do you mean? I cannot find his reply to message-id\n>> \n>\n> http://permalink.gmane.org/gmane.comp.version-control.git/80720\n>\n\nJust received it\n\n>>> are also a start towards that, even though I don't think your \n>>> transition plan is feasible (also because it would break \"git remote \n>>> update\" completely).\n>>\n>> Which part of \"warn people in git-fetch\" will break \"git remote update\"?\n>> Or what will break after the \"git remote add\" start setting\n>> skipDefaultUpdate?\n>\n> People will expect the new remotes to be, ehm, updated by \"git remote \n> update\".\n>\n\nAh, right. How about a warning, then? Like:\n\n $ git remote add abc host:src/project\n warning: fetch and push without arguments WILL update the references of \"abc\"\n $\n\n>> It is not. It seem to propose, instead of fixing existing behaviour,\n>\n> Do you know how to \"fix\" existing behavior?\n>\n\nNever considered it broken. OTOH, it hasn't occured to me to run \"git\npush\" without arguments. And I do expect \"git fetch\" to fetch just the\nremote my current branch is related to (and not all remotes).\n\n> I mean, I just wonder why as long as I had one remote only, I could \n> write \"git push\", while now I have to write \"git push origin && git push \n> mirror\". The patch to \"git fetch\" comes from this observation too, and \n> I think it is a good idea, even though I'm less attached to it and it \n> would influence my workflow much less.\n\nHave you tested your patches in your workflow? Worked with them for\nsome weeks? Gave them to your peers?\n"},{"id":"75594","messageId":"7vwsmg5nqv.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"20080429193536.GA19340@sigill.intra.peff.net","subject":"Re: [PATCH 0/7] limit the usage of the default remote \"origin\" to the minimum","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-29T21:56:24Z","receivedAt":"2008-04-29T21:56:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... The principle of \"remove defaults from code, and\n> put them into the automatically generated config file\" makes sense to\n> me. It gives users an easy place to look to understand and change such\n> behavior. So even without the rest of the patches, I think this is an\n> improvement.\n\nIf the removal of defaults do not break expectations of users of an\nexisting repository, I'd agree. Is it the case, or the lack of default\nthat is supposed to be there now suddenly makes the tool do unexpected\nthings?\n\n>> Patch 4 is a reworking of my previous patch. Instead of having \"git\n>> push\" push to \"all mirrors plus the magic origin branch\", it will\n>> push to \"all remotes having a push refspec\". In the future, this\n>> will always include the origin branch because of patch 2, while\n>> right now the origin branch is still used if no remote has a\n>> push refspec (for backwards compatibility -- more discussion in the\n>> patch log message).\n\nDidn't we already have this discussion and don't we already have a way to\ndefine a remote that you can use to push to more than one places?\n\n>> This patch may cause incompatibilities to be warned about in\n>> the release notes. Luckily, these incompatibilities only affect\n>> users that already know their way in .git/config, because no porcelain\n>> command creates push refspecs.\n\n\"Knowledgeable people all _can_ work around the change\" does not change\nthe fact that you are forcing existing users unnecessary change to their\nconfigurations. Why does this patch need to break existing users setups?\n\n> ... I\n> assume people still with ancient .git/remotes files? Are those actually\n> deprecated?\n\nNo.\n\nNeither .git/branches. When you interact with hundreds of remote\nrepositories, one interesting branch per each, like akpm does, the format\nof one-file-per-remote is far easier and simpler to work with.\n"},{"id":"75600","messageId":"alpine.DEB.1.00.0804292320240.13650@eeepc-johanness","threadId":"13265","inReplyTo":"4817915C.6060009@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-29T22:21:31Z","receivedAt":"2008-04-29T22:21:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Apr 2008, Paolo Bonzini wrote:\n\n> > Sorry but then why does this patch have to even touch \"git fetch\"? \n> > Isn't it enough to run \"git remote update\"?\n> \n> I'm tired of answering. Please read the cover letter.\n\nActually, this is unfair. You did not answer it to my satisfaction, but I \nthought that maybe it is just me.\n\nAlas, apparently it is not just me. I think that \"git fetch\" is something \nmore concise than \"git remote update\", and that it is a good thing.\n\nCiao,\nDscho\n"},{"id":"75602","messageId":"alpine.DEB.1.00.0804292324040.13650@eeepc-johanness","threadId":"13265","inReplyTo":"48179625.3050704@gnu.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-29T22:26:46Z","receivedAt":"2008-04-29T22:26:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Apr 2008, Paolo Bonzini wrote:\n\n> I mean, I just wonder why as long as I had one remote only, I could \n> write \"git push\", while now I have to write \"git push origin && git push \n> mirror\". The patch to \"git fetch\" comes from this observation too, and \n> I think it is a good idea, even though I'm less attached to it and it \n> would influence my workflow much less.\n\nI wonder why you need to make such a big change, which _is_ incompatible, \nand not do the obvious thing, namely introduce a subcommand to \"git \nremote\" which does the \"push\" equivalent of \"git remote update\"...\n\nDo you really think that it is a good idea to push down a huge change like \nthis down everybody else's throat, just because you do not want to type \n\"git remote ...\" but \"git fetch ...\" in your workflow?\n\nCiao,\nDscho\n"},{"id":"75606","messageId":"20080429230237.GA22598@sigill.intra.peff.net","threadId":"13265","inReplyTo":"alpine.DEB.1.00.0804292324040.13650@eeepc-johanness","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-29T23:02:37Z","receivedAt":"2008-04-29T23:02:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 29, 2008 at 11:26:46PM +0100, Johannes Schindelin wrote:\n\n> I wonder why you need to make such a big change, which _is_ incompatible, \n> and not do the obvious thing, namely introduce a subcommand to \"git \n> remote\" which does the \"push\" equivalent of \"git remote update\"...\n> \n> Do you really think that it is a good idea to push down a huge change like \n> this down everybody else's throat, just because you do not want to type \n> \"git remote ...\" but \"git fetch ...\" in your workflow?\n\nI wonder this a bit, too, and I am even somebody who _likes_ the new\nbehavior. But there is a difference between \"should have been designed\nthis way in the first place\" and \"is currently designed some other way,\nand will cause pain to switch it to this way.\"\n\nSo it might simply not be worth the trouble to change. OTOH, I think\nthis is how we end up with many commands to do slightly different\nthings, which can end up confusing new users. I'm not sure what the\nright answer is.\n\n-Peff\n"},{"id":"75610","messageId":"20080429231201.GA22646@sigill.intra.peff.net","threadId":"13265","inReplyTo":"7vwsmg5nqv.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 0/7] limit the usage of the default remote \"origin\" to the minimum","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-29T23:12:01Z","receivedAt":"2008-04-29T23:12:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 29, 2008 at 02:56:24PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... The principle of \"remove defaults from code, and\n> > put them into the automatically generated config file\" makes sense to\n> > me. It gives users an easy place to look to understand and change such\n> > behavior. So even without the rest of the patches, I think this is an\n> > improvement.\n> \n> If the removal of defaults do not break expectations of users of an\n> existing repository, I'd agree. Is it the case, or the lack of default\n> that is supposed to be there now suddenly makes the tool do unexpected\n> things?\n\nI think in the case of patches 1 and 2 (but without the later patches)\nit becomes redundant. And of course, Paolo's idea is that it opens us up\nto changing the default later, in which case it will cease to be\nredundant. But I think even in the meantime that it gives the user\na clue when looking in the config file about what can be tweaked.\n\n> > ... I\n> > assume people still with ancient .git/remotes files? Are those actually\n> > deprecated?\n> \n> No.\n> \n> Neither .git/branches. When you interact with hundreds of remote\n> repositories, one interesting branch per each, like akpm does, the format\n> of one-file-per-remote is far easier and simpler to work with.\n\nThen in that case, I think the warning is definitely bogus.\n\n-Peff\n"},{"id":"75611","messageId":"7vzlrc45ex.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"20080429230237.GA22598@sigill.intra.peff.net","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-29T23:17:42Z","receivedAt":"2008-04-29T23:17:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I wonder this a bit, too, and I am even somebody who _likes_ the new\n> behavior. But there is a difference between \"should have been designed\n> this way in the first place\" and \"is currently designed some other way,\n> and will cause pain to switch it to this way.\"\n>\n> So it might simply not be worth the trouble to change. OTOH, I think\n> this is how we end up with many commands to do slightly different\n> things, which can end up confusing new users. I'm not sure what the\n> right answer is.\n\nWell, the thing is, push and fetch are different, so expecting the same\nbehaviour and syntax from them is a lost cause to begin with. Even if we\nwere designing fetch and push right now, I do not necessarily think the\nseries shows a way that \"should have been designed in the first place\".\n"},{"id":"75635","messageId":"48180270.9080708@gnu.org","threadId":"13265","inReplyTo":"20080429231201.GA22646@sigill.intra.peff.net","subject":"Re: [PATCH 0/7] limit the usage of the default remote \"origin\" to the minimum","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-30T05:24:00Z","receivedAt":"2008-04-30T05:24:00Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>>> ... The principle of \"remove defaults from code, and\n>>> put them into the automatically generated config file\" makes sense to\n>>> me. It gives users an easy place to look to understand and change such\n>>> behavior. So even without the rest of the patches, I think this is an\n>>> improvement.\n>> If the removal of defaults do not break expectations of users of an\n>> existing repository, I'd agree. Is it the case, or the lack of default\n>> that is supposed to be there now suddenly makes the tool do unexpected\n>> things?\n> \n> I think in the case of patches 1 and 2 (but without the later patches)\n> it becomes redundant. And of course, Paolo's idea is that it opens us up\n> to changing the default later, in which case it will cease to be\n> redundant. But I think even in the meantime that it gives the user\n> a clue when looking in the config file about what can be tweaked.\n\nAgreed. Patches 1 and 2 can definitely go in earlier and can help in \nthe transition (see later).\n\n> Didn't we already have this discussion and don't we already have a way to\n> define a remote that you can use to push to more than one places?\n\nNo, because you may want to push to some places, and mirror to others. \nUnfortunately, mirroring is not handled entirely within match_refs but \nis also special-cased in builtin-send-pack.c. So you cannot handle it \nwith a magic refspec (like --force), and you are forced to use a \nseparate remote, independent of remote.*.mirror.\n\n>>> ... I\n>>> assume people still with ancient .git/remotes files? Are those actually\n>>> deprecated?\n>>\n>> Neither .git/branches. When you interact with hundreds of remote\n>> repositories, one interesting branch per each, like akpm does, the format\n>> of one-file-per-remote is far easier and simpler to work with.\n> \n> Then in that case, I think the warning is definitely bogus.\n\nWhen you use .git/remotes and .git/branches, do you actually use them \nwith the zero-argument versions of \"git pull\" (and \"git fetch\")? I'm \nnot sure about that, actually I very much doubt so.\n\nSo here is my plan.\n\n1) Merge patches 1 and 2 now.\n\n2) Add a warning to \"git push\" if it pushes to something without a push \nrefspec. Merge patch 3, the doc can say that --push suppresses this \nwarning. Make sure the warning suggests how to silence it.\n\n3) Merge patch 5 as it is just a cleanup.\n\n4) Merge patch 6.\n\n5) Add a similar warning to \"git fetch\".\n\n6) Add a warning when \"git push\" is used with zero-arguments and there \nis more than one remote with a push refspec. Something like, \"git push \nwill only push to ***. This may not be what you want, and it may change \nin future versions of git\".\n\n7) If there is a revolt against the warning in (5), revert it and add a \nwarning whenever the \"magic origin\" behavior is triggered by \"git push\".\n\n\nFor 1.6.0, the remaining changes would be harder to warn about \npreventively, so this part can be refined:\n\n8) In \"git pull\", turn the warning into an error.\n\n9) Ditto for \"git fetch\".\n\n10) Ditto for \"git push\" if we had to go for (7). If we didn't, merge \npatch 4 for 1.6.0. Put a prominent note in the release notes that \"git \npush\" will push to all remotes with a push refspec. By now, users will \nhave added push refspecs appropriately thanks to the warning in step 2 \nabove; so at least \"git push\" will not stop pushing to origin.\n\n\nIn the meanwhile, decide what is the best thing to do for patch 7. If \nwe decide it is to go in, steps 5 and 9 will have to be replaced with \nsomething else (I don't know what).\n\nPaolo\n"},{"id":"75636","messageId":"48180381.9070801@gnu.org","threadId":"13265","inReplyTo":"7vzlrc45ex.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 7/7] make \"git fetch\" update all fetch repositories","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-30T05:28:33Z","receivedAt":"2008-04-30T05:28:33Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> Do you really think that it is a good idea to push down a huge change like \n> this down everybody else's throat, just because you do not want to type \n> \"git remote ...\" but \"git fetch ...\" in your workflow?\n\nIt's not that I don't want. I couldn't care less, but I just don't see \nwhy I should have learnt it in the first place.\n\n>> I wonder this a bit, too, and I am even somebody who _likes_ the new\n>> behavior. But there is a difference between \"should have been designed\n>> this way in the first place\" and \"is currently designed some other way,\n>> and will cause pain to switch it to this way.\"\n\nAgreed.\n\n>> So it might simply not be worth the trouble to change. OTOH, I think\n>> this is how we end up with many commands to do slightly different\n>> things, which can end up confusing new users. I'm not sure what the\n>> right answer is.\n> \n> Well, the thing is, push and fetch are different, so expecting the same\n> behaviour and syntax from them is a lost cause to begin with. Even if we\n> were designing fetch and push right now, I do not necessarily think the\n> series shows a way that \"should have been designed in the first place\".\n\nTo me, \"push and pull\" are different obviously (because pull modifies \ntwo refs, the remote one and the local one). But \"push and fetch\" are \nnot so different, so I do expect lots of different options but the gist \nof the command-line syntax to be the same.\n\nThere are definitely uncontroversial changes in the series, we can start \nfrom there.\n\nPaolo\n"},{"id":"75661","messageId":"7vfxt31ys6.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"af57d23aca6137c1ae7702027ce3742433840872.1209391614.git.bonzini@gnu.org","subject":"Re: [PATCH 1/7] add special \"matching refs\" refspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-30T09:23:53Z","receivedAt":"2008-04-30T09:23:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n> @@ -937,13 +945,23 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,\n> \t\t\t\t\t\t const struct ref *src)\n> {\n> \tint i;\n> +\tint matching_refs = -1;\n> \tfor (i = 0; i < rs_nr; i++) {\n> +\t\tif (rs[i].matching &&\n> +\t\t (matching_refs == -1 || rs[i].force)) {\n> +\t\t\tmatching_refs = i;\n> +\t\t\tcontinue;\n> +\t\t}\n> +\n> \t\tif (rs[i].pattern &&\n> \t\t !prefixcmp(src->name, rs[i].src) &&\n> \t\t src->name[strlen(rs[i].src)] == '/')\n> \t\t\treturn rs + i;\n> \t}\n> -\treturn NULL;\n> +\tif (matching_refs != -1)\n> +\t\treturn rs + matching_refs;\n> +\telse\n> +\t\treturn NULL;\n> }\n\nIt is probably better to document that you would force if you have both\n\"+:\" and \":\" for the same remote, even though I am not sure if allowing\nthat (instead of diagnosing it as an error) is the right thing to do.\n\nIs it an error to have both \":\" and \"some:other\" refspecs for the same\nremote? If so who makes the check?\n\nOtherwise this patch seems to be very cleanly done. Especially I like how\nthe updated match_refs() looks.\n"},{"id":"75662","messageId":"48183D44.8080507@gnu.org","threadId":"13265","inReplyTo":"7vfxt31ys6.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/7] add special \"matching refs\" refspec","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-30T09:35:00Z","receivedAt":"2008-04-30T09:35:00Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n>> +\t\tif (rs[i].matching &&\n>> +\t\t (matching_refs == -1 || rs[i].force)) {\n>> +\t\t\tmatching_refs = i;\n>> +\t\t\tcontinue;\n>> +\t\t}\n>\n> It is probably better to document that you would force if you have both\n> \"+:\" and \":\" for the same remote, even though I am not sure if allowing\n> that (instead of diagnosing it as an error) is the right thing to do.\n\nI screwed up here. I was sure that something like\n\n push = refs/heads/*:refs/heads/*\n push = +refs/heads/*:refs/heads/*\n\nwould also force, instead the first one wins. I'm ok with just removing \nthe \"|| rs[i].force\" part.\n\n> Is it an error to have both \":\" and \"some:other\" refspecs for the same\n> remote? If so who makes the check?\n\nNo, it is not an error. For example, it allows to have a\n\n\tpush = refs/tags/*:refs/tags/*\n\tpush = :\n\nrefspec, which pushes all tags but only pushes branches if there is a \nmatching ref on the other side. I don't have a use for this, but it \nmade sense to support the general case.\n\n> Otherwise this patch seems to be very cleanly done. Especially I like how\n> the updated match_refs() looks.\n\nThanks. Should I resubmit?\n\nPaolo\n"},{"id":"75734","messageId":"7vve1yzgfc.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"ff298458e7efc14721fdc0420432bf33efd76784.1209391614.git.bonzini@gnu.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2008-05-01T06:28:39Z","receivedAt":"2008-05-01T06:28:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n> This patch makes git-clone add a remote.origin.push line, using the\n> new \":\" special refspec. This is useful in the following patches that\n> modify the behavior of \"git push\"; right now, it only adds clarity.\n\nUsed together with [1/7], this change is Ok in a homogeneous environment,\nbut it would break people who use git of different vintage on the same\nrepository (think of a repository on a networked filesystem). You clone\nlike this, and older git won't grok the push configuration anymore.\n\nIt may look a very minor point, but I think it deserves mentioning.\n"},{"id":"76187","messageId":"482018E4.9000908@gnu.org","threadId":"13265","inReplyTo":"7vve1yzgfc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-05-06T08:37:56Z","receivedAt":"2008-05-06T08:37:56Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Used together with [1/7], this change is Ok in a homogeneous environment,\n> but it would break people who use git of different vintage on the same\n> repository (think of a repository on a networked filesystem). You clone\n> like this, and older git won't grok the push configuration anymore.\n> \n> It may look a very minor point, but I think it deserves mentioning.\n\nI think it is reasonable to require cloning with the \nleast-common-denominator version in this case. Think of what happened \nif the pack format changed.\n\nPaolo\n"},{"id":"76948","messageId":"482B0354.2060207@gnu.org","threadId":"13265","inReplyTo":"482018E4.9000908@gnu.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-05-14T15:20:52Z","receivedAt":"2008-05-14T15:20:52Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Paolo Bonzini wrote:\n> \n>> Used together with [1/7], this change is Ok in a homogeneous environment,\n>> but it would break people who use git of different vintage on the same\n>> repository (think of a repository on a networked filesystem). You clone\n>> like this, and older git won't grok the push configuration anymore.\n>>\n>> It may look a very minor point, but I think it deserves mentioning.\n> \n> I think it is reasonable to require cloning with the \n> least-common-denominator version in this case. Think of what happened \n> if the pack format changed.\n\nAny news on this (and on 1/7, which is in pu)?\n\nPaolo\n"},{"id":"76968","messageId":"7vhcd0oiov.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"482B0354.2060207@gnu.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-14T18:16:00Z","receivedAt":"2008-05-14T18:16:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n> Paolo Bonzini wrote:\n>>\n>>> Used together with [1/7], this change is Ok in a homogeneous environment,\n>>> but it would break people who use git of different vintage on the same\n>>> repository (think of a repository on a networked filesystem). You clone\n>>> like this, and older git won't grok the push configuration anymore.\n>>>\n>>> It may look a very minor point, but I think it deserves mentioning.\n>>\n>> I think it is reasonable to require cloning with the\n>> least-common-denominator version in this case. Think of what\n>> happened if the pack format changed.\n>\n> Any news on this (and on 1/7, which is in pu)?\n\nI did not personally find that argument convincing, and I thought list\nagreed with me with silence ;-).\n\nThe pack-format change is a big deal and benefit everybody. Comparing it\nwith this change feels like comparing an apple and a poppy seed, doesn't\nit?\n"},{"id":"76976","messageId":"482B3854.9040906@gnu.org","threadId":"13265","inReplyTo":"7vhcd0oiov.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-05-14T19:07:00Z","receivedAt":"2008-05-14T19:07:00Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Junio C Hamano wrote:\n> Paolo Bonzini writes:\n> \n>> Paolo Bonzini wrote:\n>>>> Used together with [1/7], this change is Ok in a homogeneous environment,\n>>>> but it would break people who use git of different vintage on the same\n>>>> repository (think of a repository on a networked filesystem). You clone\n>>>> like this, and older git won't grok the push configuration anymore.\n>>>>\n>>>> It may look a very minor point, but I think it deserves mentioning.\n>>>\n>>> I think it is reasonable to require cloning with the\n>>> least-common-denominator version in this case. Think of what\n>>> happened if the pack format changed.\n>> Any news on this (and on 1/7, which is in pu)?\n> \n> The pack-format change is a big deal and benefit everybody. Comparing it\n> with this change feels like comparing an apple and a poppy seed, doesn't\n> it?\n\nYes, but it is the same. Another example is when remotes started being \ncreated in refs/remotes/origin upon cloning. In general, you cannot \nexpect a clone to be downwards-compatible (or, you should expect a clone \n*not* to be downwards-compatible).\n\nPaolo\n"},{"id":"76979","messageId":"7vod78n10h.fsf@gitster.siamese.dyndns.org","threadId":"13265","inReplyTo":"482B3854.9040906@gnu.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-14T19:23:10Z","receivedAt":"2008-05-14T19:23:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n>>>> I think it is reasonable to require cloning with the\n>>>> least-common-denominator version in this case. Think of what\n>>>> happened if the pack format changed.\n>>> Any news on this (and on 1/7, which is in pu)?\n>>\n>> The pack-format change is a big deal and benefit everybody. Comparing it\n>> with this change feels like comparing an apple and a poppy seed, doesn't\n>> it?\n>\n> Yes, but it is the same. Another example is when remotes started\n> being created in refs/remotes/origin upon cloning. In general, you\n> cannot expect a clone to be downwards-compatible (or, you should\n> expect a clone *not* to be downwards-compatible).\n\nI think we are in agreement and that is all the more reason we have to be\nextremely careful not to introduce incompatibility without a clear\nadvantage. The commands involved with your patch work with or without the\nnew default entry in the config created by the clone exactly the same way,\nand the versions before your patch would choke with the new default entry.\n"},{"id":"76981","messageId":"482B403C.5060101@gnu.org","threadId":"13265","inReplyTo":"7vod78n10h.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/7] add push line in git-clone","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-05-14T19:40:44Z","receivedAt":"2008-05-14T19:40:44Z","isPatch":true,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> I think we are in agreement and that is all the more reason we have to be\n> extremely careful not to introduce incompatibility without a clear\n> advantage. The commands involved with your patch work with or without the\n> new default entry in the config created by the clone exactly the same way,\n> and the versions before your patch would choke with the new default entry.\n\nOk, this patch is (for now :-) withdrawn. I think I'll punt and prepare \nsomething along the lines of \"git remote push\". When I get to that, we \ncan reconsider this patch too.\n\nPaolo\n"}]}