{"thread":{"id":"28081","subject":"Overriding ~/.gitconfig using GIT_CONFIG","startedAt":"2011-08-12T15:38:18Z","lastAt":"2011-09-05T19:29:50Z","messageCount":12,"participants":["Richard Purdie","Junio C Hamano","David Aguilar","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"173406","messageId":"1313163498.14274.505.camel@rex","threadId":"28081","inReplyTo":null,"subject":"Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2011-08-12T15:38:18Z","receivedAt":"2011-08-12T15:38:18Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"I work on build systems which need to check code out of source control\nsystems like git. I need to do this in a way in which there are not\noutside influences and a user's $HOME/.gitconfig file can contain things\nwe don't want. I therefore need a way to disable it.\n\nLooking through the manuals/code, it suggests I should be able to do:\n\nGIT_CONFIG=/dev/null git XXX\n\nand all should work happily. It doesn't though. As an example, with a\n~/.gitconfig, \"GIT_CONFIG=/dev/null git fetch --all\" is clearly\naccessing the file in ~ and then acting upon it.\n\nI've searched through the code and whilst config_exclusive_filename\nappears to be the magic variable that should get set when I set\nGIT_CONFIG in the environment, nothing ever sets it apart from within a\ngit-config command.\n\nThe following patch sets the variable from the environment initially and\nshould do what the code intends if I read understand it correctly. Its\nnot ideal for my use case as I actually want the repo_config and only\nthe repo config to be used but I can live with setting GIT_CONFIG to\npoint at it.\n\nAlternative ideas welcome, I've considered changing $HOME but that seems\na little too ugly and likely to cause other problems.\n\nSigned-off-by: Richard Purdie \n\ndiff --git a/config.c b/config.c\nindex d06fb19..19e7565 100644\n--- a/config.c\n+++ b/config.c\n@@ -860,6 +860,8 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)\n \tint ret = 0, found = 0;\n \tconst char *home = NULL;\n \n+\tconfig_exclusive_filename = getenv(CONFIG_ENVIRONMENT);\n+\n \t/* Setting $GIT_CONFIG makes git read _only_ the given config file. */\n \tif (config_exclusive_filename)\n \t\treturn git_config_from_file(fn, config_exclusive_filename, data);\n\n\n-- \nLinux Foundation\nhttp://www.yoctoproject.org/\n"},{"id":"173412","messageId":"7vr54qmodf.fsf@alter.siamese.dyndns.org","threadId":"28081","inReplyTo":"1313163498.14274.505.camel@rex","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-12T19:16:44Z","receivedAt":"2011-08-12T19:16:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Purdie writes:\n\n> Looking through the manuals/code, it suggests I should be able to do:\n>\n> GIT_CONFIG=/dev/null git XXX\n>\n> and all should work happily. It doesn't though. As an example, with a\n> ~/.gitconfig, \"GIT_CONFIG=/dev/null git fetch --all\" is clearly\n> accessing the file in ~ and then acting upon it.\n\nIf the manual says the above is expected for any value of XXX, then that\nis a bug in the manual since mid 2008, I think.\n\nSee dc87183 (Only use GIT_CONFIG in \"git config\", not other programs,\n2008-06-30).\n\nI _think_ these days a workaround to force a known config is to set HOME\nto a value that has a known .gitconfig (or no such file), and decline\nusage of /etc/git.config by exporting GIT_CONFIG_NOSYSTEM.\n"},{"id":"173413","messageId":"7vmxfemnc4.fsf@alter.siamese.dyndns.org","threadId":"28081","inReplyTo":"7vr54qmodf.fsf@alter.siamese.dyndns.org","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-12T19:39:07Z","receivedAt":"2011-08-12T19:39:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Richard Purdie writes:\n>\n>> Looking through the manuals/code, it suggests I should be able to do:\n>>\n>> GIT_CONFIG=/dev/null git XXX\n>>\n>> and all should work happily. It doesn't though. As an example, with a\n>> ~/.gitconfig, \"GIT_CONFIG=/dev/null git fetch --all\" is clearly\n>> accessing the file in ~ and then acting upon it.\n>\n> If the manual says the above is expected for any value of XXX, then that\n> is a bug in the manual since mid 2008, I think.\n>\n> See dc87183 (Only use GIT_CONFIG in \"git config\", not other programs,\n> 2008-06-30).\n>\n> I _think_ these days a workaround to force a known config is to set HOME\n> to a value that has a known .gitconfig (or no such file), and decline\n> usage of /etc/git.config by exporting GIT_CONFIG_NOSYSTEM.\n\nSide note. Here is what dc87183 says:\n\ncommit dc87183189b54441e315d35d48983d80ab085299\nAuthor: Daniel Barkalow \nDate: Mon Jun 30 03:37:47 2008 -0400\n\n Only use GIT_CONFIG in \"git config\", not other programs\n \n For everything other than using \"git config\" to read or write a\n git-style config file that isn't the current repo's config file,\n GIT_CONFIG was actively detrimental. Rather than argue over which\n programs are important enough to have work anyway, just fix all of\n them at the root.\n \n Also removes GIT_LOCAL_CONFIG, which would only be useful for programs\n that do want to use global git-specific config, but not the repo's own\n git-specific config, and want to use some other, presumably\n git-specific config. Despite being documented, I can't find any sign that\n it was ever used.\n \n Signed-off-by: Daniel Barkalow \n Signed-off-by: Junio C Hamano \n\nIt clearly explains the reason why LOCAL_CONFIG was removed (the reader\ndoes not have to agree with \"I can't find any sign that it was ever used\",\nthough), but I cannot read from the first paragraph the reason why it was\nfelt necessary not to honor GIT_CONFIG in other programs, i.e. \"was\nactively detrimental\" is not backed by any example in the paragraph. I can\nsort of sense from \"Rather than argue over...\" that there may have been a\ndiscussion on the list, and reading the archive from that timeframe may\nreveal why many felt it was not a good idea.\n\nDaniel, do you recall the context?\n"},{"id":"173417","messageId":"1313181853.14274.535.camel@rex","threadId":"28081","inReplyTo":"7vmxfemnc4.fsf@alter.siamese.dyndns.org","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2011-08-12T20:44:13Z","receivedAt":"2011-08-12T20:44:13Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"On Fri, 2011-08-12 at 12:39 -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Richard Purdie writes:\n> >\n> >> Looking through the manuals/code, it suggests I should be able to do:\n> >>\n> >> GIT_CONFIG=/dev/null git XXX\n> >>\n> >> and all should work happily. It doesn't though. As an example, with a\n> >> ~/.gitconfig, \"GIT_CONFIG=/dev/null git fetch --all\" is clearly\n> >> accessing the file in ~ and then acting upon it.\n> >\n> > If the manual says the above is expected for any value of XXX, then that\n> > is a bug in the manual since mid 2008, I think.\n> >\n> > See dc87183 (Only use GIT_CONFIG in \"git config\", not other programs,\n> > 2008-06-30).\n> >\n> > I _think_ these days a workaround to force a known config is to set HOME\n> > to a value that has a known .gitconfig (or no such file), and decline\n> > usage of /etc/git.config by exporting GIT_CONFIG_NOSYSTEM.\n> \n> Side note. Here is what dc87183 says:\n> \n> commit dc87183189b54441e315d35d48983d80ab085299\n> Author: Daniel Barkalow \n> Date: Mon Jun 30 03:37:47 2008 -0400\n> \n> Only use GIT_CONFIG in \"git config\", not other programs\n> \n> For everything other than using \"git config\" to read or write a\n> git-style config file that isn't the current repo's config file,\n> GIT_CONFIG was actively detrimental. Rather than argue over which\n> programs are important enough to have work anyway, just fix all of\n> them at the root.\n> \n> Also removes GIT_LOCAL_CONFIG, which would only be useful for programs\n> that do want to use global git-specific config, but not the repo's own\n> git-specific config, and want to use some other, presumably\n> git-specific config. Despite being documented, I can't find any sign that\n> it was ever used.\n> \n> Signed-off-by: Daniel Barkalow \n> Signed-off-by: Junio C Hamano \n> \n> It clearly explains the reason why LOCAL_CONFIG was removed (the reader\n> does not have to agree with \"I can't find any sign that it was ever used\",\n> though), but I cannot read from the first paragraph the reason why it was\n> felt necessary not to honor GIT_CONFIG in other programs, i.e. \"was\n> actively detrimental\" is not backed by any example in the paragraph. I can\n> sort of sense from \"Rather than argue over...\" that there may have been a\n> discussion on the list, and reading the archive from that timeframe may\n> reveal why many felt it was not a good idea.\n> \n> Daniel, do you recall the context?\n\nI went digging and this looks like as good a summary as any of the posts\naround that time:\n\nhttp://marc.info/?l=git&m=121476432303314&w=2\n\nIt sounds like if you specified GIT_CONFIG when making a clone it would\nend up writing the config file specified rather than .git/config.\n\nMy problem isn't that I want to specify a specific .gitconfig file, I\njust need it to ignore the one in $HOME. I'm happy for the .git/config\nfile to be used, in fact I need it to be.\n\nI noticed 8f323c00dd3c9b396b01a1aeea74f7dfd061bb7f was committed which\nremoved GIT_CONFIG_NOGLOBAL support which is the other way to address\nthe problem. Could we add that back?\n\nI appreciate I can set $HOME to something but that means creating an\nempty directory to point at and feels rather like a work around rather\nthan a solution.\n\nCheers,\n\nRichard\n\n-- \nLinux Foundation\nhttp://www.yoctoproject.org/\n"},{"id":"174414","messageId":"20110828130555.GA56765@gmail.com","threadId":"28081","inReplyTo":"1313181853.14274.535.camel@rex","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-08-28T13:05:56Z","receivedAt":"2011-08-28T13:05:56Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:\n> My problem isn't that I want to specify a specific .gitconfig file, I\n> just need it to ignore the one in $HOME. I'm happy for the .git/config\n> file to be used, in fact I need it to be.\n\nIf you're writing a tool then it should restrict itself to\ngit's plumbing commands. You should be able to do just about\nanything without needing to worry about differences in\nconfiguraiton. Git commands almost always provide a way to\noverride configuration through the use of flags.\n\nThe plumbing commands are listed in the main git manpage.\nSee \"Low-level commands (plumbing)\" here:\nhttp://www.kernel.org/pub/software/scm/git/docs/\n\nWhat is the specific problem solved by overriding the\nconfiguration? It may be possible to solve it without needing\nto get too complicated.\n\nHave fun,\n-- \n\t\t\t\t\tDavid\n"},{"id":"174455","messageId":"1314620166.5939.282.camel@rex","threadId":"28081","inReplyTo":"20110828130555.GA56765@gmail.com","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2011-08-29T12:16:06Z","receivedAt":"2011-08-29T12:16:06Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"On Sun, 2011-08-28 at 06:05 -0700, David Aguilar wrote:\n> On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:\n> > My problem isn't that I want to specify a specific .gitconfig file, I\n> > just need it to ignore the one in $HOME. I'm happy for the .git/config\n> > file to be used, in fact I need it to be.\n> \n> If you're writing a tool then it should restrict itself to\n> git's plumbing commands. You should be able to do just about\n> anything without needing to worry about differences in\n> configuraiton. Git commands almost always provide a way to\n> override configuration through the use of flags.\n> \n> The plumbing commands are listed in the main git manpage.\n> See \"Low-level commands (plumbing)\" here:\n> http://www.kernel.org/pub/software/scm/git/docs/\n> \n> What is the specific problem solved by overriding the\n> configuration? It may be possible to solve it without needing\n> to get too complicated.\n\nI'm not sure writing my own porcelain makes sense in this case.\n\nThe tool in question is a build system which is primarily interested in\nbuilding software. Sometimes the software we want to build is \"bleeding\nedge\" and hence rather than download tarballs, we want to interact\ndirectly with SCMs like git to obtain it.\n\nThe commands I'm using are the likes of \"git clone\" and \"git fetch\"\nalthough we do use commands listed under the plumbing section too such\nas ls-remote and read-tree. We do \"cache\" checkouts and support\nautomatically noticing changes and updating/building.\n\nWhat I do want to be able to say is \"ignore whatever the user might have\nput in their ~/.gitconfig file\" since I've open bug reports about people\nputting things in there that break builds.\n\nThe fetch/clone commands do what I need, apart from being influenced by\nuserconfig so reimplementing them myself doesn't seem like a good\napproach.\n\nCheers,\n\nRichard\n\n-- \nLinux Foundation\nhttp://www.yoctoproject.org/\n"},{"id":"174533","messageId":"20110830031022.GA64106@gmail.com","threadId":"28081","inReplyTo":"1314620166.5939.282.camel@rex","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-08-30T03:10:24Z","receivedAt":"2011-08-30T03:10:24Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Aug 29, 2011 at 01:16:06PM +0100, Richard Purdie wrote:\n> On Sun, 2011-08-28 at 06:05 -0700, David Aguilar wrote:\n> > On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:\n> > > My problem isn't that I want to specify a specific .gitconfig file, I\n> > > just need it to ignore the one in $HOME. I'm happy for the .git/config\n> > > file to be used, in fact I need it to be.\n> > \n> > If you're writing a tool then it should restrict itself to\n> > git's plumbing commands. You should be able to do just about\n> > anything without needing to worry about differences in\n> > configuraiton. Git commands almost always provide a way to\n> > override configuration through the use of flags.\n> > \n> > The plumbing commands are listed in the main git manpage.\n> > See \"Low-level commands (plumbing)\" here:\n> > http://www.kernel.org/pub/software/scm/git/docs/\n> > \n> > What is the specific problem solved by overriding the\n> > configuration? It may be possible to solve it without needing\n> > to get too complicated.\n> \n> I'm not sure writing my own porcelain makes sense in this case.\n\nTrue... luckily we don't have to go that far.\n\n> The tool in question is a build system which is primarily interested in\n> building software. Sometimes the software we want to build is \"bleeding\n> edge\" and hence rather than download tarballs, we want to interact\n> directly with SCMs like git to obtain it.\n> \n> The commands I'm using are the likes of \"git clone\" and \"git fetch\"\n> although we do use commands listed under the plumbing section too such\n> as ls-remote and read-tree. We do \"cache\" checkouts and support\n> automatically noticing changes and updating/building.\n> \n> What I do want to be able to say is \"ignore whatever the user might have\n> put in their ~/.gitconfig file\" since I've open bug reports about people\n> putting things in there that break builds.\n> \n> The fetch/clone commands do what I need, apart from being influenced by\n> userconfig so reimplementing them myself doesn't seem like a good\n> approach.\n\nThis is what we're interested in.\n\nDo you have the specifics of exactly what in the user\n~/.gitconfig file broke the build?\n\nWhat I'm suggesting is that there's probably a way to avoid\nthe user-dependent behavior by being explicit on\nthe command-line.\n\nSpecifically regarding fetch -- if you're doing \"git fetch\"\nand relying on the configuration then we can probably come\nup with a more explicit fetch command that has an explicit\nand predictable behavior independent of the user's\nconfiguraiton.\n\nUsing the explicit form of the command can make the build system\nmore robust.\n\nLet us know what you're cooking, it sounds interesting.\n\ncheers,\n-- \n\t\t\t\t\tDavid\n"},{"id":"174546","messageId":"1314706381.5939.348.camel@rex","threadId":"28081","inReplyTo":"20110830031022.GA64106@gmail.com","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Richard Purdie","fromEmail":"rpurdie@rpsys.net","sentAt":"2011-08-30T12:13:01Z","receivedAt":"2011-08-30T12:13:01Z","isPatch":false,"sender":{"key":"rpurdie@rpsys.net","avatar":null},"body":"On Mon, 2011-08-29 at 20:10 -0700, David Aguilar wrote:\n> On Mon, Aug 29, 2011 at 01:16:06PM +0100, Richard Purdie wrote:\n> > On Sun, 2011-08-28 at 06:05 -0700, David Aguilar wrote:\n> > > On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:\n> > > > My problem isn't that I want to specify a specific .gitconfig file, I\n> > > > just need it to ignore the one in $HOME. I'm happy for the .git/config\n> > > > file to be used, in fact I need it to be.\n> > > \n> > > If you're writing a tool then it should restrict itself to\n> > > git's plumbing commands. You should be able to do just about\n> > > anything without needing to worry about differences in\n> > > configuraiton. Git commands almost always provide a way to\n> > > override configuration through the use of flags.\n> > > \n> > > The plumbing commands are listed in the main git manpage.\n> > > See \"Low-level commands (plumbing)\" here:\n> > > http://www.kernel.org/pub/software/scm/git/docs/\n> > > \n> > > What is the specific problem solved by overriding the\n> > > configuration? It may be possible to solve it without needing\n> > > to get too complicated.\n> > \n> > I'm not sure writing my own porcelain makes sense in this case.\n> \n> True... luckily we don't have to go that far.\n> \n> > The tool in question is a build system which is primarily interested in\n> > building software. Sometimes the software we want to build is \"bleeding\n> > edge\" and hence rather than download tarballs, we want to interact\n> > directly with SCMs like git to obtain it.\n> > \n> > The commands I'm using are the likes of \"git clone\" and \"git fetch\"\n> > although we do use commands listed under the plumbing section too such\n> > as ls-remote and read-tree. We do \"cache\" checkouts and support\n> > automatically noticing changes and updating/building.\n> > \n> > What I do want to be able to say is \"ignore whatever the user might have\n> > put in their ~/.gitconfig file\" since I've open bug reports about people\n> > putting things in there that break builds.\n> > \n> > The fetch/clone commands do what I need, apart from being influenced by\n> > userconfig so reimplementing them myself doesn't seem like a good\n> > approach.\n> \n> This is what we're interested in.\n> \n> Do you have the specifics of exactly what in the user\n> ~/.gitconfig file broke the build?\n> \n> What I'm suggesting is that there's probably a way to avoid\n> the user-dependent behavior by being explicit on\n> the command-line.\n> \n> Specifically regarding fetch -- if you're doing \"git fetch\"\n> and relying on the configuration then we can probably come\n> up with a more explicit fetch command that has an explicit\n> and predictable behavior independent of the user's\n> configuraiton.\n> \n> Using the explicit form of the command can make the build system\n> more robust.\n> \n> Let us know what you're cooking, it sounds interesting.\n\nWe've gone through several iterations of this but as things stand now,\nto initially clone things we're doing:\n\ngit clone --bare --mirror \n\nbut if we already have some existing clone we'd update with:\n\ngit remote prune origin\ngit remote rm origin\ngit remote add --mirror origin \ngit fetch --all -t\n\nI have a strong suspicion that the fetch --all doesn't do us any favours\nsince if the user defines other remotes in their local config it will\nalso fetch them. We could probably change this to be \"git fetch origin\n-t\" which would be safer however the .gitconfig file that someone\nreported causing problems actually defined an origin remote. I don't\nwant to debate whether that is sane or not, I just want to be 100% sure\nwe work regardless of what the user may have defined.\n\nFor reference, the reasons for the remote commands above is to be 100%\nsure that we fetch the right thing if has changed, or if upstream\nhas deleted any branches in incompatible ways. We've tried not using any\nremotes at all but that seems to bring its own set of problems as we\nhave seen issues with fetch not downloading everything from the upstream\nrepo (which is what we need since this is a cache/mirror copy). We ended\nup needing to be very precise about what we wanted.\n\nWhen we actually come to build something we make a referenced clone that\ncontains an actual checkout with the commands:\n\ngit clone -s -n \ngit checkout \n\nwhich has the nice effect of being kind on disk space and fast :).\n\nOr in some cases where we only want a specific subdirectory:\n\ngit read-tree :\ngit checkout-index -q -f -a\n\nwhich is fairly evil and leaves the tree in a nasty state but its what\nsome people need.\n\nIn case you're interested, the code in question is part of a tool called\nbitbake and is one of several different fetcher modules:\n\nhttp://git.openembedded.org/cgit.cgi/bitbake/tree/lib/bb/fetch2/git.py\n\nSo if a user has an origin remote in their .gitconfig, can we ignore it?\n\nCheers,\n\nRichard\n\n-- \nLinux Foundation\nhttp://www.yoctoproject.org/\n"},{"id":"174556","messageId":"20110830155649.GA15790@sigill.intra.peff.net","threadId":"28081","inReplyTo":"1314706381.5939.348.camel@rex","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-30T15:56:49Z","receivedAt":"2011-08-30T15:56:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 30, 2011 at 01:13:01PM +0100, Richard Purdie wrote:\n\n> We've gone through several iterations of this but as things stand now,\n> to initially clone things we're doing:\n> \n> git clone --bare --mirror \n> \n> but if we already have some existing clone we'd update with:\n> \n> git remote prune origin\n> git remote rm origin\n> git remote add --mirror origin \n> git fetch --all -t\n>\n> [...]\n>\n> So if a user has an origin remote in their .gitconfig, can we ignore it?\n\nWouldn't:\n\n git fetch --prune refs/heads/*:refs/remotes/origin/*\n\ndo what you want, and not look at config at all?\n\n-Peff\n"},{"id":"174577","messageId":"1314729545.5939.391.camel@rex","threadId":"28081","inReplyTo":"20110830155649.GA15790@sigill.intra.peff.net","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Richard Purdie","fromEmail":"richard.purdie@linuxfoundation.org","sentAt":"2011-08-30T18:39:05Z","receivedAt":"2011-08-30T18:39:05Z","isPatch":false,"sender":{"key":"richard.purdie@linuxfoundation.org","avatar":null},"body":"On Tue, 2011-08-30 at 11:56 -0400, Jeff King wrote:\n> On Tue, Aug 30, 2011 at 01:13:01PM +0100, Richard Purdie wrote:\n> \n> > We've gone through several iterations of this but as things stand now,\n> > to initially clone things we're doing:\n> > \n> > git clone --bare --mirror \n> > \n> > but if we already have some existing clone we'd update with:\n> > \n> > git remote prune origin\n> > git remote rm origin\n> > git remote add --mirror origin \n> > git fetch --all -t\n> >\n> > [...]\n> >\n> > So if a user has an origin remote in their .gitconfig, can we ignore it?\n> \n> Wouldn't:\n> \n> git fetch --prune refs/heads/*:refs/remotes/origin/*\n> \n> do what you want, and not look at config at all?\n\nSince this is a bare/mirror clone, wouldn't that need to be:\n\n git fetch --prune refs/heads/*:refs/heads/*\n\n?\n\nThat also wouldn't fetch tags?\n\nCheers,\n\nRichard\n"},{"id":"174574","messageId":"20110830184951.GA19204@sigill.intra.peff.net","threadId":"28081","inReplyTo":"1314729545.5939.391.camel@rex","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-30T18:49:51Z","receivedAt":"2011-08-30T18:49:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 30, 2011 at 07:39:05PM +0100, Richard Purdie wrote:\n\n> On Tue, 2011-08-30 at 11:56 -0400, Jeff King wrote:\n> > On Tue, Aug 30, 2011 at 01:13:01PM +0100, Richard Purdie wrote:\n> > \n> > > We've gone through several iterations of this but as things stand now,\n> > > to initially clone things we're doing:\n> > > \n> > > git clone --bare --mirror \n> > > \n> > > but if we already have some existing clone we'd update with:\n> > > \n> > > git remote prune origin\n> > > git remote rm origin\n> > > git remote add --mirror origin \n> > > git fetch --all -t\n> > >\n> > > [...]\n> > >\n> > > So if a user has an origin remote in their .gitconfig, can we ignore it?\n> > \n> > Wouldn't:\n> > \n> > git fetch --prune refs/heads/*:refs/remotes/origin/*\n> > \n> > do what you want, and not look at config at all?\n> \n> Since this is a bare/mirror clone, wouldn't that need to be:\n> \n> git fetch --prune refs/heads/*:refs/heads/*\n\nSorry, yes, I forgot about the mirroring bit.\n\n> That also wouldn't fetch tags?\n\nIt would only do autofollowing. You could use \"-t\", but if you really\nwant a straight mirror, you could do:\n\n git fetch --prune refs/*:refs/*\n\nto get everything.\n\n-Peff\n"},{"id":"174881","messageId":"1315250990.1243.14.camel@ted","threadId":"28081","inReplyTo":"20110830184951.GA19204@sigill.intra.peff.net","subject":"Re: Overriding ~/.gitconfig using GIT_CONFIG","fromName":"Richard Purdie","fromEmail":"richard.purdie@linuxfoundation.org","sentAt":"2011-09-05T19:29:50Z","receivedAt":"2011-09-05T19:29:50Z","isPatch":false,"sender":{"key":"richard.purdie@linuxfoundation.org","avatar":null},"body":"On Tue, 2011-08-30 at 14:49 -0400, Jeff King wrote:\n> On Tue, Aug 30, 2011 at 07:39:05PM +0100, Richard Purdie wrote:\n> \n> > On Tue, 2011-08-30 at 11:56 -0400, Jeff King wrote:\n> > > On Tue, Aug 30, 2011 at 01:13:01PM +0100, Richard Purdie wrote:\n> > > \n> > > > We've gone through several iterations of this but as things stand now,\n> > > > to initially clone things we're doing:\n> > > > \n> > > > git clone --bare --mirror \n> > > > \n> > > > but if we already have some existing clone we'd update with:\n> > > > \n> > > > git remote prune origin\n> > > > git remote rm origin\n> > > > git remote add --mirror origin \n> > > > git fetch --all -t\n> > > >\n> > > > [...]\n> > > >\n> > > > So if a user has an origin remote in their .gitconfig, can we ignore it?\n> > > \n> > > Wouldn't:\n> > > \n> > > git fetch --prune refs/heads/*:refs/remotes/origin/*\n> > > \n> > > do what you want, and not look at config at all?\n> > \n> > Since this is a bare/mirror clone, wouldn't that need to be:\n> > \n> > git fetch --prune refs/heads/*:refs/heads/*\n> \n> Sorry, yes, I forgot about the mirroring bit.\n> \n> > That also wouldn't fetch tags?\n> \n> It would only do autofollowing. You could use \"-t\", but if you really\n> want a straight mirror, you could do:\n> \n> git fetch --prune refs/*:refs/*\n> \n> to get everything.\n\nThanks. Just to updated, I've changed the code to do this so we'll see\nhow it goes...\n\nCheers,\n\nRichard\n"}]}