{"thread":{"id":"20128","subject":"[ANNOUNCE] GIT 1.6.4.rc1","startedAt":"2009-07-16T00:57:12Z","lastAt":"2009-07-19T14:45:00Z","messageCount":19,"participants":["Junio C Hamano","Tommy Nordgren","Jeff Garzik","Felipe Balbi","Nicolas Sebrecht","Mike Ralphson","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118061","messageId":"7vmy75bg2f.fsf@alter.siamese.dyndns.org","threadId":"20128","inReplyTo":null,"subject":"[ANNOUNCE] GIT 1.6.4.rc1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-16T00:57:12Z","receivedAt":"2009-07-16T00:57:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A release candidate GIT 1.6.4.rc1 is available at the usual places\nfor testing:\n\n http://www.kernel.org/pub/software/scm/git/\n\n git-1.6.4.rc1.tar.{gz,bz2}\t\t\t(source tarball)\n git-htmldocs-1.6.4.rc1.tar.{gz,bz2}\t\t(preformatted docs)\n git-manpages-1.6.4.rc1.tar.{gz,bz2}\t\t(preformatted docs)\n\nThe RPM binary packages for a few architectures are found in:\n\n testing/git-*-1.6.4.rc1-1.fc9.$arch.rpm\t(RPM)\n\nGIT v1.6.4 Release Notes (draft)\n================================\n\nWith the next major release, \"git push\" into a branch that is\ncurrently checked out will be refused by default. You can choose\nwhat should happen upon such a push by setting the configuration\nvariable receive.denyCurrentBranch in the receiving repository.\n\nTo ease the transition plan, the receiving repository of such a\npush running this release will issue a big warning when the\nconfiguration variable is missing. Please refer to:\n\n http://git.or.cz/gitwiki/GitFaq#non-bare\n http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\nfor more details on the reason why this change is needed and the\ntransition plan.\n\nFor a similar reason, \"git push $there :$killed\" to delete the branch\n$killed in a remote repository $there, if $killed branch is the current\nbranch pointed at by its HEAD, gets a large warning. You can choose what\nshould happen upon such a push by setting the configuration variable\nreceive.denyDeleteCurrent in the receiving repository.\n\nWhen the user does not tell \"git push\" what to push, it has always\npushed matching refs. For some people it is unexpected, and a new\nconfiguration variable push.default has been introduced to allow\nchanging a different default behaviour. To advertise the new feature,\na big warning is issued if this is not configured and a git push without\narguments is attempted.\n\n\tSide note: we might want to tone this down, as it does not seem\n\tlikely for us to change the default behaviour when this option is\n\tnot set.\n\n\nUpdates since v1.6.3\n--------------------\n\n(subsystems)\n\n * gitweb Perl style clean-up.\n\n * git-svn updates, including a new --authors-prog option to map author\n names by invoking an external program.\n\n(portability)\n\n * We feed iconv with \"UTF-8\" instead of \"utf8\"; the former is\n understood more widely.\n\n(performance)\n\n(usability, bells and whistles)\n\n * \"git add --edit\" lets users edit the whole patch text to fine-tune what\n is added to the index.\n\n * \"git log --graph\" draws graphs more compactly by using horizonal lines\n when able.\n\n * \"git log --decorate\" shows shorter refnames by stripping well-known\n refs/* prefix.\n\n * \"git send-email\" understands quoted aliases in .mailrc files (might\n have to be backported to 1.6.3.X).\n\n * \"git send-email\" can fetch the sender address from the configuration\n variable \"sendmail.from\" (and \"sendmail..from\").\n\n * \"git show-branch\" can color its output.\n\n * \"add\" and \"update\" subcommands to \"git submodule\" learned --reference\n option to use local clone with references.\n\n(developers)\n\n * A major part of the \"git bisect\" wrapper has moved to C.\n\nFixes since v1.6.3\n------------------\n\nAll of the fixes in v1.6.3.X maintenance series are included in this\nrelease, unless otherwise noted.\n\nHere are fixes that this release has, but have not been backported to\nv1.6.3.X series.\n\n * The way Git.pm sets up a Repository object was not friendly to callers\n that chdir around. It now internally records the repository location\n as an absolute path when autodetected.\n"},{"id":"118070","messageId":"057D2A1F-0383-4AE4-A431-54D6C1F90D85@comhem.se","threadId":"20128","inReplyTo":"7vmy75bg2f.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Tommy Nordgren","fromEmail":"tommy.nordgren@comhem.se","sentAt":"2009-07-16T03:51:48Z","receivedAt":"2009-07-16T03:51:48Z","isPatch":false,"sender":{"key":"tommy.nordgren@comhem.se","avatar":null},"body":"Testing a build of this version fails at a late stage, with an error \nthat aborts testing.\nMy system is Mac OS X 10.5.8\nFragment of output at failure:\n*** t9200-git-cvsexportcommit.sh ***\n* ok 1: New file\n..snip\n* FAIL 14: re-commit a removed filename which remains in CVS attic\n\t\n\t\n\t (cd \"$CVSWORK\" &&\n\t echo >attic_gremlin &&\n\t cvs -Q add attic_gremlin &&\n\t cvs -Q ci -m \"added attic_gremlin\" &&\n\t rm attic_gremlin &&\n\t cvs -Q rm attic_gremlin &&\n\t cvs -Q ci -m \"removed attic_gremlin\") &&\n\t\n\t echo > attic_gremlin &&\n\t git add attic_gremlin &&\n\t git commit -m \"Added attic_gremlin\" &&\n\t\tgit cvsexportcommit -w \"$CVSWORK\" -c HEAD &&\n\t (cd \"$CVSWORK\"; cvs -Q update -d) &&\n\t test -f \"$CVSWORK/attic_gremlin\"\n\t\n* failed 1 among 14 test(s)\n\nOn Jul 16, 2009, at 2:57 AM, Junio C Hamano wrote:\n\n> A release candidate GIT 1.6.4.rc1 is available at the usual places\n> for testing:\n>\n> http://www.kernel.org/pub/software/scm/git/\n>\n> git-1.6.4.rc1.tar.{gz,bz2}\t\t\t(source tarball)\n> git-htmldocs-1.6.4.rc1.tar.{gz,bz2}\t\t(preformatted docs)\n> git-manpages-1.6.4.rc1.tar.{gz,bz2}\t\t(preformatted docs)\n>\n> The RPM binary packages for a few architectures are found in:\n>\n> testing/git-*-1.6.4.rc1-1.fc9.$arch.rpm\t(RPM)\n>\n> GIT v1.6.4 Release Notes (draft)\n> ================================\n>\n> With the next major release, \"git push\" into a branch that is\n> currently checked out will be refused by default. You can choose\n> what should happen upon such a push by setting the configuration\n> variable receive.denyCurrentBranch in the receiving repository.\n>\n> To ease the transition plan, the receiving repository of such a\n> push running this release will issue a big warning when the\n> configuration variable is missing. Please refer to:\n>\n> http://git.or.cz/gitwiki/GitFaq#non-bare\n> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>\n> for more details on the reason why this change is needed and the\n> transition plan.\n>\n> For a similar reason, \"git push $there :$killed\" to delete the branch\n> $killed in a remote repository $there, if $killed branch is the \n> current\n> branch pointed at by its HEAD, gets a large warning. You can choose \n> what\n> should happen upon such a push by setting the configuration variable\n> receive.denyDeleteCurrent in the receiving repository.\n>\n> When the user does not tell \"git push\" what to push, it has always\n> pushed matching refs. For some people it is unexpected, and a new\n> configuration variable push.default has been introduced to allow\n> changing a different default behaviour. To advertise the new feature,\n> a big warning is issued if this is not configured and a git push \n> without\n> arguments is attempted.\n>\n> \tSide note: we might want to tone this down, as it does not seem\n> \tlikely for us to change the default behaviour when this option is\n> \tnot set.\n>\n>\n> Updates since v1.6.3\n> --------------------\n>\n> (subsystems)\n>\n> * gitweb Perl style clean-up.\n>\n> * git-svn updates, including a new --authors-prog option to map author\n> names by invoking an external program.\n>\n> (portability)\n>\n> * We feed iconv with \"UTF-8\" instead of \"utf8\"; the former is\n> understood more widely.\n>\n> (performance)\n>\n> (usability, bells and whistles)\n>\n> * \"git add --edit\" lets users edit the whole patch text to fine-tune \n> what\n> is added to the index.\n>\n> * \"git log --graph\" draws graphs more compactly by using horizonal \n> lines\n> when able.\n>\n> * \"git log --decorate\" shows shorter refnames by stripping well-known\n> refs/* prefix.\n>\n> * \"git send-email\" understands quoted aliases in .mailrc files (might\n> have to be backported to 1.6.3.X).\n>\n> * \"git send-email\" can fetch the sender address from the configuration\n> variable \"sendmail.from\" (and \"sendmail..from\").\n>\n> * \"git show-branch\" can color its output.\n>\n> * \"add\" and \"update\" subcommands to \"git submodule\" learned -- \n> reference\n> option to use local clone with references.\n>\n> (developers)\n>\n> * A major part of the \"git bisect\" wrapper has moved to C.\n>\n> Fixes since v1.6.3\n> ------------------\n>\n> All of the fixes in v1.6.3.X maintenance series are included in this\n> release, unless otherwise noted.\n>\n> Here are fixes that this release has, but have not been backported to\n> v1.6.3.X series.\n>\n> * The way Git.pm sets up a Repository object was not friendly to \n> callers\n> that chdir around. It now internally records the repository \n> location\n> as an absolute path when autodetected.\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\"Home is not where you are born, but where your heart finds peace\" -\nTommy Nordgren, \"The dying old crone\"\ntommy.nordgren@comhem.se\n"},{"id":"118071","messageId":"4A5EA598.5050801@garzik.org","threadId":"20128","inReplyTo":"7vmy75bg2f.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2009-07-16T03:59:20Z","receivedAt":"2009-07-16T03:59:20Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Junio C Hamano wrote:\n> GIT v1.6.4 Release Notes (draft)\n> ================================\n> \n> With the next major release, \"git push\" into a branch that is\n> currently checked out will be refused by default. You can choose\n> what should happen upon such a push by setting the configuration\n> variable receive.denyCurrentBranch in the receiving repository.\n> \n> To ease the transition plan, the receiving repository of such a\n> push running this release will issue a big warning when the\n> configuration variable is missing. Please refer to:\n> \n> http://git.or.cz/gitwiki/GitFaq#non-bare\n> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n> \n> for more details on the reason why this change is needed and the\n> transition plan.\n> \n> For a similar reason, \"git push $there :$killed\" to delete the branch\n> $killed in a remote repository $there, if $killed branch is the current\n> branch pointed at by its HEAD, gets a large warning. You can choose what\n> should happen upon such a push by setting the configuration variable\n> receive.denyDeleteCurrent in the receiving repository.\n> \n> When the user does not tell \"git push\" what to push, it has always\n> pushed matching refs. For some people it is unexpected, and a new\n> configuration variable push.default has been introduced to allow\n> changing a different default behaviour. To advertise the new feature,\n> a big warning is issued if this is not configured and a git push without\n> arguments is attempted.\n> \n> \tSide note: we might want to tone this down, as it does not seem\n> \tlikely for us to change the default behaviour when this option is\n> \tnot set.\n\n\nIs there some sort of guide to the new best practices for handling trees \nsuch as git.kernel.org, where one pushes into \"foo.git\" directly, and \nthere is no checked-out source code at all?\n\nI've been getting the multi-line \"warning: Updating the currently \nchecked out branch may cause confusion\" message, but ignoring it for \nnow, because it does not appear to apply to my situation (no checked-out \nwork tree).\n\nAdvice appreciated...\n\n\tJeff\n"},{"id":"118077","messageId":"7v3a8xb0lz.fsf@alter.siamese.dyndns.org","threadId":"20128","inReplyTo":"4A5EA598.5050801@garzik.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-16T06:31:04Z","receivedAt":"2009-07-16T06:31:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Garzik writes:\n\n> Is there some sort of guide to the new best practices for handling\n> trees such as git.kernel.org, where one pushes into \"foo.git\"\n> directly, and there is no checked-out source code at all?\n\nI think old repositories will be helped if you add\n\n\t[core]\n \tbare\n\nto their foo.git/config files.\n"},{"id":"118078","messageId":"4A5ECC09.3010405@garzik.org","threadId":"20128","inReplyTo":"7v3a8xb0lz.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2009-07-16T06:43:21Z","receivedAt":"2009-07-16T06:43:21Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Junio C Hamano wrote:\n> Jeff Garzik writes:\n> \n>> Is there some sort of guide to the new best practices for handling\n>> trees such as git.kernel.org, where one pushes into \"foo.git\"\n>> directly, and there is no checked-out source code at all?\n> \n> I think old repositories will be helped if you add\n> \n> \t[core]\n> \tbare\n> \n> to their foo.git/config files.\n\nThanks. What about cloning new repositories? Real world example:\n\nLocal workstation has /spare/repo/cld/.git repository, with checked-out \nworking tree.\n\nI want to publish this tree to the world via a *.kernel.org-like system, \nso my task is to\n\n\tscp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n\nbut if I do this with scp, then future pushes to \nremote.example.com:/pub/scm/cld.git emit the warning about updating the \ncurrently checked-out branch -- even though there are no checked-out \nfiles. The checked-out files were not copied in the scp.\n\nRegards,\n\n\tJeff\n"},{"id":"118079","messageId":"4A5ECC93.1050602@garzik.org","threadId":"20128","inReplyTo":"4A5ECC09.3010405@garzik.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2009-07-16T06:45:39Z","receivedAt":"2009-07-16T06:45:39Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Jeff Garzik wrote:\n> I want to publish this tree to the world via a *.kernel.org-like system, \n> so my task is to\n> \n> scp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n> \n> but if I do this with scp, then future pushes to \n> remote.example.com:/pub/scm/cld.git emit the warning about updating the \n> currently checked-out branch -- even though there are no checked-out \n> files. The checked-out files were not copied in the scp.\n\nIOW -- do I just edit the config for this case too, or is there some \n'git clone --bare' magic that can work across ssh, as shown above?\n\nIt is easy to clone -from- a remote, but not so easy to clone -to- a \nnew, bare remote.\n\n\tJeff\n"},{"id":"118080","messageId":"20090716064802.GG5256@nokia.com","threadId":"20128","inReplyTo":"4A5ECC09.3010405@garzik.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Felipe Balbi","fromEmail":"felipe.balbi@nokia.com","sentAt":"2009-07-16T06:48:02Z","receivedAt":"2009-07-16T06:48:02Z","isPatch":false,"sender":{"key":"felipe.balbi@nokia.com","avatar":null},"body":"On Thu, Jul 16, 2009 at 08:43:21AM +0200, ext Jeff Garzik wrote:\n> Junio C Hamano wrote:\n> > Jeff Garzik writes:\n> > \n> >> Is there some sort of guide to the new best practices for handling\n> >> trees such as git.kernel.org, where one pushes into \"foo.git\"\n> >> directly, and there is no checked-out source code at all?\n> > \n> > I think old repositories will be helped if you add\n> > \n> > \t[core]\n> > \tbare\n> > \n> > to their foo.git/config files.\n> \n> Thanks. What about cloning new repositories? Real world example:\n> \n> Local workstation has /spare/repo/cld/.git repository, with checked-out \n> working tree.\n> \n> I want to publish this tree to the world via a *.kernel.org-like system, \n> so my task is to\n> \n> \tscp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n> \n> but if I do this with scp, then future pushes to \n> remote.example.com:/pub/scm/cld.git emit the warning about updating the \n> currently checked-out branch -- even though there are no checked-out \n> files. The checked-out files were not copied in the scp.\n\nhow about you create the bare repository on the kernel.org-like server\nand then push cld to it ?\n\n-- \nbalbi\n"},{"id":"118081","messageId":"20090716065535.GG12971@vidovic","threadId":"20128","inReplyTo":"7vmy75bg2f.fsf@alter.siamese.dyndns.org","subject":"[ANNOUNCE] Re: GIT 1.6.4.rc1","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-07-16T06:55:35Z","receivedAt":"2009-07-16T06:55:35Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 15/07/09, Junio C Hamano wrote:\n\n> A release candidate GIT 1.6.4.rc1 is available at the usual places\n> for testing:\n> \n> http://www.kernel.org/pub/software/scm/git/\n\nCould you push into kernel.org, please?\n\n-- \nNicolas Sebrecht\n"},{"id":"118082","messageId":"7vocrl9kwi.fsf@alter.siamese.dyndns.org","threadId":"20128","inReplyTo":"4A5ECC09.3010405@garzik.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-16T06:55:41Z","receivedAt":"2009-07-16T06:55:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Garzik writes:\n\n> I want to publish this tree to the world via a *.kernel.org-like\n> system, so my task is to\n>\n> \tscp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n>\n> but if I do this with scp, then future pushes to\n> remote.example.com:/pub/scm/cld.git emit the warning about updating\n> the currently checked-out branch\n\nI think \"scp -r\" is a wrong way to \"clone\", as it will copy .git/config\nthat is specific to your local work tree that does not apply to the\nsituation at remote.example.com anyway. You do not want to push into your\nlocal repository with a work tree you are \"scp -r\"ing out of, but you do\nwant to push into the one at remote.example.com.\n\nInterestingly enough, we had a two separate thread about making a bare\nrepository out of a repository with a work tree today ;-)\n\n\tremote.example.com$ cd /pub/scm/\n remote.example.com$ git clone --bare over.there:/spare/repo/cld/.git cld.git\n"},{"id":"118084","messageId":"4A5ED38F.5070708@garzik.org","threadId":"20128","inReplyTo":"7vocrl9kwi.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2009-07-16T07:15:27Z","receivedAt":"2009-07-16T07:15:27Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Junio C Hamano wrote:\n> Jeff Garzik writes:\n> \n>> I want to publish this tree to the world via a *.kernel.org-like\n>> system, so my task is to\n>>\n>> \tscp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n>>\n>> but if I do this with scp, then future pushes to\n>> remote.example.com:/pub/scm/cld.git emit the warning about updating\n>> the currently checked-out branch\n> \n> I think \"scp -r\" is a wrong way to \"clone\", as it will copy .git/config\n> that is specific to your local work tree that does not apply to the\n> situation at remote.example.com anyway. You do not want to push into your\n> local repository with a work tree you are \"scp -r\"ing out of, but you do\n> want to push into the one at remote.example.com.\n> \n> Interestingly enough, we had a two separate thread about making a bare\n> repository out of a repository with a work tree today ;-)\n> \n> \tremote.example.com$ cd /pub/scm/\n> remote.example.com$ git clone --bare over.there:/spare/repo/cld/.git cld.git\n\nThat direction doesn't work due to firewalls, hence the scp out /to/ \nremote.example.com.\n\nSo, will this make git happy? :)\n\n[starting on local machine, where I do development]\n1) scp -r /spare/repo/cld remote.example.com:/tmp\n\n2) ssh remote.example.com\n\n3) cd /pub/scm\n\n4) git clone --bare /tmp/cld/.git cld.git\n\nRegards,\n\n\tJeff\n"},{"id":"118085","messageId":"4A5ED41F.5010502@garzik.org","threadId":"20128","inReplyTo":"20090716064802.GG5256@nokia.com","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2009-07-16T07:17:51Z","receivedAt":"2009-07-16T07:17:51Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Felipe Balbi wrote:\n> On Thu, Jul 16, 2009 at 08:43:21AM +0200, ext Jeff Garzik wrote:\n>> Junio C Hamano wrote:\n>>> Jeff Garzik writes:\n>>>\n>>>> Is there some sort of guide to the new best practices for handling\n>>>> trees such as git.kernel.org, where one pushes into \"foo.git\"\n>>>> directly, and there is no checked-out source code at all?\n>>> I think old repositories will be helped if you add\n>>>\n>>> \t[core]\n>>> \tbare\n>>>\n>>> to their foo.git/config files.\n>> Thanks. What about cloning new repositories? Real world example:\n>>\n>> Local workstation has /spare/repo/cld/.git repository, with checked-out \n>> working tree.\n>>\n>> I want to publish this tree to the world via a *.kernel.org-like system, \n>> so my task is to\n>>\n>> \tscp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n>>\n>> but if I do this with scp, then future pushes to \n>> remote.example.com:/pub/scm/cld.git emit the warning about updating the \n>> currently checked-out branch -- even though there are no checked-out \n>> files. The checked-out files were not copied in the scp.\n> \n> how about you create the bare repository on the kernel.org-like server\n> and then push cld to it ?\n\nYou mean use 'git init-db', like this?\n\n1) remote: cd /pub/scm ; mkdir cld.git ; GIT_DIR=cld.git git init-db\n\n2) local: cd /spare/repo/cld ; git push --force --all \\\n\tremote.ex.com/pub/scm/cld.git\n\nI suppose that would work...\n\n\tJeff\n"},{"id":"118086","messageId":"20090716072130.GH5256@nokia.com","threadId":"20128","inReplyTo":"4A5ED41F.5010502@garzik.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Felipe Balbi","fromEmail":"felipe.balbi@nokia.com","sentAt":"2009-07-16T07:21:30Z","receivedAt":"2009-07-16T07:21:30Z","isPatch":false,"sender":{"key":"felipe.balbi@nokia.com","avatar":null},"body":"On Thu, Jul 16, 2009 at 09:17:51AM +0200, ext Jeff Garzik wrote:\n> Felipe Balbi wrote:\n> > On Thu, Jul 16, 2009 at 08:43:21AM +0200, ext Jeff Garzik wrote:\n> >> Junio C Hamano wrote:\n> >>> Jeff Garzik writes:\n> >>>\n> >>>> Is there some sort of guide to the new best practices for handling\n> >>>> trees such as git.kernel.org, where one pushes into \"foo.git\"\n> >>>> directly, and there is no checked-out source code at all?\n> >>> I think old repositories will be helped if you add\n> >>>\n> >>> \t[core]\n> >>> \tbare\n> >>>\n> >>> to their foo.git/config files.\n> >> Thanks. What about cloning new repositories? Real world example:\n> >>\n> >> Local workstation has /spare/repo/cld/.git repository, with checked-out \n> >> working tree.\n> >>\n> >> I want to publish this tree to the world via a *.kernel.org-like system, \n> >> so my task is to\n> >>\n> >> \tscp -r /spare/repo/cld/.git remote.example.com:/pub/scm/cld.git\n> >>\n> >> but if I do this with scp, then future pushes to \n> >> remote.example.com:/pub/scm/cld.git emit the warning about updating the \n> >> currently checked-out branch -- even though there are no checked-out \n> >> files. The checked-out files were not copied in the scp.\n> > \n> > how about you create the bare repository on the kernel.org-like server\n> > and then push cld to it ?\n> \n> You mean use 'git init-db', like this?\n> \n> 1) remote: cd /pub/scm ; mkdir cld.git ; GIT_DIR=cld.git git init-db\n> \n> 2) local: cd /spare/repo/cld ; git push --force --all \\\n> \tremote.ex.com/pub/scm/cld.git\n> \n> I suppose that would work...\n\nyes, exactly :-)\n\n-- \nbalbi\n"},{"id":"118088","messageId":"7v4otd9jg8.fsf@alter.siamese.dyndns.org","threadId":"20128","inReplyTo":"4A5ED38F.5070708@garzik.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-16T07:27:03Z","receivedAt":"2009-07-16T07:27:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Garzik writes:\n\n> That direction doesn't work due to firewalls, hence the scp out /to/\n> remote.example.com.\n\nAh, then the \"git init --bare\" at remote followed by pushing -all into it,\nsuggested in your other subthread, would be an appropriate way.\n"},{"id":"118089","messageId":"e2b179460907160037t17e276fas8a713eff55bba7f3@mail.gmail.com","threadId":"20128","inReplyTo":"057D2A1F-0383-4AE4-A431-54D6C1F90D85@comhem.se","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-07-16T07:37:21Z","receivedAt":"2009-07-16T07:37:21Z","isPatch":false,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2009/7/16 Tommy Nordgren :\n> Testing a build of this version fails at a late stage, with an error that\n> aborts testing.\n> My system is Mac OS X 10.5.8\n> Fragment of output at failure:\n> *** t9200-git-cvsexportcommit.sh ***\n> ..snip\n> * FAIL 14: re-commit a removed filename which remains in CVS attic\n\nI posted a fix (well, a sticking plaster) for this yesterday. Could\nyou confirm if this fixes it for you?\n\nhttp://article.gmane.org/gmane.comp.version-control.git/123317\n\nThe issue is intermittent on AIX (and Junio has seen it as such on\nLinux too) so you may need to run the t9200... script a few times to\nverify all is ok.\n\nThanks also for testing the rc, and the detailed report, very much\nappreciated by all I'm sure.\n\nIf you can regularly build git.git snapshots, there are some scripts\nat http://repo.or.cz/w/git/gitbuild.git in the platform branch, and\ntags get pushed there describing the state of the build and tests on a\nfew 'non-core' platforms.\n\nCheers, Mike\n"},{"id":"118129","messageId":"4A5F8B5C.3020902@garzik.org","threadId":"20128","inReplyTo":"7v4otd9jg8.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2009-07-16T20:19:40Z","receivedAt":"2009-07-16T20:19:40Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Junio C Hamano wrote:\n> Jeff Garzik writes:\n> \n>> That direction doesn't work due to firewalls, hence the scp out /to/\n>> remote.example.com.\n> \n> Ah, then the \"git init --bare\" at remote followed by pushing -all into it,\n> suggested in your other subthread, would be an appropriate way.\n\nThanks!\n\n\tJeff\n"},{"id":"118179","messageId":"D205883B-CE07-4817-8F22-6071837945B5@comhem.se","threadId":"20128","inReplyTo":"e2b179460907160037t17e276fas8a713eff55bba7f3@mail.gmail.com","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Tommy Nordgren","fromEmail":"tommy.nordgren@comhem.se","sentAt":"2009-07-17T15:16:02Z","receivedAt":"2009-07-17T15:16:02Z","isPatch":false,"sender":{"key":"tommy.nordgren@comhem.se","avatar":null},"body":"\nOn Jul 16, 2009, at 9:37 AM, Mike Ralphson wrote:\n\n> 2009/7/16 Tommy Nordgren :\n>> Testing a build of this version fails at a late stage, with an \n>> error that\n>> aborts testing.\n>> My system is Mac OS X 10.5.8\n>> Fragment of output at failure:\n>> *** t9200-git-cvsexportcommit.sh ***\n>> ..snip\n>> * FAIL 14: re-commit a removed filename which remains in CVS attic\n>\n> I posted a fix (well, a sticking plaster) for this yesterday. Could\n> you confirm if this fixes it for you?\n>\n\tThe fix works 200 times out of 200\n\tThe old version fails 58 times out of 200.\n> http://article.gmane.org/gmane.comp.version-control.git/123317\n>\n> The issue is intermittent on AIX (and Junio has seen it as such on\n> Linux too) so you may need to run the t9200... script a few times to\n> verify all is ok.\n>\n> Thanks also for testing the rc, and the detailed report, very much\n> appreciated by all I'm sure.\n>\n> If you can regularly build git.git snapshots, there are some scripts\n> at http://repo.or.cz/w/git/gitbuild.git in the platform branch, and\n> tags get pushed there describing the state of the build and tests on a\n> few 'non-core' platforms.\n>\n> Cheers, Mike\n\n----------------------------------\nSkinheads are so tired of immigration, that they are going to move to \na country that don't accept immigrants!\nTommy Nordgren\ntommy.nordgren@comhem.se\n"},{"id":"118252","messageId":"20090719080558.6117@nanako3.lavabit.com","threadId":"20128","inReplyTo":"7vmy75bg2f.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-07-18T23:05:58Z","receivedAt":"2009-07-18T23:05:58Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano writes:\n\n> When the user does not tell \"git push\" what to push, it has always\n> pushed matching refs. For some people it is unexpected, and a new\n> configuration variable push.default has been introduced to allow\n> changing a different default behaviour. To advertise the new feature,\n> a big warning is issued if this is not configured and a git push without\n> arguments is attempted.\n>\n> \tSide note: we might want to tone this down, as it does not seem\n> \tlikely for us to change the default behaviour when this option is\n> \tnot set.\n\nI thought you applied this patch from Finn Arne:\n\n http://article.gmane.org/gmane.comp.version-control.git/119173\n\nbut apparently you didn't.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"118254","messageId":"7vskgt1q3t.fsf@alter.siamese.dyndns.org","threadId":"20128","inReplyTo":"20090719080558.6117@nanako3.lavabit.com","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-19T00:19:34Z","receivedAt":"2009-07-19T00:19:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Junio C Hamano writes:\n>\n>> When the user does not tell \"git push\" what to push, it has always\n>> pushed matching refs. For some people it is unexpected, and a new\n>> configuration variable push.default has been introduced to allow\n>> changing a different default behaviour. To advertise the new feature,\n>> a big warning is issued if this is not configured and a git push without\n>> arguments is attempted.\n>>\n>> \tSide note: we might want to tone this down, as it does not seem\n>> \tlikely for us to change the default behaviour when this option is\n>> \tnot set.\n>\n> I thought you applied this patch from Finn Arne:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/119173\n>\n> but apparently you didn't.\n\nI wrote that side note after googling around and found that many users\noutside git community wondering what a strange way to announce a new\nfeature it was, and I think they are right. I stupidly said that we\nshould tone the message neutral, because we might want to change the\ndefault in the future but we are still not committed. But the end result\nis just a confusing advertisement of an optional feature.\n\nI actually think that the right course of action at this point is this\npatch instead. We keep the default, we do not annoy the users, and people\nwho want to use a non-default configuration can use the feature.\n\n-- >8 --\nSubject: do not give big warning when push preference is unconfigured\n\nIf the message said \"we will be changing the default in the future, so\nthis is to warn people who want to keep the current default what to do\",\nit would have made some sense, but as it stands, the message is merely an\nunsolicited advertisement for a new feature which it is not helpful at\nall. Squelch it.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-push.c | 27 +--------------------------\n cache.h | 1 -\n environment.c | 2 +-\n 3 files changed, 2 insertions(+), 28 deletions(-)\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex 0a0297f..1d92e22 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -64,36 +64,11 @@ static void setup_push_tracking(void)\n \tadd_refspec(refspec.buf);\n }\n \n-static const char *warn_unconfigured_push_msg[] = {\n-\t\"You did not specify any refspecs to push, and the current remote\",\n-\t\"has not configured any push refspecs. The default action in this\",\n-\t\"case is to push all matching refspecs, that is, all branches\",\n-\t\"that exist both locally and remotely will be updated. This may\",\n-\t\"not necessarily be what you want to happen.\",\n-\t\"\",\n-\t\"You can specify what action you want to take in this case, and\",\n-\t\"avoid seeing this message again, by configuring 'push.default' to:\",\n-\t\" 'nothing' : Do not push anything\",\n-\t\" 'matching' : Push all matching branches (default)\",\n-\t\" 'tracking' : Push the current branch to whatever it is tracking\",\n-\t\" 'current' : Push the current branch\"\n-};\n-\n-static void warn_unconfigured_push(void)\n-{\n-\tint i;\n-\tfor (i = 0; i < ARRAY_SIZE(warn_unconfigured_push_msg); i++)\n-\t\twarning(\"%s\", warn_unconfigured_push_msg[i]);\n-}\n-\n static void setup_default_push_refspecs(void)\n {\n \tgit_config(git_default_config, NULL);\n \tswitch (push_default) {\n-\tcase PUSH_DEFAULT_UNSPECIFIED:\n-\t\twarn_unconfigured_push();\n-\t\t/* fallthrough */\n-\n+\tdefault:\n \tcase PUSH_DEFAULT_MATCHING:\n \t\tadd_refspec(\":\");\n \t\tbreak;\ndiff --git a/cache.h b/cache.h\nindex f1e5ede..c72f125 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -543,7 +543,6 @@ enum rebase_setup_type {\n };\n \n enum push_default_type {\n-\tPUSH_DEFAULT_UNSPECIFIED = -1,\n \tPUSH_DEFAULT_NOTHING = 0,\n \tPUSH_DEFAULT_MATCHING,\n \tPUSH_DEFAULT_TRACKING,\ndiff --git a/environment.c b/environment.c\nindex 801a005..720f26b 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -42,7 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n enum rebase_setup_type autorebase = AUTOREBASE_NEVER;\n-enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;\n+enum push_default_type push_default = PUSH_DEFAULT_MATCHING;\n #ifndef OBJECT_CREATION_MODE\n #define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS\n #endif\n"},{"id":"118264","messageId":"20090719234500.6117@nanako3.lavabit.com","threadId":"20128","inReplyTo":"7vskgt1q3t.fsf@alter.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GIT 1.6.4.rc1","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-07-19T14:45:00Z","receivedAt":"2009-07-19T14:45:00Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> I wrote that side note after googling around and found that many users\n> outside git community wondering what a strange way to announce a new\n> feature it was, and I think they are right. I stupidly said that we\n> should tone the message neutral, because we might want to change the\n> default in the future but we are still not committed. But the end result\n> is just a confusing advertisement of an optional feature.\n>\n> I actually think that the right course of action at this point is this\n> patch instead. We keep the default, we do not annoy the users, and people\n> who want to use a non-default configuration can use the feature.\n\nAn alternative approach could be to rewrite the message to say that we will change the default to something other than 'matching' as the first step, and then apply Finn Arne's patch as the second step to really force people to choose, because I thought the plan was to switch the default to something other than the matching.\nBut apparently I misremembered. I googled and found nobody explaining that this message is a preparatory step for such transition. The only reactions I found were the ones that said this is a strange way to advertize a new feature.\nI think you are correct, and I think your patch is the right way forward.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"}]}