{"thread":{"id":"2631","subject":"[RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","startedAt":"2005-11-21T13:56:41Z","lastAt":"2005-11-29T06:04:07Z","messageCount":21,"participants":["Johannes Schindelin","Josef Weidendorfer","Andreas Ericsson","Junio C Hamano","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12433","messageId":"Pine.LNX.4.63.0511211455120.13775@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2631","inReplyTo":null,"subject":"[RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-21T13:56:41Z","receivedAt":"2005-11-21T13:56:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWith this patch, git automatically extracts the information from \n.git/branches and .git/remotes, puts it into .git/config, and renames the \ndirectories to .git/branches.old and .git/remotes.old, respectively.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\n---\n\n git-parse-remote.sh |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 53 insertions(+), 0 deletions(-)\n\napplies-to: 239817500e3556e8541d3b2b8257802c10da85c2\n69062e3473f9f3cafe33954d9b995da89f6d9898\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex cd976da..0d603ac 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -2,6 +2,59 @@\n \n . git-sh-setup\n \n+if [ -d \"$GIT_DIR\"/branches ]; then\n+\techo \"Rewriting $GIT_DIR/branches\" >&2\n+\terror=0\n+\t# rewrite into config\n+\t{\n+\t\tcd \"$GIT_DIR\"/branches\n+\t\tls | while read f; do\n+\t\t\tname=$(echo -n \"$f\" | tr -c \"A-Za-z0-9\" \".\")\n+\t\t\tsed \\\n+\t\t\t-e \"s/^/remote.$name.url /\" \\\n+\t\t\t-e \"s/#\\(.*\\)$/\\nremote.$name.pull \\1/\" \\\n+\t\t\t< \"$f\"\n+\t\tdone\n+\t\techo done\n+\t} | while read key value; do\n+\t\tcase $key in\n+\t\tdone)\n+\t\t\tif [ $error = 0 ]; then\n+\t\t\t\tmv \"$GIT_DIR\"/branches \"$GIT_DIR\"/branches.old\n+\t\t\tfi ;;\n+\t\t*)\n+\t\t\tgit-config-set $key \"$value\" || error=1 ;;\n+\t\tesac\n+\tdone\n+fi\n+\n+if [ -d \"$GIT_DIR\"/remotes ]; then\n+\techo \"Rewriting $GIT_DIR/remotes\" >&2\n+\terror=0\n+\t# rewrite into config\n+\t{\n+\t\tcd \"$GIT_DIR\"/remotes\n+\t\tls | while read f; do\n+\t\t\tname=$(echo -n \"$f\" | tr -c \"A-Za-z0-9\" \".\")\n+\t\t\tsed -n \\\n+\t\t\t-e \"s/^URL: /remote.$name.url . /p\" \\\n+\t\t\t-e \"s/^Pull: /remote.$name.pull ^$ /p\" \\\n+\t\t\t-e \"s/^Push: /remote.$name.push ^$ /p\" \\\n+\t\t\t< \"$f\"\n+\t\tdone\n+\t\techo done\n+\t} | while read key regex value; do\n+\t\tcase $key in\n+\t\tdone)\n+\t\t\tif [ $error = 0 ]; then\n+\t\t\t\tmv \"$GIT_DIR\"/remotes \"$GIT_DIR\"/remotes.old\n+\t\t\tfi ;;\n+\t\t*)\n+\t\t\tgit-config-set $key \"$value\" $regex || error=1 ;;\n+\t\tesac\n+\tdone\n+fi\n+\n get_data_source () {\n \tcase \"$1\" in\n \t*/*)\n---\n0.99.9.GIT\n"},{"id":"12440","messageId":"200511211644.16789.Josef.Weidendorfer@gmx.de","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511211455120.13775@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-21T15:44:16Z","receivedAt":"2005-11-21T15:44:16Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 21 November 2005 14:56, Johannes Schindelin wrote:\n> With this patch, git automatically extracts the information from \n> .git/branches and .git/remotes, puts it into .git/config, and renames the \n> directories to .git/branches.old and .git/remotes.old, respectively.\n\nPlease... don't trash .git/branches.\nThis is about Cogito, not about Git. You will render every repository cloned\nwith Cogito useless, as it expects a per-branch configuration with the same\nname as heads.\n\nThe part about .git/branches has to be sent to Pasky, not Junio. \n\nJosef\n"},{"id":"12441","messageId":"Pine.LNX.4.63.0511211653420.2569@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2631","inReplyTo":"200511211644.16789.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-21T15:57:07Z","receivedAt":"2005-11-21T15:57:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Nov 2005, Josef Weidendorfer wrote:\n\n> On Monday 21 November 2005 14:56, Johannes Schindelin wrote:\n> > With this patch, git automatically extracts the information from \n> > .git/branches and .git/remotes, puts it into .git/config, and renames the \n> > directories to .git/branches.old and .git/remotes.old, respectively.\n> \n> Please... don't trash .git/branches.\n> This is about Cogito, not about Git. You will render every repository cloned\n> with Cogito useless, as it expects a per-branch configuration with the same\n> name as heads.\n> \n> The part about .git/branches has to be sent to Pasky, not Junio. \n\nI was aware that .git/branches was introduced by Pasky, but as it is \nhandled in git-parse-remote.sh, I thought that it may be a bit more \ngeneral than just cogito.\n\nAnyways, I sent this out as an *RFC*, but the \"C\" obviously stands for \n\"Comments\"...\n\nWhat do people say? Is it useless to move that information into the \nconfig, where it can be queried/replaced/set/removed by the config \"API\", \nor should we continue with two incompatible ad-hoc formats? (If that \nsounds biased, it was not meant to be.)\n\nCiao,\nDscho\n"},{"id":"12445","messageId":"200511211725.21642.Josef.Weidendorfer@gmx.de","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511211653420.2569@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-21T16:25:21Z","receivedAt":"2005-11-21T16:25:21Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 21 November 2005 16:57, Johannes Schindelin wrote:\n> > The part about .git/branches has to be sent to Pasky, not Junio. \n> \n> I was aware that .git/branches was introduced by Pasky, but as it is \n> handled in git-parse-remote.sh, I thought that it may be a bit more \n> general than just cogito.\n\nAFAIK, Cogito introduced it, and Git used it in the wrong way. All files\nin .git/branches map 1:1 to a local head (perhaps not really existing).\nGit misused this information by using a head name as shortcut for a\nremote repository - which still leads to quite some confusion:\nIn repositories cloned by Cogito you now have a \"origin\" head, and\nautomatically have a repository shortcut \"origin\", too. The same name is\nused for different kinds of objects - IMHO quite bad.\n\nThe best thing is to simply remove .git/branches parsing in git at all.\n \n> Anyways, I sent this out as an *RFC*, but the \"C\" obviously stands for \n> \"Comments\"...\n\nI think that putting .git/remotes info into .git/config is nice.\nAnd I also think that putting .git/branches info into .git/config is a nice\nthing.\nIf .git/branches/origin contains \"http://www.kernel.org/pub/scm/git/git.git#todo\",\nthis should map to\n\n[head.origin]\n  fetchurl = http://www.kernel.org/pub/scm/git/git.git\n  fetchhead = todo\n\nThe problem here is that heads can have spaces, \".\" and \"/\" in their name.\n\n> What do people say? Is it useless to move that information into the \n> config, where it can be queried/replaced/set/removed by the config \"API\", \n> or should we continue with two incompatible ad-hoc formats? (If that \n> sounds biased, it was not meant to be.)\n\nCogito does not have per-repository configuration (e.g. like this \"shortcut\"\nthing), but only about per-head configuration. In this way, the information\nin .git/branches is quite different from the one in .git/remotes.\n\nJosef\n\n> \n> Ciao,\n> Dscho\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n> \n"},{"id":"12446","messageId":"4381F727.2090005@op5.se","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511211653420.2569@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-21T16:34:47Z","receivedAt":"2005-11-21T16:34:47Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> \n> What do people say? Is it useless to move that information into the \n> config, where it can be queried/replaced/set/removed by the config \"API\", \n\nYou're thinking the wrong way around. \"Is it useless so we should \nrefrain?\" is not the same as \"is it useful enough to do?\".\n\n\n> or should we continue with two incompatible ad-hoc formats? (If that \n> sounds biased, it was not meant to be.)\n> \n\nI don't use Cogito myself so I'm not aware of what incompatibilities \nthere are. However, it's a user-friendliness layer, so it can choose to \ndo things differently if it wants to, but changing how the plumbing \nworks to match the porcelain seems wrong to me.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12488","messageId":"7vpsotmych.fsf@assigned-by-dhcp.cox.net","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511211653420.2569@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-21T22:26:38Z","receivedAt":"2005-11-21T22:26:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Mon, 21 Nov 2005, Josef Weidendorfer wrote:\n>\n>> On Monday 21 November 2005 14:56, Johannes Schindelin wrote:\n>> > With this patch, git automatically extracts the information from \n>> > .git/branches and .git/remotes, puts it into .git/config, and renames the \n>> > directories to .git/branches.old and .git/remotes.old, respectively.\n>> \n>> Please... don't trash .git/branches.\n>> This is about Cogito, not about Git. You will render every repository cloned\n>> with Cogito useless, as it expects a per-branch configuration with the same\n>> name as heads.\n>> \n> I was aware that .git/branches was introduced by Pasky, but as it is \n> handled in git-parse-remote.sh, I thought that it may be a bit more \n> general than just cogito.\n\nWhat Josef said is correct in that I was not aware of the fact\nthat Cogito branches/ are *per-branch* configuration when I did\nparse-remote.  remotes/ are deliberately *per-remote*\nconfiguration, because it is more efficient when you are\ndownloading more than one refs from the same remote over a\ngit-aware protocol.  Arguably, it is optimizing for the wrong\ncase, because it may well be a minority case to keep track of\nmore than one remote head.  I dunno.\n\nI am not sure if it is a good idea to automatically convert what\nis stored in .git/branches to .git/remotes (or the equivalent of\nthe latter in .git/config), but if somebody wanted to do it, the\nright thing would be:\n\n - grab the URL without optional fragment '#rembranch' part from\n   all branches/* file;\n\n - group the ones that fetch from the same URL into one\n   remotes/$file (what to call that file is very debatable\n   because the original branches/* is in different namespace and\n   we cannot tell what the user wants to call the remote),\n   giving appropriate head mapping.  branches/$branch file with\n   the fragment part '#$rembranch' translates to \"Pull:\n   $rembranch:$branch\".\n"},{"id":"12794","messageId":"20051127125945.GD22159@pasky.or.cz","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511211455120.13775@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-27T12:59:45Z","receivedAt":"2005-11-27T12:59:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Nov 21, 2005 at 02:56:41PM CET, I got a letter\nwhere Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...\n> With this patch, git automatically extracts the information from \n> .git/branches and .git/remotes, puts it into .git/config, and renames the \n> directories to .git/branches.old and .git/remotes.old, respectively.\n> \n> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n\nPlease don't do so for .git/branches, that is primarily Cogito thing\nand you will make it impossible to use GIT and Cogito on the same\nrepository - the moment the user uses git-pull on the repository, his\nCogito configuration is trashed and he has even no reliable undo\nmechanism.\n\nAnd in another thread (we have too many threads for this subject ;-)\nI've tried to explain that branches and remotes are different concepts,\nwhich live in different namespaces and have different semantics, so\nrewriting branches to remotes is a bad idea anyway.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"12836","messageId":"Pine.LNX.4.63.0511280248020.12343@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2631","inReplyTo":"20051127125945.GD22159@pasky.or.cz","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-28T01:52:08Z","receivedAt":"2005-11-28T01:52:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 Nov 2005, Petr Baudis wrote:\n\n> I've tried to explain that branches and remotes are different concepts,\n\nWell, no. They aren't. The \"branches\" concept is a proper special case of \nthe \"remotes\" concept.\n\nBut what the heck, I don't care what you eventually use.\n\nI only realized that we -- in the good tradition of UNIX -- have many \ndifferent formats for different configurations: Some configurations are in \n.gitignore, some are in .git/branches/, some in .git/remotes/, some in \n.git/config, and even some in environment variables!\n\nIf everybody says that this should stay so, I'll just shut up.\n\nHth,\nDscho\n"},{"id":"12841","messageId":"7vfyph1ebq.fsf@assigned-by-dhcp.cox.net","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511280248020.12343@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-28T06:22:49Z","receivedAt":"2005-11-28T06:22:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> I only realized that we -- in the good tradition of UNIX -- have many \n> different formats for different configurations: Some configurations are in \n> .gitignore, some are in .git/branches/, some in .git/remotes/, some in \n> .git/config, and even some in environment variables!\n\nCan you live with something like this?\n\n - we will add new ones to config, now we have it;\n\n - we will not deprecate existing ones outside of config for some time;\n\n - we will not duplicate/move existing ones into config at least\n   for now to keep our work less complicated;\n\n - we would revisit deprecating things outside config file\n   sometime later after 1.0 stabilizes, and that's when we will\n   talk about moving these things into config.\n"},{"id":"12850","messageId":"438AC32E.5010100@op5.se","threadId":"2631","inReplyTo":"7vfyph1ebq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-28T08:43:26Z","receivedAt":"2005-11-28T08:43:26Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> \n>>I only realized that we -- in the good tradition of UNIX -- have many \n>>different formats for different configurations: Some configurations are in \n>>.gitignore, some are in .git/branches/, some in .git/remotes/, some in \n>>.git/config, and even some in environment variables!\n> \n> \n> Can you live with something like this?\n> \n>  - we will add new ones to config, now we have it;\n> \n\nI'd still like to see git-repo-config and git-user-config. Otherwise \nwe'll need to continue having user-based environment variables \n(GIT_COMMITTER_IDENT and friends).\n\n> \n>  - we would revisit deprecating things outside config file\n>    sometime later after 1.0 stabilizes, and that's when we will\n>    talk about moving these things into config.\n> \n\nGIT_DIR and GIT_OBJECT_DIR must remain environment variables (or command \nline arguments) more or less indefinitely. It doesn't make sense to keep \nthem any other way.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12853","messageId":"7vpsolxhg8.fsf@assigned-by-dhcp.cox.net","threadId":"2631","inReplyTo":"438AC32E.5010100@op5.se","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-28T09:14:15Z","receivedAt":"2005-11-28T09:14:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> I'd still like to see git-repo-config and git-user-config. Otherwise \n> we'll need to continue having user-based environment variables \n> (GIT_COMMITTER_IDENT and friends).\n\nSince .git/config is not shared across repositories even on\nclone (and is deliberately so), \"git-repo-config user.name\" is\nfor you to set *your* name.\n\nHaving said that, GIT_COMMITTER_IDENT and friends are there to\nstay, because that is how you override what you get from the\nconfig file per commit, which is needed for people playing the\nintegrator role.  When one is playing an individual developer\nrole, user.name or even not having any and relying on GECOS is\noften good enough.\n"},{"id":"12863","messageId":"200511281359.04741.Josef.Weidendorfer@gmx.de","threadId":"2631","inReplyTo":"438AC32E.5010100@op5.se","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-28T12:59:04Z","receivedAt":"2005-11-28T12:59:04Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 28 November 2005 09:43, Andreas Ericsson wrote:\n> Junio C Hamano wrote:\n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> > \n> > \n> >>I only realized that we -- in the good tradition of UNIX -- have many \n> >>different formats for different configurations: Some configurations are in \n> >>.gitignore, some are in .git/branches/, some in .git/remotes/, some in \n> >>.git/config, and even some in environment variables!\n> > \n> > \n> > Can you live with something like this?\n> > \n> >  - we will add new ones to config, now we have it;\n\nIt is not really fitting for all purposes (eg. syntax restrictions).\n\n\n> I'd still like to see git-repo-config and git-user-config. Otherwise \n> we'll need to continue having user-based environment variables \n> (GIT_COMMITTER_IDENT and friends).\n\nIn fact, it would be nice to have different \"config levels\" supported\nby git. I can imagine:\n(1) user config (typically in $HOME/.gitrc)\n(2) project config (in .git/project.conf)\n(3) repository config; i.e. separate for every clone\n    (in .git/repo.conf instead of .git/config as of now?)\nEven for one such level, it would be nice to be able to seperate the\nconfig into multiple files; ie. remote config in a .git/remote.conf,\nand a porcelain should be able to have its own config files, but still\nusing git's config parser.\n\nTo allow for this, git_config() should not be hardcoded to only\nread .git/config, but perhaps a list of files in environment variable\nGIT_CONFIG_FILES.\n\nFor (2), git-clone should copy some files, e.g. the .git/project.conf\nor .git/info/exclude. But project config probably should be kept\nup to date among all repositories for a project, i.e. it should be\nversion controlled itself, but independent from the project.\nWe could use a project config head .git/refs/projectconfig for this;\nof course post-1.0 material.\n\n\nJosef\n"},{"id":"12866","messageId":"438B021F.5030204@op5.se","threadId":"2631","inReplyTo":"200511281359.04741.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-28T13:11:59Z","receivedAt":"2005-11-28T13:11:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> \n> To allow for this, git_config() should not be hardcoded to only\n> read .git/config, but perhaps a list of files in environment variable\n> GIT_CONFIG_FILES.\n> \n\n$HOME/.gitrc:$GIT_DIR/conf/*\n\nAll files could support the freestanding \"include\" syntax.\n\n> For (2), git-clone should copy some files, e.g. the .git/project.conf\n> or .git/info/exclude. But project config probably should be kept\n> up to date among all repositories for a project, i.e. it should be\n> version controlled itself, but independent from the project.\n> We could use a project config head .git/refs/projectconfig for this;\n> of course post-1.0 material.\n\n\nIt would be very nifty to have some files that can hold maintainer-like \nvariables (like upstream email address for patches).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12868","messageId":"20051128134808.GQ22159@pasky.or.cz","threadId":"2631","inReplyTo":"200511281359.04741.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-28T13:48:08Z","receivedAt":"2005-11-28T13:48:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> (2) project config (in .git/project.conf)\n\nWhat are you going to keep in it? There isn't much of stuff which is not\nper-user or per-instance. I can't think of anything now, but there is no\nlist of configuration variables to check yet.\n\n(Upstream maintainer email is interesting, OTOH it alone doesn't seem to\njustify the mechanism by itself; also, the upstreams may be different\nbased on where you cloned the project from, etc.)\n\n> For (2), git-clone should copy some files, e.g. the .git/project.conf\n> or .git/info/exclude. But project config probably should be kept\n> up to date among all repositories for a project, i.e. it should be\n> version controlled itself, but independent from the project.\n> We could use a project config head .git/refs/projectconfig for this;\n> of course post-1.0 material.\n\nIf you still want per-project config, why should it be independent from\nthe project? Actually, like you have .gitignore, having something like\n.gitconfig in project root would be by far the simplest - if you want\nseparate head, your merging and stuff gets quite more complicated, as\nwell as actually branching the project config, etc.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"12870","messageId":"20051128135915.GR22159@pasky.or.cz","threadId":"2631","inReplyTo":"Pine.LNX.4.63.0511280248020.12343@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-28T13:59:15Z","receivedAt":"2005-11-28T13:59:15Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Nov 28, 2005 at 02:52:08AM CET, I got a letter\nwhere Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...\n> On Sun, 27 Nov 2005, Petr Baudis wrote:\n> \n> > I've tried to explain that branches and remotes are different concepts,\n> \n> Well, no. They aren't. The \"branches\" concept is a proper special case of \n> the \"remotes\" concept.\n\nYes, but precisely what I want to do is to avoid (most of) the \"added\nvalue\" of the remotes concept, if you will. Also, it really is a\ndifferent namespace than branches (while branches share the same\nnamespace with heads); I can try to make the namespaces match, but when\nthey suddenly won't, you are in big mess.\n\n> But what the heck, I don't care what you eventually use.\n> \n> I only realized that we -- in the good tradition of UNIX -- have many \n> different formats for different configurations: Some configurations are in \n> .gitignore, some are in .git/branches/, some in .git/remotes/, some in \n> .git/config, and even some in environment variables!\n> \n> If everybody says that this should stay so, I'll just shut up.\n\nAs I said, I don't care much if this moves to the git configuration\nfile, but please don't merge it with the remotes.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"12872","messageId":"200511281532.36054.Josef.Weidendorfer@gmx.de","threadId":"2631","inReplyTo":"438B021F.5030204@op5.se","subject":"Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-28T14:32:35Z","receivedAt":"2005-11-28T14:32:35Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 28 November 2005 14:11, Andreas Ericsson wrote:\n> Josef Weidendorfer wrote:\n> > \n> > To allow for this, git_config() should not be hardcoded to only\n> > read .git/config, but perhaps a list of files in environment variable\n> > GIT_CONFIG_FILES.\n> > \n> \n> $HOME/.gitrc:$GIT_DIR/conf/*\n\nYes, perhaps with this as default...\n\n> All files could support the freestanding \"include\" syntax.\n\nBetter run cpp on the config files before loading ;-)\nOr provide a hook which returns the config on stdout.\nThe default for .git/hooks/config would be\n\n\tcat $GIT_DIR/config\n\nHmm... this was only meant to be a joke; but now I actually think\nthis is a nice idea as basic configuration mechanism of git plumbing.\n\nJosef\n"},{"id":"12876","messageId":"200511281603.54433.Josef.Weidendorfer@gmx.de","threadId":"2631","inReplyTo":"20051128134808.GQ22159@pasky.or.cz","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-28T15:03:54Z","receivedAt":"2005-11-28T15:03:54Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 28 November 2005 14:48, Petr Baudis wrote:\n> Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter\n> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > (2) project config (in .git/project.conf)\n> \n> What are you going to keep in it? There isn't much of stuff which is not\n> per-user or per-instance. I can't think of anything now, but there is no\n> list of configuration variables to check yet.\n\nProject global configurations could be:\n- .git/info\n- .git/hooks\n- default for encoding of commit messages\n- relationship of public project branches (perhaps access rights)\n- project description, maintainers, public branch descriptions\n- central repository URL\n- ...\n\n> (Upstream maintainer email is interesting, OTOH it alone doesn't seem to\n> justify the mechanism by itself; also, the upstreams may be different\n> based on where you cloned the project from, etc.)\n\nHmm.. this even could be seen as another level: origin specific\n\n> > For (2), git-clone should copy some files, e.g. the .git/project.conf\n> > or .git/info/exclude. But project config probably should be kept\n> > up to date among all repositories for a project, i.e. it should be\n> > version controlled itself, but independent from the project.\n> > We could use a project config head .git/refs/projectconfig for this;\n> > of course post-1.0 material.\n> \n> If you still want per-project config, why should it be independent from\n> the project? Actually, like you have .gitignore, having something like\n> .gitconfig\n\nThat doesn't work well with configuration which should be global to the\nwhole history of the original project, e.g. .git/info/exclude, or maintainer\ninformation.\n\n> in project root would be by far the simplest - if you want \n> separate head, your merging and stuff gets quite more complicated, as\n> well as actually branching the project config, etc.\n\nProject configuration probably always should be up to date, so:\n* always update when fetching/pulling project branches\n* always push when pushing project branches\n\nJosef\n"},{"id":"12877","messageId":"Pine.LNX.4.63.0511281620520.11052@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2631","inReplyTo":"200511281532.36054.Josef.Weidendorfer@gmx.de","subject":"Re: Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-28T15:26:31Z","receivedAt":"2005-11-28T15:26:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Nov 2005, Josef Weidendorfer wrote:\n\n> On Monday 28 November 2005 14:11, Andreas Ericsson wrote:\n> > Josef Weidendorfer wrote:\n> > > \n> > > To allow for this, git_config() should not be hardcoded to only\n> > > read .git/config, but perhaps a list of files in environment variable\n> > > GIT_CONFIG_FILES.\n> > > \n> > \n> > $HOME/.gitrc:$GIT_DIR/conf/*\n> \n> Yes, perhaps with this as default...\n> \n> > All files could support the freestanding \"include\" syntax.\n> \n> Better run cpp on the config files before loading ;-)\n> Or provide a hook which returns the config on stdout.\n> The default for .git/hooks/config would be\n> \n> \tcat $GIT_DIR/config\n> \n> Hmm... this was only meant to be a joke; but now I actually think\n> this is a nice idea as basic configuration mechanism of git plumbing.\n\nThe longer I read this thread the more I *positively* *hate* to have \nstarted it.\n\nPeople, I wanted simplification. And you ask instead for every feature and \nhis dog, and could I have fries with that?\n\nKISS!\n\nI *don't* want split config files. Why? Because it buys you only confusion \nand complication. If you want to group variables, do so with sections (BTW \nthat's what they were designed for).\n\nI am perfectly okay when somebody says that I should leave things as they \nare and not fsck around with configuration. The impression I get is that \nyou want to force me to admit that I was wrong from the start.\n\nCiao,\nDscho\n"},{"id":"12883","messageId":"Pine.LNX.4.63.0511281728110.11362@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2631","inReplyTo":"7vfyph1ebq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-28T16:29:58Z","receivedAt":"2005-11-28T16:29:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 Nov 2005, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > I only realized that we -- in the good tradition of UNIX -- have many \n> > different formats for different configurations: Some configurations are in \n> > .gitignore, some are in .git/branches/, some in .git/remotes/, some in \n> > .git/config, and even some in environment variables!\n> \n> Can you live with something like this?\n> \n>  - we will add new ones to config, now we have it;\n> \n>  - we will not deprecate existing ones outside of config for some time;\n> \n>  - we will not duplicate/move existing ones into config at least\n>    for now to keep our work less complicated;\n> \n>  - we would revisit deprecating things outside config file\n>    sometime later after 1.0 stabilizes, and that's when we will\n>    talk about moving these things into config.\n\nI can very well live with this!\n\nAs a first step, we could support getting the remote information from \n.git/config after testing .git/branches/ and .git/remotes/?\n\nCiao,\nDscho\n"},{"id":"12882","messageId":"Pine.LNX.4.63.0511281731490.11362@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2631","inReplyTo":"20051128135915.GR22159@pasky.or.cz","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-28T16:33:35Z","receivedAt":"2005-11-28T16:33:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Nov 2005, Petr Baudis wrote:\n\n> As I said, I don't care much if this moves to the git configuration\n> file, but please don't merge it with the remotes.\n\nAs you have made quite clear, it is for *you* to decide if you want to \nmove .git/branches/ anywhere. I wrote the automatic conversion only to \ndemonstrate how I thought how a migration *could* be done painlessly, if \nthe information goes into .git/config.\n\nHth,\nDscho\n"},{"id":"12912","messageId":"7v4q5wng6g.fsf@assigned-by-dhcp.cox.net","threadId":"2631","inReplyTo":"200511281359.04741.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-29T06:04:07Z","receivedAt":"2005-11-29T06:04:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n>> >  - we will add new ones to config, now we have it;\n>\n> It is not really fitting for all purposes (eg. syntax restrictions).\n\nOK; please read it as \"when able\".\n"}]}