{"thread":{"id":"4011","subject":"[PATCH 3/3] fetch: optionally store the current remote information in the config","startedAt":"2006-04-30T13:24:22Z","lastAt":"2006-05-03T00:36:24Z","messageCount":16,"participants":["Johannes Schindelin","Jakub Narebski","sean","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"19285","messageId":"Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4011","inReplyTo":null,"subject":"[PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-30T13:24:22Z","receivedAt":"2006-04-30T13:24:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nInstead of editing files, you can now say\n\n\tgit pull --store junio \\\n\t\tgit://git.kernel.org/pub/scm/git/git.git next:next\n\nand next time, just\n\n\tgit pull junio\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n\tThis is what the patch series is all about.\n\n\tIf there is no interest in a feature like this, let's just forget\n\tabout the whole \"remote info in config\" thing.\n\n\tIf there is interest, I could add the same functionality to\n\tbuiltin-push.\n\n Documentation/fetch-options.txt | 6 ++++++\n git-fetch.sh | 19 +++++++++++++++++++\n git-pull.sh | 8 ++++++--\n 3 files changed, 31 insertions(+), 2 deletions(-)\n\n6bd937b0de211465e9664f8dc890fc5066617b73\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex 13f34d3..caf98de 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -16,6 +16,12 @@\n \tfetches is a descendant of ``. This option\n \toverrides that check.\n \n+-S, \\--store ::\n+\tStore the URL and the refnames in the config file so that\n+\t`git fetch ` repeats the exercise.\n+\tIf the nick exists already, edit the URL, but append the\n+\trefnames.\n+\n \\--no-tags::\n \tBy default, `git-fetch` fetches tags that point at\n \tobjects that are downloaded from the remote repository\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 280f62e..ac122da 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -15,8 +15,10 @@ no_tags=\n tags=\n append=\n force=\n+keep=\n verbose=\n update_head_ok=\n+store=\n exec=\n upload_pack=\n while case \"$#\" in 0) break ;; esac\n@@ -34,6 +36,10 @@ do\n \t-f|--f|--fo|--for|--forc|--force)\n \t\tforce=t\n \t\t;;\n+\t-S|--s|--st|--sto|--stor|--store)\n+\t\tstore=\"$2\"\n+\t\tshift\n+\t\t;;\n \t-t|--t|--ta|--tag|--tags)\n \t\ttags=t\n \t\t;;\n@@ -235,6 +241,12 @@ then\n \tfi\n fi\n \n+if test \"$store\"\n+then\n+ git-repo-config remote.\"$store\".url $remote ||\n+\tdie \"Could not store into $store\"\n+fi\n+\n fetch_main () {\n reflist=\"$1\"\n refs=\n@@ -243,6 +255,11 @@ fetch_main () {\n do\n refs=\"$refs$LF$ref\"\n \n+ if test \"$store\"\n+ then\n+\t git-repo-config remote.\"$store\".pull \"$ref\" '^$'\n+ fi\n+\n # These are relative path from $GIT_DIR, typically starting at refs/\n # but may be HEAD\n if expr \"z$ref\" : 'z\\.' >/dev/null\n@@ -381,6 +398,8 @@ fetch_main () {\n \n fetch_main \"$reflist\"\n \n+store=\n+\n # automated tag following\n case \"$no_tags$tags\" in\n '')\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 4611ae6..ab0fba3 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]\n LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'\n . git-sh-setup\n \n-strategy_args= no_summary= no_commit=\n+strategy_args= no_summary= no_commit= store=\n while case \"$#,$1\" in 0) break ;; *,-*) ;; *) break ;; esac\n do\n \tcase \"$1\" in\n@@ -31,6 +31,10 @@ do\n \t\tesac\n \t\tstrategy_args=\"${strategy_args}-s $strategy \"\n \t\t;;\n+\t-S|--store)\n+\t\tstore=\"-S $2\"\n+\t\tshift\n+\t\t;;\n \t-h|--h|--he|--hel|--help)\n \t\tusage\n \t\t;;\n@@ -43,7 +47,7 @@ do\n done\n \n orig_head=$(git-rev-parse --verify HEAD) || die \"Pulling into a black hole?\"\n-git-fetch --update-head-ok \"$@\" || exit 1\n+git-fetch --update-head-ok $store \"$@\" || exit 1\n \n curr_head=$(git-rev-parse --verify HEAD)\n if test \"$curr_head\" != \"$orig_head\"\n-- \n1.3.1.g38c00-dirty\n"},{"id":"19287","messageId":"e32h0o$15n$1@sea.gmane.org","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-30T14:19:54Z","receivedAt":"2006-04-30T14:19:54Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"There was thread about storing somewhere default branch we merge to during\npull, instead of using always surrent one. Different schemes were proposed,\nmost of them depending on the remotes configuration being available [also]\nin config file.\n\nPerhaps it would be easiest to extend existing notation in the following\nway: \n :[:]\n\nBy the way: it would be nice to have command/script to trasform freely\nbetween 'remotes/' and config file.\n\n\nP.S. I wonder if it would be difficult to implement 'include ' for\nconfig file...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19288","messageId":"BAYC1-PASMTP08069B2CE6005391A1AFF9AEB00@CEZ.ICE","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-30T14:30:46Z","receivedAt":"2006-04-30T14:30:46Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 30 Apr 2006 15:24:22 +0200 (CEST)\nJohannes Schindelin wrote:\n\n> Instead of editing files, you can now say\n> \n> \tgit pull --store junio \\\n> \t\tgit://git.kernel.org/pub/scm/git/git.git next:next\n> \n> and next time, just\n> \n> \tgit pull junio\n> \n> Signed-off-by: Johannes Schindelin \n> \n> ---\n> \n> \tThis is what the patch series is all about.\n> \n> \tIf there is no interest in a feature like this, let's just forget\n> \tabout the whole \"remote info in config\" thing.\n> \n> \tIf there is interest, I could add the same functionality to\n> \tbuiltin-push.\n\nWell I agree with you that doing something like this is important. We\nshould take this moment of moving things to the config file to correct\nthe terminology and help make things clear. We're not storing \"Pull:\"\ninformation, we're storing config/remote.$NICK.fetch data. It's really\nused just by fetch, pull just happens to call fetch.\n\nAlong that same line of reasoning, it seems more appropriate to use \ngit fetch --store ... rather than git pull --store ... to set this\ninformation. And there needs to be a way to change and delete the \nnick information, perhaps git fetch store junio \"\" would delete the\nentry. Or maybe people should just be instructed to use git-repo-config\nfor setting, changing and deleting?\n\nPull needs additional logic that allows it to merge from the proper\nlocal branch after it calls fetch. Right now it just uses whatever \nfetch sets as FETCH_HEAD. It's not clear to me what is set as \nFETCH_HEAD when multiple refs are fetched from the remote. It'll \nbe even more confusing once it's possible to fetch from multiple \nremotes at once.\n\nAs for these specific patches, it doesn't appear that your change to\nbuiltin-push allows the push variable to hold more than one remote \nrepo URI or even more than one refspec, or did I misread that?\nAlso it seems that the refspec is used from the config file even if\nthe user tries to override it by specifying an alternative on the\ncommand line.\n\nSean\n"},{"id":"19290","messageId":"Pine.LNX.4.63.0604301743370.3641@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4011","inReplyTo":"BAYC1-PASMTP08069B2CE6005391A1AFF9AEB00@CEZ.ICE","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-30T15:49:06Z","receivedAt":"2006-04-30T15:49:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 30 Apr 2006, sean wrote:\n\n> On Sun, 30 Apr 2006 15:24:22 +0200 (CEST)\n> Johannes Schindelin wrote:\n> \n> > Instead of editing files, you can now say\n> > \n> > \tgit pull --store junio \\\n> > \t\tgit://git.kernel.org/pub/scm/git/git.git next:next\n> > \n> > and next time, just\n> > \n> > \tgit pull junio\n> > \n> > Signed-off-by: Johannes Schindelin \n> > \n> > ---\n> > \n> > \tThis is what the patch series is all about.\n> > \n> > \tIf there is no interest in a feature like this, let's just forget\n> > \tabout the whole \"remote info in config\" thing.\n> > \n> > \tIf there is interest, I could add the same functionality to\n> > \tbuiltin-push.\n> \n> Well I agree with you that doing something like this is important. We\n> should take this moment of moving things to the config file to correct\n> the terminology and help make things clear. We're not storing \"Pull:\"\n> information, we're storing config/remote.$NICK.fetch data. It's really\n> used just by fetch, pull just happens to call fetch.\n\nI have no strong feelings either way.\n\n> Along that same line of reasoning, it seems more appropriate to use \n> git fetch --store ... rather than git pull --store ... to set this\n> information.\n\nBoth works.\n\n> And there needs to be a way to change and delete the nick information, \n> perhaps git fetch store junio \"\" would delete the entry. Or maybe \n> people should just be instructed to use git-repo-config for setting, \n> changing and deleting?\n\nThe latter should be done, because \"git fetch\" really is about fetching, \nnot playing games with the config.\n\n> Pull needs additional logic that allows it to merge from the proper\n> local branch after it calls fetch. Right now it just uses whatever \n> fetch sets as FETCH_HEAD. It's not clear to me what is set as \n> FETCH_HEAD when multiple refs are fetched from the remote. It'll \n> be even more confusing once it's possible to fetch from multiple \n> remotes at once.\n\nFETCH_HEAD can contain multiple refs. And I don't get the part about \nfetching from multiple remotes: my patch does not allow for that.\n\n> As for these specific patches, it doesn't appear that your change to\n> builtin-push allows the push variable to hold more than one remote \n> repo URI or even more than one refspec, or did I misread that?\n\nBut it does! Note the \"uri_[current_uri++]\" part of the patch.\n\n> Also it seems that the refspec is used from the config file even if\n> the user tries to override it by specifying an alternative on the\n> command line.\n\nNo. It is only used when there were no refspecs specified on the command \nline:\n\n if (refspec_nr == 0)\n set_refspecs((const char**)refspecs_, current_refspec);\n\n\nCiao,\nDscho\n"},{"id":"19291","messageId":"Pine.LNX.4.63.0604301749130.3641@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4011","inReplyTo":"e32h0o$15n$1@sea.gmane.org","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-30T15:52:07Z","receivedAt":"2006-04-30T15:52:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 30 Apr 2006, Jakub Narebski wrote:\n\n> There was thread about storing somewhere default branch we merge to during\n> pull, instead of using always surrent one. Different schemes were proposed,\n> most of them depending on the remotes configuration being available [also]\n> in config file.\n\nI was not following that thread closely, since it became too confusing for \nme. However, I think that my patch could be a start in that direction.\n\n> By the way: it would be nice to have command/script to trasform freely\n> between 'remotes/' and config file.\n\nIf you set the environment variable GIT_REWRITE_REMOTES to \"true\", and \ncall git-parse-remotes.sh, it will do the rewriting to the config file. \nObviously, I did not test that part of the patch all that well.\n\n> P.S. I wonder if it would be difficult to implement 'include ' for\n> config file...\n\nYou really need that?\n\nCiao,\nDscho\n"},{"id":"19292","messageId":"e32n9j$ibl$1@sea.gmane.org","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301749130.3641@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-30T16:07:01Z","receivedAt":"2006-04-30T16:07:01Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Sun, 30 Apr 2006, Jakub Narebski wrote:\n> \n>> P.S. I wonder if it would be difficult to implement 'include ' for\n>> config file...\n> \n> You really need that?\n\nNeed? Not exactly. I don't think git ever reach complexity of Apache or\nSamba configuration files, and _need_ for includes. Still dividing separate\nareas of configuration (core, user, default commands options, remotes) has\nit's merits.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19293","messageId":"BAYC1-PASMTP03034CC49FFA3042562BCBAEB00@CEZ.ICE","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301743370.3641@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-30T16:37:09Z","receivedAt":"2006-04-30T16:37:09Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 30 Apr 2006 17:49:06 +0200 (CEST)\nJohannes Schindelin wrote:\n\n\n> > the terminology and help make things clear. We're not storing \"Pull:\"\n> > information, we're storing config/remote.$NICK.fetch data. It's really\n> > used just by fetch, pull just happens to call fetch.\n>\n> I have no strong feelings either way.\n\nYeah, once you \"get\" it, it's not a problem; but it's not easy when you're\njust learning git to separate fetch and pull. It's made harder if git \ncan't even keep them straight internally. :o/\n\n[...]\n\n> The latter should be done, because \"git fetch\" really is about fetching, \n> not playing games with the config.\n\nThen we should also remove the --store option from pull and fetch. It\ncan be set with git-repo-config.\n\n> FETCH_HEAD can contain multiple refs. \n\nWhich head does git-pull then use to merge, all of them?\n\n> And I don't get the part about fetching from multiple remotes: \n> my patch does not allow for that.\n\nActually it does :o) User just needs multiple remote.$nick.url entries \nin his config.\n\n> But it does! Note the \"uri_[current_uri++]\" part of the patch.\n[...]\n> No. It is only used when there were no refspecs specified on the command \n> line:\n> \n> if (refspec_nr == 0)\n> set_refspecs((const char**)refspecs_, current_refspec);\n\nRight you are, on both counts.\n\nSean\n"},{"id":"19294","messageId":"e32pto$p3a$1@sea.gmane.org","threadId":"4011","inReplyTo":"BAYC1-PASMTP03034CC49FFA3042562BCBAEB00@CEZ.ICE","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-30T16:51:54Z","receivedAt":"2006-04-30T16:51:54Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"sean wrote:\n\n> On Sun, 30 Apr 2006 17:49:06 +0200 (CEST)\n> Johannes Schindelin wrote:\n> \n> \n>> > the terminology and help make things clear. We're not storing \"Pull:\"\n>> > information, we're storing config/remote.$NICK.fetch data. It's really\n>> > used just by fetch, pull just happens to call fetch.\n>>\n>> I have no strong feelings either way.\n> \n> Yeah, once you \"get\" it, it's not a problem; but it's not easy when you're\n> just learning git to separate fetch and pull. It's made harder if git\n> can't even keep them straight internally. :o/\n\nWell, it could also contain default head we merge to (instead of using what\nfetch set as FETCH_HEAD, usually current head while fetching), as\n\n        pull = master:origin:merger\n\n> [...]\n> \n> > The latter should be done, because \"git fetch\" really is about fetching, \n> > not playing games with the config.\n> \n> Then we should also remove the --store option from pull and fetch.  It\n> can be set with git-repo-config.\n\nThe --store option is similar to using 'git checkout -b newbranch' as a\nshortcut for 'git branch newbranch' followed by 'git checkout newbranch'.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19295","messageId":"Pine.LNX.4.63.0604301859280.3977@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4011","inReplyTo":"BAYC1-PASMTP03034CC49FFA3042562BCBAEB00@CEZ.ICE","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-04-30T17:09:18Z","receivedAt":"2006-04-30T17:09:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 30 Apr 2006, sean wrote:\n\n> On Sun, 30 Apr 2006 17:49:06 +0200 (CEST)\n> Johannes Schindelin wrote:\n> \n> \n> > The latter should be done, because \"git fetch\" really is about fetching, \n> > not playing games with the config.\n> \n> Then we should also remove the --store option from pull and fetch. It\n> can be set with git-repo-config.\n\nWell, with \"--store\", \"git fetch\" still fetches. It just happens to write \ndown -- for convenience -- the possibly long url and the refspecs.\n\n> > FETCH_HEAD can contain multiple refs. \n> \n> Which head does git-pull then use to merge, all of them?\n\nThe first one.\n\n> > And I don't get the part about fetching from multiple remotes: \n> > my patch does not allow for that.\n> \n> Actually it does :o) User just needs multiple remote.$nick.url entries \n> in his config.\n\nYou are right. But you are also wrong. The patch uses\n\n\tgit-repo-config --get remote.$nick.url\n\nwhich fails if there are more than one matching line. Note that \n\"--get-all\" is used to get _all_ remote.$nick.pull lines...\n\nBut of course, Linus \"built git-push in\" so that multiple urls are \nallowed and handled. It is probably confusing, if you can push but \ncannot fetch with the same remote information... But then, I fail to see \nhow you could possibly specify the refspecs for the different urls.\n\nCiao,\nDscho\n"},{"id":"19296","messageId":"BAYC1-PASMTP054CF113E95D45B8778DACAEB00@CEZ.ICE","threadId":"4011","inReplyTo":"e32pto$p3a$1@sea.gmane.org","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-30T17:19:36Z","receivedAt":"2006-04-30T17:19:36Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 30 Apr 2006 18:51:54 +0200\nJakub Narebski wrote:\n \n> Well, it could also contain default head we merge to (instead of using what\n> fetch set as FETCH_HEAD, usually current head while fetching), as\n> \n>         pull = master:origin:merger\n\nThen lets take a simple case; we clone a new repo, and it has:\n\n\t[remote.origin]\n\t url = git://outthere.com\n\t fetch = master:origin:master\n\t fetch = next:next\n\nAnd we create two new branches:\n\n\tgit branch br1 next ; git branch br2 next\n\nNow say that we want a bare \"git pull\" to cause a merge from \nthe \"next\" branch regardless of which new branch we have checked\nout. In the above scheme we have to do something like:\n\n\t fetch = next:next:br1:br2\n\nThat doesn't look right. It seems better to have:\n\t\n\t[branch.origin]\n\t\tdescription = \"Pristine master from Junio\"\n\t[branch.br1]\n\t\tdescription = \"blah\"\n\t\tdefaultMerge = \"next\"\n\t[branch.br2]\n\t\tdescription = \"More blah\"\n\t\tLastMerge = 03/27/2008 3am\n\t\tdefaultMerge = \"next\"\n\t\tqgitTagColor = Blue\n\n> The --store option is similar to using 'git checkout -b newbranch' as a\n> shortcut for 'git branch newbranch' followed by 'git checkout newbranch'.\n\nOkay.\n\nSean\n"},{"id":"19297","messageId":"BAYC1-PASMTP05AA5A3E9CB852B03EAC4DAEB00@CEZ.ICE","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301859280.3977@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-30T17:28:19Z","receivedAt":"2006-04-30T17:28:19Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 30 Apr 2006 19:09:18 +0200 (CEST)\nJohannes Schindelin wrote:\n\n> > Which head does git-pull then use to merge, all of them?\n> \n> The first one.\n\nWhich can be confusing since you can only specify one \"first one\"\nin a remotes file (or .git/config) yet you can pull while \nhaving any random local branch being checkout out, each with\na different merge branch being appropriate.\n\n> You are right. But you are also wrong. The patch uses\n> \n> \tgit-repo-config --get remote.$nick.url\n> \n> which fails if there are more than one matching line. Note that \n> \"--get-all\" is used to get _all_ remote.$nick.pull lines...\n> \n> But of course, Linus \"built git-push in\" so that multiple urls are \n> allowed and handled. It is probably confusing, if you can push but \n> cannot fetch with the same remote information... But then, I fail to see \n> how you could possibly specify the refspecs for the different urls.\n\nYeah, I was speaking only of git push, but see you were speaking of \nfetch.\n\nAnyway, thanks for helping me understand your proposal, it seems\nflexible enough to handle just about any case one might want to\nthrow at it.\n\nCheers,\nSean\n"},{"id":"19298","messageId":"e32ses$vs1$1@sea.gmane.org","threadId":"4011","inReplyTo":"BAYC1-PASMTP054CF113E95D45B8778DACAEB00@CEZ.ICE","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-30T17:35:10Z","receivedAt":"2006-04-30T17:35:10Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"sean wrote:\n\n> [branch.origin]\n> description = \"Pristine master from Junio\"\n\nI'd like to add\n> pristine = true\n\nand for git to warn if we try to commit to branch which is supposed to be\npristine (tracking external repository).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19309","messageId":"7v1wveya9m.fsf@assigned-by-dhcp.cox.net","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301743370.3641@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-30T22:21:57Z","receivedAt":"2006-04-30T22:21:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sun, 30 Apr 2006, sean wrote:\n>\n>> Well I agree with you that doing something like this is important. We\n>> should take this moment of moving things to the config file to correct\n>> the terminology and help make things clear. We're not storing \"Pull:\"\n>> information, we're storing config/remote.$NICK.fetch data. It's really\n>> used just by fetch, pull just happens to call fetch.\n>\n> I have no strong feelings either way.\n\nI have a strong feeling that naming them \"Pull: \" was a mistake\nto begin with and they should have been called \"Fetch: \" ;-).\n\n>> Along that same line of reasoning, it seems more appropriate to use \n>> git fetch --store ... rather than git pull --store ... to set this\n>> information.\n>\n> Both works.\n\nI'd rather not see --store added to either fetch nor pull.\n\nWhile I would agree --store would appear to be a convenient\nshort-hand for first timers, I strongly suspect this will cause\nmore confusion and complexity down the line. If a topic that\ninterests you appears today at the remote, and you start\nfollowing it by adding --store when you fetch from it, and later\nwhen the topic disappears at the remote in two weeks because it\nis fully cooked and merged into somewhere else, you would need\nto have a way to --unstore it somehow, and at that time the\nfirst timer needs to learn repo-config to deal with that failure\nanyway. Or you need to teach git-fetch that fetch failure of a\nbranch is actually OK as long as all of the following holds\ntrue:\n\n - the branch was added with --store in the past; the user is\n not actively asking for it in the current request, saying \"I\n want to fetch from there THIS TIME\".\n\n - the fetch failed only because the remote repository droped\n the branch (IOW you need to tell connection and protocol\n failure from \"branch disappeared\"case),\n\n - the fetch is not being done to merge it into the current branch,\n\nor something complicated like that, and unstore it automatically\nfor the user.\n\nOther than that, I do not have strong feelings against using the\nstandard .git/config to store what we store in .git/remotes/*\ncurrently, and I also suspect doing so would be a prerequiste\nfirst step to do \"per local branch configuration\" (e.g. \"when on\nthis branch, merge from this branch by default\") some people\nseem to want.\n"},{"id":"19357","messageId":"7v3bfsol9j.fsf@assigned-by-dhcp.cox.net","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-02T08:59:04Z","receivedAt":"2006-05-02T08:59:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> \tThis is what the patch series is all about.\n>\n> \tIf there is no interest in a feature like this, let's just forget\n> \tabout the whole \"remote info in config\" thing.\n\nWell, I took the liberty of adjusting the first one in the\nseries and tonight's \"pu\" has that one and the second one.\nI haven't touched the third one yet, though.\n\nAbout the second one, I think it probably is a good idea to\nrename the \"refspec used for fetch\" as Sean suggested earlier.\nI do not like that hidden environment variable that sits in the\ncommand I use everyday, waiting to be triggered to update my\n.config file, possibly by my PEBCAK mistake when I did not want\nit to do so.\n\nI am not quite sure what this bit is about in the second one:\n\n sed -n \\\n -e \"s/^URL: /remote.$name.url . /p\" \\\n -e \"s/^Pull: /remote.$name.pull ^$ /p\" \\\n -e \"s/^Push: /remote.$name.push ^$ /p\" \\\n\t< \"$f\"\n\nI am getting this out of the above:\n\n remote.ko.url . xxx.kernel.org:/pub/scm/git/git.git/\n remote.ko.pull ^$ master:refs/tags/ko-master\n remote.ko.pull ^$ next:refs/tags/ko-next\n remote.ko.pull ^$ +pu:refs/tags/ko-pu\n remote.ko.pull ^$ maint:refs/tags/ko-maint\n remote.ko.push ^$ heads/master\n remote.ko.push ^$ heads/next\n remote.ko.push ^$ +heads/pu\n remote.ko.push ^$ heads/maint\n\nbut I suspect that is not what you intended...\n\nI think easy conversion tool is a good idea, but I would sleep\nbetter if it is outside of git-fetch/push chain and is available\nelsewhere, perhaps in contrib/ area.\n\nOn a slightly related topic, I think my aversion to your \"push\nremotes into config\" series the last time was primarily because\nI do not trust repo-config. Reading an already built config\nseems to work OK and I do not worry too much, but I am still\nwary of letting it write. Typing \"git repo-config\" in a freshly\ninitialized empty repository seems to segfault, which does not\nhelp my confidence level either.\n"},{"id":"19365","messageId":"Pine.LNX.4.63.0605021422520.7051@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4011","inReplyTo":"7v3bfsol9j.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-02T12:42:14Z","receivedAt":"2006-05-02T12:42:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 May 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > \tThis is what the patch series is all about.\n> >\n> > \tIf there is no interest in a feature like this, let's just forget\n> > \tabout the whole \"remote info in config\" thing.\n> \n> Well, I took the liberty of adjusting the first one in the\n> series and tonight's \"pu\" has that one and the second one.\n> I haven't touched the third one yet, though.\n\nI don't think it is worth introducing yet another way to specify \nshort-cuts for remote information, if there is not at least one problem \nwhich can get solved easier with it than with the other two ways.\n\n> About the second one, I think it probably is a good idea to\n> rename the \"refspec used for fetch\" as Sean suggested earlier.\n\nOkay.\n\n> I do not like that hidden environment variable that sits in the\n> command I use everyday, waiting to be triggered to update my\n> .config file, possibly by my PEBCAK mistake when I did not want\n> it to do so.\n\nI will refactor it.\n\n> I am not quite sure what this bit is about in the second one:\n> \n> sed -n \\\n> -e \"s/^URL: /remote.$name.url . /p\" \\\n> -e \"s/^Pull: /remote.$name.pull ^$ /p\" \\\n> -e \"s/^Push: /remote.$name.push ^$ /p\" \\\n> \t< \"$f\"\n\nThat is obviously wrong. Will fix while refactoring.\n\n> I think easy conversion tool is a good idea, but I would sleep\n> better if it is outside of git-fetch/push chain and is available\n> elsewhere, perhaps in contrib/ area.\n\nWill do.\n\n> On a slightly related topic, I think my aversion to your \"push\n> remotes into config\" series the last time was primarily because\n> I do not trust repo-config. Reading an already built config\n> seems to work OK and I do not worry too much, but I am still\n> wary of letting it write. Typing \"git repo-config\" in a freshly\n> initialized empty repository seems to segfault, which does not\n> help my confidence level either.\n\nI fixed this error (see separate patch). This was reintroduced by \ncarelessly checking argv[1] for \"--list\" and \"-l\", even if argc < 2. I am \nsorry that I did not review that patch.\n\nI tried to make really sure that repo-config works as expected by \nintroducing quite a few test cases into t1300, but evidently I forgot to \ncheck for things that do not usually break, like calling without \narguments. This is fixed with the patch I just sent out.\n\nThis patch also introduces the \"--get-regexp\" flag to repo-config, which \nmakes up for the lacking shell wildcards (you can ask questions like: \nwhich keys in the config end in \"coatl\"?).\n\nAs for the trust in repo-config writing the config: it is all done by \ncalling git_config_set() or git_config_set_multivar(), which you use \nyourself to set core.repositoryformatversion, among other values.\n\nCiao,\nDscho\n"},{"id":"19397","messageId":"7vmze0hrlj.fsf@assigned-by-dhcp.cox.net","threadId":"4011","inReplyTo":"Pine.LNX.4.63.0605021422520.7051@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 3/3] fetch: optionally store the current remote information in the config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-03T00:36:24Z","receivedAt":"2006-05-03T00:36:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Well, I took the liberty of adjusting the first one in the\n>> series and tonight's \"pu\" has that one and the second one.\n>> I haven't touched the third one yet, though.\n>\n> I don't think it is worth introducing yet another way to specify \n> short-cuts for remote information, if there is not at least one problem \n> which can get solved easier with it than with the other two ways.\n\nI think the biggest contribution this series might bring in is\nto send a message that we would want to have things in config,\nnot outside -- otherwise people might be tempted to do \"while on\nthis branch use this remote to fetch/pull from by default\"\noutside config (perhaps abusing .git/branches, which _is_ per\nbranch configuration).\n\n>> I do not like that hidden environment variable that sits in the\n>> command I use everyday, waiting to be triggered to update my\n>> .config file, possibly by my PEBCAK mistake when I did not want\n>> it to do so.\n>\n> I will refactor it.\n\nThanks.\n\n> I fixed this error (see separate patch). This was reintroduced by \n> carelessly checking argv[1] for \"--list\" and \"-l\", even if argc < 2.\n\nThanks.\n\n> As for the trust in repo-config writing the config: it is all done by \n> calling git_config_set() or git_config_set_multivar(), which you use \n> yourself to set core.repositoryformatversion, among other values.\n\nSince that happens in a freshly created empty config, I do not\nhave to have a high confidence for that case, compared to the\ncase it has to muck with random configuration files people\nalready have populated with arbitrary gunk. In any case, I\nhaven't seen breakage myself recently so hopefully it is safe\nenough now ;-).\n"}]}