{"thread":{"id":"17807","subject":"[RFC - draft] List of proposed future changes that are backward incompatible","startedAt":"2009-02-15T21:31:50Z","lastAt":"2009-02-20T04:13:39Z","messageCount":91,"participants":["Junio C Hamano","david@lang.hm","Jakub Narebski","Johannes Schindelin","Heikki Orsila","Jeff King","Pieter de Bie","Sitaram Chamarty","Julian Phillips","Brian Gernhardt","SZEDER Gábor","Björn Steinbrink","Daniel Barkalow","Wincent Colaiuta","Sergio Callegari","Martin Mares","Sverre Rabbelier","Matthieu Moy","Jay Soffian","Andreas Ericsson","Eric W. Biederman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"104825","messageId":"7vk57ridyx.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":null,"subject":"[RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-15T21:31:50Z","receivedAt":"2009-02-15T21:31:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here is a draft; please discuss items that are already on the list to\nimprove their wording, and propose changes you would want to add to the\nlist, so that I can send the final message out when I tag v1.6.2-rc2.\n\nI originally considered to Cc: mailing list addresses of various projects\nthat use git when sending out the final message, but I do not think it is\npractical, as I suspect some/many are subscriber only (and I am not, and\nwould not want to be, a subscriber to them).\n\nSo instead, I'd like people from the projects that use git to forward the\nfinal message to the mailing lists they belong to, and we would want some\ncoordination among volunteers to avoid duplicated forwards.\n\nSomebody, please volunteer to keep a list of tuples. It might be a good idea to create a new page that is\nlinked from http://git.or.cz/gitwiki/GitProjects for that purpose.\n\nThanks.\n\n-- >8 -- cut here -- >8 --\n\nTo: git@vger.kernel.org\nSubject: [RFC/WARNING] Proposed future changes that are backward incompatible\n\nHere is a list of possible future changes to git that are backward\nincompatible that are under discussion on the git mailing list.\n\nNone of them will be in the upcoming 1.6.2 release, but some of them are\nlikely to appear in future versions. If you think we should not introduce\nsome of the listed changes, here is a chance to voice your opinions and\nmake a convincing argument against them, so please do so. Many people\ncomplained about the removal of many git-foo commands from user's PATH,\nwhich was done in 1.6.0 based on user input, after it happened. You do\nnot want to see such a mess happen again.\n\nThanks.\n\n* git-push to update the checked out branch will be refused by default\n\n Make \"git push\" into a repository to update the branch that is checked\n out fail by default.\n\n http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\n* git-push to delete the current branch will be refused by default\n\n Make \"git push $there :$killed\" to delete the branch that is pointed at\n by its HEAD fail by default.\n\n http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936\n\n* git-send-email won't make deep threads by default\n\n Many people said that by default when sending more than 2 patches the\n threading git-send-email makes by default is hard to read, and they\n prefer the default be one cover letter and each patch as a direct\n follow-up to the cover letter.\n\n http://article.gmane.org/gmane.comp.version-control.git/109790\n\n* make core.quotepath=false the default\n\n By default, \"git diff\" output quotes bytes in pathnames with high bit\n set, primarily to avoid corruption during e-mail based transfer. This\n however is inconvenient for human readers, and also makes some poorly\n written user scripts that do not unquote them fail. Change the default\n so that they are not quoted (note that control characters such as HT are\n always quoted).\n\n http://thread.gmane.org/gmane.comp.version-control.git/110033\n"},{"id":"104828","messageId":"7vfxifid6r.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"7vk57ridyx.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-15T21:48:44Z","receivedAt":"2009-02-15T21:48:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Somebody, please volunteer to keep a list of forwarder> tuples. It might be a good idea to create a new page that is\n> linked from http://git.or.cz/gitwiki/GitProjects for that purpose.\n\nPlease use http://git.or.cz/gitwiki/ProjectContacts for this.\n"},{"id":"104844","messageId":"m3k57rtilx.fsf@localhost.localdomain","threadId":"17807","inReplyTo":"7vfxifid6r.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-15T22:56:12Z","receivedAt":"2009-02-15T22:56:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n> \n> > Somebody, please volunteer to keep a list of > forwarder> tuples. It might be a good idea to create a new page that is\n> > linked from http://git.or.cz/gitwiki/GitProjects for that purpose.\n> \n> Please use http://git.or.cz/gitwiki/ProjectContacts for this.\n\nBy the way, you could blog it^W^W write about it on your blog.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"104845","messageId":"alpine.DEB.1.00.0902152358330.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-15T23:01:08Z","receivedAt":"2009-02-15T23:01:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Feb 2009, david@lang.hm wrote:\n\n> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n> \n> > Thanks.\n> >\n> > * git-push to update the checked out branch will be refused by default\n> >\n> > Make \"git push\" into a repository to update the branch that is checked\n> > out fail by default.\n> >\n> > http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n> \n> If I understand this one, it will cause grief for quite a few people.\n> \n> I have a public repository that I push to and then have a trigger that checks\n> out the current version, compiles it, publishes the compiled version, sends an\n> announcement, etc\n\nSo you have to set a config variable. Big deal.\n\nCompared to that, the thousands of new Git users will no longer be bitten \nby the \"do not push to a non-bare repository\" issue without a useful error \nmessage.\n\nPlease, please, publicize that if there is somebody who is doing the same \nas you (which I deem a dangerous workflow; I certainly do not use it \nmyself) that they will have to adjust their receive.denyCurrentBranch \nvariable.\n\nCiao,\nDscho\n"},{"id":"104846","messageId":"m3fxifticm.fsf@localhost.localdomain","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-15T23:01:48Z","receivedAt":"2009-02-15T23:01:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"david@lang.hm writes:\n\n> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n> \n> > Thanks.\n> >\n> > * git-push to update the checked out branch will be refused by default\n> >\n> > Make \"git push\" into a repository to update the branch that is checked\n> > out fail by default.\n> >\n> > http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n> \n> If I understand this one, it will cause grief for quite a few people.\n> \n> I have a public repository that I push to and then have a trigger that\n> checks out the current version, compiles it, publishes the compiled\n> version, sends an announcement, etc\n> \n> if I am understanding the purpose of this change, you would prohibit\n> the update from taking place.\n\nNo, you just have to configure it to enable it. In the meantime\n(before the change) you would get warnings unless you configure it.\n\n> > * git-send-email won't make deep threads by default\n> >\n> > Many people said that by default when sending more than 2 patches the\n> > threading git-send-email makes by default is hard to read, and they\n> > prefer the default be one cover letter and each patch as a direct\n> > follow-up to the cover letter.\n> >\n> > http://article.gmane.org/gmane.comp.version-control.git/109790\n> \n> I have mixed feelings about this one, if some messages get delayed in\n> transit the deep threads still keeps them in order, while the 2-layer\n> option doesn't.\n\nThat is whay you should use --numbered (and I think it should be\ndefault for --no-chain-reply-to), using [PATCH m/n] prefix.\n\nNote that usually you would have problems if patch arrive out of\norder, unless your enail client / news reader is able to rethread.\n\n> \n> that being said, I don't think it's that significant to change the\n> default.\n\nIt is much, much nicer when there is discussion on the patches in\npatch series to have 'shallow' threading (cover letter + patches\nnumbered being reply to cover letter).\n\nUnless you don't get review of patches, then deep threading might look\nas nice...\n\n\n> \n> one thing that would help new users is if there was a way to create a\n> git config file that explicitly listed all the defaults. either as a\n> sample config, or to expand the existing config file with all the\n> defaults listed, but commented out.\n> \n> I find that having such a config file helps me find config options I\n> never thought to look for.\n\nThat is a very good idea... if next to impossible now, I think, as\nthere is (I guess) no single place that stores default values. But\nperhaps I am mistaken.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"104849","messageId":"alpine.DEB.1.00.0902160009010.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"m3fxifticm.fsf@localhost.localdomain","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-15T23:15:00Z","receivedAt":"2009-02-15T23:15:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Feb 2009, Jakub Narebski wrote:\n\n> david@lang.hm writes:\n> \n> > one thing that would help new users is if there was a way to create a \n> > git config file that explicitly listed all the defaults. either as a \n> > sample config, or to expand the existing config file with all the \n> > defaults listed, but commented out.\n> > \n> > I find that having such a config file helps me find config options I\n> > never thought to look for.\n> \n> That is a very good idea... if next to impossible now, I think, as\n> there is (I guess) no single place that stores default values. But\n> perhaps I am mistaken.\n\nOf course, you have to ignore the fact that it would no longer possible to \nupdate defaults for existing repositories.\n\nFor example, setting something like receive.denyCurrentBranch to a saner \ndefault would not reach existing repositories.\n\nAnd you would also have to ignore the fact that sometimes, config \nvariables are deprecated, and this _also_ would not reach existing \nrepositories. Of course, the same holds true if you set such a config \nvariable manually, but then you are _supposed_ to know the config \nvariable, and you are unlikely to learn the name of an obsolete variable.\n\nDo keep in mind, too, that most of the variables are next to useless \nwithout the proper documentation. And do you really want to replicate \nDocumentation/config.txt in the config file? If not, how do you want to \nmake sure that the two different documentations do not go out of sync?\n\nFurther, it would be much, much harder to see what is _actually_ set.\n\nSummary: I do not like that idea.\n\nCiao,\nDscho\n"},{"id":"104850","messageId":"alpine.DEB.1.00.0902160016230.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151613110.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-15T23:18:17Z","receivedAt":"2009-02-15T23:18:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Feb 2009, david@lang.hm wrote:\n\n> On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n> \n> > On Sun, 15 Feb 2009, david@lang.hm wrote:\n> >\n> > > On Sun, 15 Feb 2009, Junio C Hamano wrote:\n> > >\n> > > > Thanks.\n> > > >\n> > > > * git-push to update the checked out branch will be refused by default\n> > > >\n> > > > Make \"git push\" into a repository to update the branch that is checked\n> > > > out fail by default.\n> > > >\n> > > > http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n> > >\n> > > If I understand this one, it will cause grief for quite a few people.\n> > >\n> > > I have a public repository that I push to and then have a trigger that\n> > > checks\n> > > out the current version, compiles it, publishes the compiled version,\n> > > sends an\n> > > announcement, etc\n> >\n> > So you have to set a config variable. Big deal.\n> >\n> > Compared to that, the thousands of new Git users will no longer be bitten\n> > by the \"do not push to a non-bare repository\" issue without a useful error\n> > message.\n> >\n> > Please, please, publicize that if there is somebody who is doing the same\n> > as you (which I deem a dangerous workflow; I certainly do not use it\n> > myself) that they will have to adjust their receive.denyCurrentBranch\n> > variable.\n> \n> since this repository isn't use for anything other than publishing for public\n> access, what's so dangerous about it?\n\nHey, you do what you want...\n\nI just keep in mind that it _is_ a working directory that can go dirty, \nfor whatever reasons.\n\nWhich is why _I_ do things like your workflow locally, even if that means \nthat I log onto another machine (which is then \"local\").\n\nBut again, it is your choice. And certainly, it will be possible in the \nfuture, too, just more deprecated than it is already.\n\nCiao,\nDscho\n"},{"id":"104860","messageId":"20090215232013.GA11543@zakalwe.fi","threadId":"17807","inReplyTo":"7vk57ridyx.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Heikki Orsila","fromEmail":"shdl@zakalwe.fi","sentAt":"2009-02-15T23:20:13Z","receivedAt":"2009-02-15T23:20:13Z","isPatch":false,"sender":{"key":"shdl@zakalwe.fi","avatar":null},"body":"On Sun, Feb 15, 2009 at 01:31:50PM -0800, Junio C Hamano wrote:\n> * git-push to update the checked out branch will be refused by default\n> \n> Make \"git push\" into a repository to update the branch that is checked\n> out fail by default.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\nIf this is implemented, it shouldn't, in my opinion, be a default \nsetting. I regularly push to checkout repos when I'm doing cross machine \ndevelopment. However, I could live with a configurable setting as \nproposed in the given URL. I think Git should not be too cautious about \nfollowing users instructions. The user knows what is best for him/her ;)\n\n-- \nHeikki Orsila\nheikki.orsila@iki.fi\nhttp://www.iki.fi/shd\n"},{"id":"104855","messageId":"7v3aefi87g.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902152358330.10279@pacific.mpi-cbg.de","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-15T23:36:19Z","receivedAt":"2009-02-15T23:36:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Sun, 15 Feb 2009, david@lang.hm wrote:\n>\n>> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n>> \n>> > Thanks.\n>> >\n>> > * git-push to update the checked out branch will be refused by default\n>> >\n>> > Make \"git push\" into a repository to update the branch that is checked\n>> > out fail by default.\n>> >\n>> > http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>> \n>> If I understand this one, it will cause grief for quite a few people.\n>> \n>> I have a public repository that I push to and then have a trigger that checks\n>> out the current version, compiles it, publishes the compiled version, sends an\n>> announcement, etc\n>\n> So you have to set a config variable. Big deal.\n>\n> Compared to that, the thousands of new Git users will no longer be bitten \n> by the \"do not push to a non-bare repository\" issue without a useful error \n> message.\n>\n> Please, please, publicize that if there is somebody who is doing the same \n> as you (which I deem a dangerous workflow; I certainly do not use it \n> myself) that they will have to adjust their receive.denyCurrentBranch \n> variable.\n\nYuck. I wasn't expecting a discussion itself here. This was a request\nfor help and comment for a future message that will ask to start the\ndiscussion.\n\nNo need to *stop* discussing, but please retitle the thread so that we can\nlater see which ones are discussion of a particular topic, and which ones\nare proposal for addition of new items.\n"},{"id":"104856","messageId":"200902160038.24838.jnareb@gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902160009010.10279@pacific.mpi-cbg.de","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-15T23:38:23Z","receivedAt":"2009-02-15T23:38:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello!\n\nOn Mon, 16 Feb 2009, Johannes Schindelin wrote:\n> On Sun, 15 Feb 2009, Jakub Narebski wrote:\n>> david@lang.hm writes:\n>> \n>>> one thing that would help new users is if there was a way to create a \n>>> git config file that explicitly listed all the defaults. either as a \n>>> sample config, or to expand the existing config file with all the \n>>> defaults listed, but commented out.\n>>> \n>>> I find that having such a config file helps me find config options I\n>>> never thought to look for.\n>> \n>> That is a very good idea... if next to impossible now, I think, as\n>> there is (I guess) no single place that stores default values. But\n>> perhaps I am mistaken.\n> \n> Of course, you have to ignore the fact that it would no longer possible to \n> update defaults for existing repositories.\n> \n> For example, setting something like receive.denyCurrentBranch to a saner \n> default would not reach existing repositories.\n\nYou missed that it would be a _sample_ config (or commented out sample\nconfig), and not the default config installed when creating repository.\n\nBut...\n\n> \n> And you would also have to ignore the fact that sometimes, config \n> variables are deprecated, and this _also_ would not reach existing \n> repositories. Of course, the same holds true if you set such a config \n> variable manually, but then you are _supposed_ to know the config \n> variable, and you are unlikely to learn the name of an obsolete variable.\n> \n> Do keep in mind, too, that most of the variables are next to useless \n> without the proper documentation. And do you really want to replicate \n> Documentation/config.txt in the config file? If not, how do you want to \n> make sure that the two different documentations do not go out of sync?\n> \n> Further, it would be much, much harder to see what is _actually_ set.\n> \n> Summary: I do not like that idea.\n\n... perhaps an alternate solution: add switch to git-config or git-var\nwhich would list (only list, no description) all defaults. Hmmm?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"104857","messageId":"7vy6w7gti4.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"m3k57rtilx.fsf@localhost.localdomain","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-15T23:39:15Z","receivedAt":"2009-02-15T23:39:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano writes:\n>\n>> Junio C Hamano writes:\n>> \n>> > Somebody, please volunteer to keep a list of > > forwarder> tuples. It might be a good idea to create a new page that is\n>> > linked from http://git.or.cz/gitwiki/GitProjects for that purpose.\n>> \n>> Please use http://git.or.cz/gitwiki/ProjectContacts for this.\n>\n> By the way, you could blog it^W^W write about it on your blog.\n\nHeh, I didn't think many people who need to know (or who would help with)\nthis follow mine, but it certainly wouldn't hurt.\n"},{"id":"104843","messageId":"alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"7vk57ridyx.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-15T23:53:50Z","receivedAt":"2009-02-15T23:53:50Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 15 Feb 2009, Junio C Hamano wrote:\n\n> Thanks.\n>\n> * git-push to update the checked out branch will be refused by default\n>\n> Make \"git push\" into a repository to update the branch that is checked\n> out fail by default.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\nIf I understand this one, it will cause grief for quite a few people.\n\nI have a public repository that I push to and then have a trigger that \nchecks out the current version, compiles it, publishes the compiled \nversion, sends an announcement, etc\n\nif I am understanding the purpose of this change, you would prohibit the \nupdate from taking place.\n\nthe message in the thread that you link to discusses how you want to be \ncareful about the change, but I have to hunt around through the rest of \nthe thread to figure out what the change really means (and I'm not sure I \nreally figured it out)\n\n> * git-send-email won't make deep threads by default\n>\n> Many people said that by default when sending more than 2 patches the\n> threading git-send-email makes by default is hard to read, and they\n> prefer the default be one cover letter and each patch as a direct\n> follow-up to the cover letter.\n>\n> http://article.gmane.org/gmane.comp.version-control.git/109790\n\nI have mixed feelings about this one, if some messages get delayed in \ntransit the deep threads still keeps them in order, while the 2-layer \noption doesn't.\n\nthat being said, I don't think it's that significant to change the \ndefault.\n\none thing that would help new users is if there was a way to create a git \nconfig file that explicitly listed all the defaults. either as a sample \nconfig, or to expand the existing config file with all the defaults \nlisted, but commented out.\n\nI find that having such a config file helps me find config options I never \nthought to look for.\n\nDavid Lang\n"},{"id":"104861","messageId":"20090216000220.GA3503@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151613110.14911@asgard.lang.hm","subject":"disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T00:02:20Z","receivedAt":"2009-02-16T00:02:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 04:14:20PM -0800, david@lang.hm wrote:\n\n>> Please, please, publicize that if there is somebody who is doing the same\n>> as you (which I deem a dangerous workflow; I certainly do not use it\n>> myself) that they will have to adjust their receive.denyCurrentBranch\n>> variable.\n>\n> since this repository isn't use for anything other than publishing for \n> public access, what's so dangerous about it?\n>\n> what do you think that I should be doing instead?\n\nWhat you are doing is not dangerous, because you are one of the clueful\nusers who understands that the repo is only for publishing, and has set\nup a hook to (or is manually triggering) a checkout of the new contents.\n\nIt is the less clueful user who doesn't realize that his working tree\nand index in the pushed-to repository contain totally bogus information\nwhich can cause him to create bad commits or even lose work permanently.\nDealing with this is one of the most common FAQ's we see on the list.\n\nSo the proposal is about making you, the clueful user, set a config\noption that promises you have a clue. Which is sad that this must impact\nyou, but unfortunately it is not a very good strategy to ask clueless\nusers to set a variable saying that they are so.\n\n-Peff\n"},{"id":"104862","messageId":"20090216000443.GB3503@coredump.intra.peff.net","threadId":"17807","inReplyTo":"20090215232013.GA11543@zakalwe.fi","subject":"disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T00:04:43Z","receivedAt":"2009-02-16T00:04:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 01:20:13AM +0200, Heikki Orsila wrote:\n\n> > * git-push to update the checked out branch will be refused by default\n> > \n> > Make \"git push\" into a repository to update the branch that is checked\n> > out fail by default.\n> > \n> > http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n> \n> If this is implemented, it shouldn't, in my opinion, be a default \n> setting. I regularly push to checkout repos when I'm doing cross machine \n> development. However, I could live with a configurable setting as \n> proposed in the given URL. I think Git should not be too cautious about \n> following users instructions. The user knows what is best for him/her ;)\n\nIt is already implemented; the proposal is about setting the default.\nThe plans for 1.6.2 are already to issue a warning and ask the user to\nset the config variable to shut it up.\n\n-Peff\n"},{"id":"104863","messageId":"20090216000732.GC3503@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm","subject":"send-email sending shallow threads by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T00:07:32Z","receivedAt":"2009-02-16T00:07:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:\n\n>> * git-send-email won't make deep threads by default\n>>\n>> Many people said that by default when sending more than 2 patches the\n>> threading git-send-email makes by default is hard to read, and they\n>> prefer the default be one cover letter and each patch as a direct\n>> follow-up to the cover letter.\n>>\n>> http://article.gmane.org/gmane.comp.version-control.git/109790\n>\n> I have mixed feelings about this one, if some messages get delayed in \n> transit the deep threads still keeps them in order, while the 2-layer \n> option doesn't.\n\nIs that the case? mutt at least orders by thread, but by rfc822 date\nwithin a single level of thread. So as long as the date fields (set by\nthe sender) are correct, it looks right no matter what order they arrive\nin.\n\nAre there common readers that thread but do not order by date?\n\n-Peff\n"},{"id":"104864","messageId":"5ABF2654-851C-47F3-9D3A-3F73F13AC5DC@ai.rug.nl","threadId":"17807","inReplyTo":"20090216000732.GC3503@coredump.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2009-02-16T00:09:11Z","receivedAt":"2009-02-16T00:09:11Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 16 feb 2009, at 00:07, Jeff King wrote:\n\n> Are there common readers that thread but do not order by date?\n\nApple's Mail orders by date received, rather than date sent\n"},{"id":"104847","messageId":"alpine.DEB.1.10.0902151613110.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902152358330.10279@pacific.mpi-cbg.de","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T00:14:20Z","receivedAt":"2009-02-16T00:14:20Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n\n> On Sun, 15 Feb 2009, david@lang.hm wrote:\n>\n>> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n>>\n>>> Thanks.\n>>>\n>>> * git-push to update the checked out branch will be refused by default\n>>>\n>>> Make \"git push\" into a repository to update the branch that is checked\n>>> out fail by default.\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>>\n>> If I understand this one, it will cause grief for quite a few people.\n>>\n>> I have a public repository that I push to and then have a trigger that checks\n>> out the current version, compiles it, publishes the compiled version, sends an\n>> announcement, etc\n>\n> So you have to set a config variable. Big deal.\n>\n> Compared to that, the thousands of new Git users will no longer be bitten\n> by the \"do not push to a non-bare repository\" issue without a useful error\n> message.\n>\n> Please, please, publicize that if there is somebody who is doing the same\n> as you (which I deem a dangerous workflow; I certainly do not use it\n> myself) that they will have to adjust their receive.denyCurrentBranch\n> variable.\n\nsince this repository isn't use for anything other than publishing for \npublic access, what's so dangerous about it?\n\nwhat do you think that I should be doing instead?\n\nDavid Lang\n"},{"id":"104868","messageId":"7vprhjgr6t.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151636510.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-16T00:29:14Z","receivedAt":"2009-02-16T00:29:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n>\n>>>> So you have to set a config variable. Big deal.\n>\n> the dashed names were the same way, but they definantly were a big deal.\n\nDscho, why do you think you saw the message you are responding to? If it\nwere not a big deal, I wouldn't have bothered.\n"},{"id":"104853","messageId":"alpine.DEB.1.10.0902151622530.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902160009010.10279@pacific.mpi-cbg.de","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T00:35:32Z","receivedAt":"2009-02-16T00:35:32Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Sun, 15 Feb 2009, Jakub Narebski wrote:\n>\n>> david@lang.hm writes:\n>>\n>>> one thing that would help new users is if there was a way to create a\n>>> git config file that explicitly listed all the defaults. either as a\n>>> sample config, or to expand the existing config file with all the\n>>> defaults listed, but commented out.\n>>>\n>>> I find that having such a config file helps me find config options I\n>>> never thought to look for.\n>>\n>> That is a very good idea... if next to impossible now, I think, as\n>> there is (I guess) no single place that stores default values. But\n>> perhaps I am mistaken.\n\nif there isn't, wouldn't it be a good idea to make one?\n\n> Of course, you have to ignore the fact that it would no longer possible to\n> update defaults for existing repositories.\n\nnot if the defaults are put into the config file commented out.\n\nthis way you can see all the options (and default settings), but still \ntell which ones are system defaults and which ones the user has set. I \nhave seen several projects that ship a config file that consists almost \nentirely of commented out items.\n\nalso, the first option I listed was to create a new file on-command that \nwould contain the defaults\n\n> For example, setting something like receive.denyCurrentBranch to a saner\n> default would not reach existing repositories.\n>\n> And you would also have to ignore the fact that sometimes, config\n> variables are deprecated, and this _also_ would not reach existing\n> repositories. Of course, the same holds true if you set such a config\n> variable manually, but then you are _supposed_ to know the config\n> variable, and you are unlikely to learn the name of an obsolete variable.\n>\n> Do keep in mind, too, that most of the variables are next to useless\n> without the proper documentation.\n\nin most cases the variable names are fairly descriptive. even if you have \nto go to the documentation to figure out what to set it to, seeing the \nname can point you to the right thing to search for in the documentation.\n\n> And do you really want to replicate\n> Documentation/config.txt in the config file? If not, how do you want to\n> make sure that the two different documentations do not go out of sync?\n\nhave one be auto-generated from the other and they won't be out of sync.\n\nalso note that I'm suggesting a git-config option that does this. not \nhaving it set at git-init time, so that users can run it long after the \nrepository was created and see the defaults for the current version of \ngit.\n\n> Further, it would be much, much harder to see what is _actually_ set.\n\nagain, not if the defaults are put in as commented out options\n\n> Summary: I do not like that idea.\n\nI'm not sure the idea you dislike so much is exactly what I proposed.\n\nDavid Lang\n"},{"id":"104854","messageId":"alpine.DEB.1.10.0902151636510.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902160016230.10279@pacific.mpi-cbg.de","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T00:38:36Z","receivedAt":"2009-02-16T00:38:36Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n\n> On Sun, 15 Feb 2009, david@lang.hm wrote:\n>\n>> On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n>>\n>>> On Sun, 15 Feb 2009, david@lang.hm wrote:\n>>>\n>>>> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n>>>>\n>>>>> Thanks.\n>>>>>\n>>>>> * git-push to update the checked out branch will be refused by default\n>>>>>\n>>>>> Make \"git push\" into a repository to update the branch that is checked\n>>>>> out fail by default.\n>>>>>\n>>>>> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>>>>\n>>>> If I understand this one, it will cause grief for quite a few people.\n>>>>\n>>>> I have a public repository that I push to and then have a trigger that\n>>>> checks\n>>>> out the current version, compiles it, publishes the compiled version,\n>>>> sends an\n>>>> announcement, etc\n>>>\n>>> So you have to set a config variable. Big deal.\n\nthe dashed names were the same way, but they definantly were a big deal.\n\n>>> Compared to that, the thousands of new Git users will no longer be bitten\n>>> by the \"do not push to a non-bare repository\" issue without a useful error\n>>> message.\n>>>\n>>> Please, please, publicize that if there is somebody who is doing the same\n>>> as you (which I deem a dangerous workflow; I certainly do not use it\n>>> myself) that they will have to adjust their receive.denyCurrentBranch\n>>> variable.\n>>\n>> since this repository isn't use for anything other than publishing for public\n>> access, what's so dangerous about it?\n>\n> Hey, you do what you want...\n>\n> I just keep in mind that it _is_ a working directory that can go dirty,\n> for whatever reasons.\n>\n> Which is why _I_ do things like your workflow locally, even if that means\n> that I log onto another machine (which is then \"local\").\n>\n> But again, it is your choice. And certainly, it will be possible in the\n> future, too, just more deprecated than it is already.\n\nplease be careful with the term 'deprecated', just becouse you would do \nsomething a different way doesn't make it 'deprecated', that term should \nonly be used for features that are on their way out of the product, but \nhaven't been removed yet.\n\nDavid Lang\n"},{"id":"104874","messageId":"slrngphg8n.hul.sitaramc@sitaramc.homelinux.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-16T01:27:51Z","receivedAt":"2009-02-16T01:27:51Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-15, david@lang.hm wrote:\n> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n>> * git-push to update the checked out branch will be refused by default\n>>\n>> Make \"git push\" into a repository to update the branch that is checked\n>> out fail by default.\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>\n> If I understand this one, it will cause grief for quite a few people.\n>\n> I have a public repository that I push to and then have a trigger that \n> checks out the current version, compiles it, publishes the compiled \n> version, sends an announcement, etc\n>\n> if I am understanding the purpose of this change, you would prohibit the \n> update from taking place.\n\nI didn't read the *entire* thread but I do believe prohibit\nis too strong. It's only the default behaviour that is\nbeing changed -- in your situation you'd just set\nreceive.denyCurrentBranch to either 'warn' (the current\ndefault) or 'ignore'.\n"},{"id":"104875","messageId":"alpine.LNX.2.00.0902160103090.7597@reaper.quantumfyre.co.uk","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151738450.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2009-02-16T01:30:05Z","receivedAt":"2009-02-16T01:30:05Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 15 Feb 2009, david@lang.hm wrote:\n\n> as I think about this more I'm puzzled as to why this is an issue.\n\nI think that you have a slightly misunderstanding of what fetch is usually \nconfigured to do.\n\n> I see mentions of it messing up the index and causing users to loose data, \n> but how is it different to push into a repository that has a workdir (with or \n> without dirty state in the workdir or in the index) and doing a fetch into \n> that repository.\n>\n> in both cases the new commits are added to the repository and the commit \n> pointed to by the branch changes, but if you do the fetch your HEAD and the \n> contents of the workdir and index aren't touched, why should a push do \n> something different?\n\nThis isn't the case. A fetch will only update the refs that refer to \nthe state of the remote repository. It will not update any of your local refs \n(unless you have a mirror setup - in which case a fetch is just as bad as \na push).\n\nSay we have two repositories, and local is cloned from remote:\n\nremote# git branch\n* master\n foo\n\nlocal# git branch #what branches do we have to work on?\n* master\n foo\n\nlocal# git branch -r #what branches do our remotes have?\n remote/master\n remote/foo\n\nIf we have updates on the master branch at remote, then \"git fetch remote\" \non local will update \"remote/master\", but will not affect \"master\" - the \ncurrently checked out branch. To update \"master\" we then have to either \nmerge \"remote/master\" (pull) or rebase \"master\" onto the new head of \n\"remote/master\" (pull --rebase).\n\nHowever, if we have updates on the master branch at local, then \"git push \nremote master\" will update \"master\" on the remote repository - the checked \nout branch. At which point the user has to know what they are doing, or \nrisk confusion and lost work, as any commit made on the remote branch will \nnot take account of the changes made by the pushed commits unless care is \ntaken to update the wordir first (and it doesn't make any difference if \nyou didn't have dirty state before the push).\n\n> I believe that if you fetch into a repository and someone else fetches from \n> you, they will get the content that's newer that what's in your dirty \n> workdir/index (I haven't tried it, but my understanding of the git internals \n> lead me to expect this to be the behavior)\n\nUnless they are also pulling your remote tracking branches (which is not \nthe default behaviour, and is a rather odd thing to do), then your fetch \nwill not change what they get from you as they only get your local \nbranches.\n\n> a pull would try to update the index, HEAD, and workdir, but I've seen many \n> discussions about how push and pull are not symetrical, but push and fetch \n> are (along with the moaning about bad names for the commands and the \n> historical explination of how they got that way)\n\nThey are symetrical in operation, but not in destination. Basically, the \nassumption is that when fetching the user is on that machine and will \nincorporate the updates themselves either using pull, or in a more manual \nway. With push, the assumption is that there is no user on the remote \nmachine only a lonely old server process, and that the changes should be \nimmediately made available to anyone accessing the repository.\n\n> If there is some reason for the normal push to try and update the HEAD, \n> index, and workdir. instead of refusing the push, how about having it put the \n> commits in the repository and then fail to change the HEAD, index, and \n> workdir if any of them contain changes? (along with a warning that it's doing \n> so).\n>\n> this should be safe to do because it will only flag on the particular \n> combination of events that will cause data loss rather than the broader \n> prohibition of \"don't push if there is a workdir\" that affects legitimate \n> uses as well\n>\n> David Lang\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-- \nJulian\n\n ---\nQ: Does Bill Gates use public domain software?\nA: Yes, as all of the public has become Bill Gates' domain.\n"},{"id":"104867","messageId":"alpine.DEB.1.10.0902151727330.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"20090216000443.GB3503@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T01:33:59Z","receivedAt":"2009-02-16T01:33:59Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 15 Feb 2009, Jeff King wrote:\n\n> On Mon, Feb 16, 2009 at 01:20:13AM +0200, Heikki Orsila wrote:\n>\n>>> * git-push to update the checked out branch will be refused by default\n>>>\n>>> Make \"git push\" into a repository to update the branch that is checked\n>>> out fail by default.\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>>\n>> If this is implemented, it shouldn't, in my opinion, be a default\n>> setting. I regularly push to checkout repos when I'm doing cross machine\n>> development. However, I could live with a configurable setting as\n>> proposed in the given URL. I think Git should not be too cautious about\n>> following users instructions. The user knows what is best for him/her ;)\n>\n> It is already implemented; the proposal is about setting the default.\n> The plans for 1.6.2 are already to issue a warning and ask the user to\n> set the config variable to shut it up.\n\nif this is going to be done the timeframe for making the change should be \nquite long. think in terms of debian stable or RHEL, whatever version they \nship is what their users are going to use. it doesn't matter how many new \nversions and what warnings you have the produce in the meantime, the users \nwon't see them.\n\nto the progression needs to be\n\none upgrade cycle the user is using the old version with no warning.\n\nnext upgrade cycle the user is using a version with a warning.\n\nthe third upgrade cycle the user is using the version with the default \nchanged.\n\nthe problem is that these upgrade cycles are 3-5 years each, and it's not \nunusual for the types of users that use dbian stable or RHEL to be running \nthese systems in places where they do not get patched during their \nlifetime.\n\nnote that this isn't always stupid to do, if you are deploying them on a \nnetwork with no Internet access the stability of knowing that things are \n_exactly_ what you tested may be worth more than updates that close bugs \nthat you don't hit or add features that you aren't using (or introduce \nunexpected changes like spitting warnings or errors for things that the \nold version didn't, which is exactly what is being proposed.\n\nDavid Lang\n"},{"id":"104870","messageId":"alpine.DEB.1.10.0902151738450.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151727330.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T01:47:37Z","receivedAt":"2009-02-16T01:47:37Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"as I think about this more I'm puzzled as to why this is an issue.\n\nI see mentions of it messing up the index and causing users to loose data, \nbut how is it different to push into a repository that has a workdir (with \nor without dirty state in the workdir or in the index) and doing a fetch \ninto that repository.\n\nin both cases the new commits are added to the repository and the commit \npointed to by the branch changes, but if you do the fetch your HEAD and \nthe contents of the workdir and index aren't touched, why should a push do \nsomething different?\n\nI believe that if you fetch into a repository and someone else fetches \nfrom you, they will get the content that's newer that what's in your dirty \nworkdir/index (I haven't tried it, but my understanding of the git \ninternals lead me to expect this to be the behavior)\n\na pull would try to update the index, HEAD, and workdir, but I've seen \nmany discussions about how push and pull are not symetrical, but push and \nfetch are (along with the moaning about bad names for the commands and the \nhistorical explination of how they got that way)\n\n\nIf there is some reason for the normal push to try and update the HEAD, \nindex, and workdir. instead of refusing the push, how about having it put \nthe commits in the repository and then fail to change the HEAD, index, and \nworkdir if any of them contain changes? (along with a warning that it's \ndoing so).\n\nthis should be safe to do because it will only flag on the particular \ncombination of events that will cause data loss rather than the broader \nprohibition of \"don't push if there is a workdir\" that affects legitimate \nuses as well\n\nDavid Lang\n"},{"id":"104880","messageId":"7vskmff6fp.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"7vk57ridyx.fsf@gitster.siamese.dyndns.org","subject":"[RFC - draft #2] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-16T02:42:50Z","receivedAt":"2009-02-16T02:42:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Let's scrap the first thread and try again, this time a bit more careful\nwording, so that premature and unwanted discussions would not cloud out\nwhat really needs to happen in response to this request.\n\nHere is a draft of a message I am preparing to send out around 1.6.2-rc2\nis tagged to this mailing list, and mailing list of the projects that use\ngit to track their changes, to announce possible future changes that may\naffect the users in a backward incompatible way, and solicit comments.\n\nI am asking three things now from the readership:\n\n - For items that are already on the list, help improve the way the\n planned/proposed changes are explained. Discussion on the desirability\n of the change itself is NOT WELCOME in this thread. That is for the\n discussion that follows the final version of this document.\n\n - If a change, that was discussed on this list recently and saw general\n consensus that such a change is desirable, is missing from this\n document, please send in updates in a similar format as you see below.\n\n - If your favourite project that uses git is not listed in:\n\n http://git.or.cz/gitwiki/ProjectContacts\n\n or it does not have \"Forwarder\" field filled in, please add the project\n with an appropriate address for the message to be sent.\n\n Be careful NOT to list a mailing list address that non-subscribers\n cannot send messages to. For such mailing lists, we need to find a\n subscribed volunteer to forward it. If you are volunteering, great.\n\nThanks.\n\n-- >8 -- cut here -- >8 --\n\nTo: git@vger.kernel.org\nSubject: [RFC/WARNING] Proposed future changes that are backward incompatible\n\nHere is a list of possible future changes to git that are backward\nincompatible that are under discussion on the git mailing list.\n\nNone of them will be in the upcoming 1.6.2 release, but some of them are\nlikely to appear in future versions. If you think we should not introduce\nsome of the listed changes, here is a chance to voice your opinions and\nmake a convincing argument against them, so please do so. Many people\ncomplained about the removal of many git-foo commands from user's PATH,\nwhich was done in 1.6.0 based on user input, after it happened. You do\nnot want to see such a mess happen again.\n\nThanks.\n\n* git-push to update the checked out branch will be refused by default\n\n Make \"git push\" into a repository to update the branch that is checked\n out fail by default. You can countermand this default by setting a\n configuration variable in the receiving repository.\n\n http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\n* git-push to delete the current branch will be refused by default\n\n Make \"git push $there :$killed\" to delete the branch that is pointed at\n by its HEAD fail by default. You can countermand this default by\n setting a configuration variable in the receiving repository.\n\n http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936\n\n* git-send-email won't make deep threads by default\n\n Many people said that by default when sending more than 2 patches the\n threading git-send-email makes by default is hard to read, and they\n prefer the default be one cover letter and each patch as a direct\n follow-up to the cover letter. You can countermand this by setting a\n configuration variable.\n\n http://article.gmane.org/gmane.comp.version-control.git/109790\n\n* make core.quotepath=false the default\n\n By default, \"git diff\" output quotes bytes in pathnames with high bit\n set, primarily to avoid corruption during e-mail based transfer. This\n however is inconvenient for human readers, and also makes some poorly\n written user scripts that do not unquote them fail. Change the default\n so that they are not quoted (note that control characters such as HT are\n always quoted). You can countermand this by setting a configuration\n variable.\n\n http://thread.gmane.org/gmane.comp.version-control.git/110033\n"},{"id":"104881","messageId":"20090216024308.GB18780@sigill.intra.peff.net","threadId":"17807","inReplyTo":"5ABF2654-851C-47F3-9D3A-3F73F13AC5DC@ai.rug.nl","subject":"Re: send-email sending shallow threads by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T02:43:08Z","receivedAt":"2009-02-16T02:43:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:\n\n> On 16 feb 2009, at 00:07, Jeff King wrote:\n>\n>> Are there common readers that thread but do not order by date?\n>\n> Apple's Mail orders by date received, rather than date sent\n\nHmph. I guess it is a potential problem, then. If you use Apple Mail,\ncan you report on whether out of order threads have been a problem\n(since earlier discussion revealed that both deep and shallow threads\nare found in the wild)?\n\n-Peff\n"},{"id":"104884","messageId":"D365EECA-C410-4DDF-83B5-7FA14C593FC1@silverinsanity.com","threadId":"17807","inReplyTo":"20090216024308.GB18780@sigill.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-02-16T02:55:17Z","receivedAt":"2009-02-16T02:55:17Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 15, 2009, at 9:43 PM, Jeff King wrote:\n\n> On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:\n>\n>> On 16 feb 2009, at 00:07, Jeff King wrote:\n>>\n>>> Are there common readers that thread but do not order by date?\n>>\n>> Apple's Mail orders by date received, rather than date sent\n>\n> Hmph. I guess it is a potential problem, then. If you use Apple Mail,\n> can you report on whether out of order threads have been a problem\n> (since earlier discussion revealed that both deep and shallow threads\n> are found in the wild)?\n\nI have noticed patches listed out of order, but I simply just open \nthem according to the [PATCH N/M] in the subject. I wouldn't really \ncall it a problem.\n\n~~ Brian\n"},{"id":"104890","messageId":"20090216032035.GA12235@coredump.intra.peff.net","threadId":"17807","inReplyTo":"7vskmff6fp.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft #2] List of proposed future changes that are backward incompatible","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T03:20:35Z","receivedAt":"2009-02-16T03:20:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 06:42:50PM -0800, Junio C Hamano wrote:\n\n> * git-push to update the checked out branch will be refused by default\n> \n> Make \"git push\" into a repository to update the branch that is checked\n> out fail by default. You can countermand this default by setting a\n> configuration variable in the receiving repository.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\nIt might be too subtle that \"checked out\" here implies a non-bare\nrepository (that is, somebody might think the HEAD branch in their bare\nrepo is \"checked out\"). So you might want to specifically mention\nnon-bare in the summary.\n\n> * make core.quotepath=false the default\n\nI have a comment on this, but I'll put it in a new thread. ;P\n\n-Peff\n"},{"id":"104894","messageId":"20090216035027.GA12689@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151727330.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T03:50:27Z","receivedAt":"2009-02-16T03:50:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 05:33:59PM -0800, david@lang.hm wrote:\n\n>> It is already implemented; the proposal is about setting the default.\n>> The plans for 1.6.2 are already to issue a warning and ask the user to\n>> set the config variable to shut it up.\n>\n> if this is going to be done the timeframe for making the change should be \n\nI don't know that a particular timeframe for switching the default has\nbeen chosen at this point. There is a short warning in 1.6.1, and a much\nmore comprehensive warning will be in 1.6.2 (which should be released\nshortly).\n\n> quite long. think in terms of debian stable or RHEL, whatever version they \n> ship is what their users are going to use. it doesn't matter how many new \n> versions and what warnings you have the produce in the meantime, the users \n> won't see them.\n\nSadly, Debian 5.0 just shipped with git 1.5.6.5, which has no warning\n(and dashed commands!).\n\n> note that this isn't always stupid to do, if you are deploying them on a \n> network with no Internet access the stability of knowing that things are \n> _exactly_ what you tested may be worth more than updates that close bugs \n> that you don't hit or add features that you aren't using (or introduce \n> unexpected changes like spitting warnings or errors for things that the \n> old version didn't, which is exactly what is being proposed.\n\nI'm not sure I understand your argument here. If you have a machine that\nneeds to do _exactly_ what you have tested, then wouldn't you be\nconcerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since\nyou are probably looking at a more macro-level, upgrading Debian 5.0 to\nDebian 6.0?\n\n-Peff\n"},{"id":"104898","messageId":"20090216040144.GB12689@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151738450.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T04:01:44Z","receivedAt":"2009-02-16T04:01:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 05:47:37PM -0800, david@lang.hm wrote:\n\n> as I think about this more I'm puzzled as to why this is an issue.\n\nFor background, see:\n\n http://thread.gmane.org/gmane.comp.version-control.git/100339\n\n http://thread.gmane.org/gmane.comp.version-control.git/107758\n\n http://article.gmane.org/gmane.comp.version-control.git/108918\n\n> in both cases the new commits are added to the repository and the commit \n> pointed to by the branch changes, but if you do the fetch your HEAD and \n> the contents of the workdir and index aren't touched, why should a push do \n> something different?\n\nThe short answer to your confusion is that fetch stores the updates in\n\"remote tracking refs\" (in refs/remotes/) but push pushes directly into\nthe refs/heads/ hierarchy.\n\nNote that you could set up an alternate push refspec in your client that\npushes into refs/remotes/. But then people fetching from it would have\nto know to fetch from their instead of the regular refs/heads/ portion.\n\n> I believe that if you fetch into a repository and someone else fetches \n> from you, they will get the content that's newer that what's in your dirty \n> workdir/index (I haven't tried it, but my understanding of the git \n> internals lead me to expect this to be the behavior)\n\nNo, they won't. Because when you fetch, your \"refs/heads/master\" branch\n(for example) is not updated. Your \"refs/remotes/origin/master\" branch\nis.\n\n> If there is some reason for the normal push to try and update the HEAD, \n> index, and workdir. instead of refusing the push, how about having it put \n> the commits in the repository and then fail to change the HEAD, index, and \n> workdir if any of them contain changes? (along with a warning that it's \n> doing so).\n\nThe question is where would it \"put\" the commits if not in the branch\nyou asked for, which is the one pointed to by \"HEAD\"?\n\n> this should be safe to do because it will only flag on the particular \n> combination of events that will cause data loss rather than the broader \n> prohibition of \"don't push if there is a workdir\" that affects legitimate \n> uses as well\n\nIt's not \"don't push if there is a workdir\". It's \"don't push into the\nref that is pointed to by HEAD\". Which is the exact situation that\ncauses problems.\n\n-Peff\n"},{"id":"104899","messageId":"20090216040529.GC12689@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902152057500.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T04:05:29Z","receivedAt":"2009-02-16T04:05:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@lang.hm wrote:\n\n>> I'm not sure I understand your argument here. If you have a machine that\n>> needs to do _exactly_ what you have tested, then wouldn't you be\n>> concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since\n>> you are probably looking at a more macro-level, upgrading Debian 5.0 to\n>> Debian 6.0?\n>\n> two points\n>\n> 1. someone running Debian 5 who then upgrades to Debian 6 should get the \n> warning, not the refusal, then when they go to Debian 7 the refusal can be \n> the standard (and substatute redhat enterprise version numbers for debian \n> if you want)\n\nSo people doing major version upgrades of their OS don't need to read\nrelease notes or re-test behavior?\n\nWhat about people who skip straight from 5 to 7? It's OK for them not to\nsee the warning, because two major versions means they should read the\nrelease notes and re-test?\n\n> so a warning can go in at any time, but changing the default in a way \n> that's not backwards compatible needs to be done over a _very_ long \n> timeframe. so long that it's worth questioning if it's worth changing (as \n> opposed to either just leaving the warning, or trying to figure out a \n> different way)\n\nThere has been a lot of questioning, and a lot of discussion of\nalternatives already. Please check the list archive for some of it.\n\nI don't think there is a timetable set at this point.\n\n-Peff\n"},{"id":"104902","messageId":"20090216043708.GB12986@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902152113380.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T04:37:09Z","receivedAt":"2009-02-16T04:37:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:\n\n>> So people doing major version upgrades of their OS don't need to read\n>> release notes or re-test behavior?\n>\n> when was the last time you read the release notes for an entire distro?\n\nSince you ask, I track Debian unstable and I read the release notes\n(NEWS.Debian) for every package that I upgrade, and skim the changelogs\nfor perhaps half.\n\nBut yes, I realize that is not common; I don't expect that every user\nreads every release note.\n\nMy point is that things _are_ going to change in a major version OS\nupgrade. It is up to the user to make the tradeoff of how much time they\nwant to spend researching those changes versus the likelihood and\nseverity of breakage. If I have a mission critical system running git,\nI'm going to read git's release notes. If I don't, then I will probably\naccept that something could break, and fix it if it does.\n\n> and it's not a matter of reading the release notes. it's a matter of them \n> running a version that gives them a warning before you feed them a version \n> that will cause their existing stuff to fail.\n\nThe warning is not a panacea:\n\n 1. It might actually cause breakage. Less likely than a straight\n change in behavior, but still possible.\n\n 2. Users don't necessarily see the warning. By definition, it is not\n changing the behavior. So unless they are examining the output\n (which might not be the case for an unattended system), it can go\n unnoticed.\n\nSo all of the problems you are talking about are still possible even\nwith an extremely long change cycle.\n\n> I recognise that not all software is concerned about backwards \n> compatibility, but if git wasn't concerned with backwards compatibility \n> and a graceful upgrade process, this thread wouldn't exist.\n\nI think git is much better about backwards compatibility than most\npackages I have seen. But there is a cost to maintaining it completely\nand forever, in that you are either hampered in what you can do (i.e.,\nthere are enhancements you would like to make but can't) or you pay an\nawful burden in development cost maintaining two diverging codebases.\n\nBased on the numbers in your last email, you seem to be advocating a\n9-15 year lag on making any behavior changes in git. I'm sorry, but I\nhave no interest in waiting that long to see enhancements I work on in\ngit make it into a released version.\n\nI think Junio is doing a fine job at dealing with backwards\ncompatibility and keeping things moving at a reasonable pace. If you\nthink it should go slower, you are certainly welcome to fork and release\nan \"ultra-stable\" version of git that reverts any backwards incompatible\nchanges while keeping up with other new features.\n\n-Peff\n"},{"id":"104897","messageId":"alpine.DEB.1.10.0902152057500.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"20090216035027.GA12689@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T05:05:33Z","receivedAt":"2009-02-16T05:05:33Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 15 Feb 2009, Jeff King wrote:\n\n>>> It is already implemented; the proposal is about setting the default.\n>>> The plans for 1.6.2 are already to issue a warning and ask the user to\n>>> set the config variable to shut it up.\n>>\n>> if this is going to be done the timeframe for making the change should be\n>\n> I don't know that a particular timeframe for switching the default has\n> been chosen at this point. There is a short warning in 1.6.1, and a much\n> more comprehensive warning will be in 1.6.2 (which should be released\n> shortly).\n>\n>> quite long. think in terms of debian stable or RHEL, whatever version they\n>> ship is what their users are going to use. it doesn't matter how many new\n>> versions and what warnings you have the produce in the meantime, the users\n>> won't see them.\n>\n> Sadly, Debian 5.0 just shipped with git 1.5.6.5, which has no warning\n> (and dashed commands!).\n>\n>> note that this isn't always stupid to do, if you are deploying them on a\n>> network with no Internet access the stability of knowing that things are\n>> _exactly_ what you tested may be worth more than updates that close bugs\n>> that you don't hit or add features that you aren't using (or introduce\n>> unexpected changes like spitting warnings or errors for things that the\n>> old version didn't, which is exactly what is being proposed.\n>\n> I'm not sure I understand your argument here. If you have a machine that\n> needs to do _exactly_ what you have tested, then wouldn't you be\n> concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since\n> you are probably looking at a more macro-level, upgrading Debian 5.0 to\n> Debian 6.0?\n\ntwo points\n\n1. someone running Debian 5 who then upgrades to Debian 6 should get the \nwarning, not the refusal, then when they go to Debian 7 the refusal can be \nthe standard (and substatute redhat enterprise version numbers for debian \nif you want)\n\n2. you can't count on users upgrading any faster than I tak about in \n#1. Debian shipped 1.5.6.5 in 5.0, when users upgrade to Debian 6.0, you \ncan't assume that they _ever_ patched the system, so even if you released \na 1.5.6.6 today that had the warning in it, you can't assume that users \nsaw it and so it's safe to remove the dashed commands in the version that \nwill ship with Debian 6.0.\n\nso a warning can go in at any time, but changing the default in a way \nthat's not backwards compatible needs to be done over a _very_ long \ntimeframe. so long that it's worth questioning if it's worth changing (as \nopposed to either just leaving the warning, or trying to figure out a \ndifferent way)\n\nDavid Lang\n"},{"id":"104904","messageId":"20090216050608.GA13181@coredump.intra.peff.net","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902152143430.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T05:06:08Z","receivedAt":"2009-02-16T05:06:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 15, 2009 at 09:55:24PM -0800, david@lang.hm wrote:\n\n> two cycles of changes, not three, so 6-10 years for changes that break \n> existing bahavior without a _really_ pressing reason. so new functions, \n> new commands, new flags don't have to wait at all. it's only if you want \n> to change something that will cause grief for users if they get a new \n> version and run their existing tools against it.\n\nI think you have to think about _how much_ grief it will cause, too.\n\nYes, some git enhancements are purely new functions and features that\nwill not affect anyone who does not opt into them. But many\nenhancements cover cases that _must_ change behavior. Even bugfixes fall\ninto this category. Who is to say somebody is not relying on the buggy\nbehavior? So there must be some discretion for the maintainer to say\n\"Anyone relying on this behavior is probably crazy\".\n\nAnd so there is some degree of cost-benefit. How much pain will this\ncause versus how much good will it do?\n\n> I am not interested in forking git. but I am saying that a backwards \n> incompatible change had better _really_ be worth it, and not just be worth \n> it for the people who live an breath git, but for the users as well (this \n> is a test that the dashed name elimination failed. in spite of a volcal \n> few saying that all the commands in the path were causing problems, most \n> people couldn't understand why the git people wanted to remove them)\n\nHave you read the related threads in the archive? I think there is a\nsignificant sentiment that this change _is_ really worth it. The current\nbehavior is hurting new users. I think the general consensus is that the\ndefault should change; the question is how and when.\n\nThe dashed-names change didn't go so well. You can argue whether or not\nit was a good change in the first place, but that is beside the point.\nThe lesson to be learned there is that _how_ it was done could have been\nbetter. One of the things we are trying differently is having the\nwarning. Another is that Junio is putting together a contact list for\nmajor projects using git. If you have a suggestion for another\ntechnique, I'm sure people will be open to it.\n\nAnd as I said, I don't think a timetable has been set. But I would be\nsurprised if it ends up in the 6-10 year range.\n\n-Peff\n"},{"id":"104900","messageId":"alpine.DEB.1.10.0902152113380.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"20090216040529.GC12689@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T05:18:47Z","receivedAt":"2009-02-16T05:18:47Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 15 Feb 2009, Jeff King wrote:\n\n> On Sun, Feb 15, 2009 at 09:05:33PM -0800, david@lang.hm wrote:\n>\n>>> I'm not sure I understand your argument here. If you have a machine that\n>>> needs to do _exactly_ what you have tested, then wouldn't you be\n>>> concerned about upgrading git 1.5.6.5 to (for example) git 1.7? Or since\n>>> you are probably looking at a more macro-level, upgrading Debian 5.0 to\n>>> Debian 6.0?\n>>\n>> two points\n>>\n>> 1. someone running Debian 5 who then upgrades to Debian 6 should get the\n>> warning, not the refusal, then when they go to Debian 7 the refusal can be\n>> the standard (and substatute redhat enterprise version numbers for debian\n>> if you want)\n>\n> So people doing major version upgrades of their OS don't need to read\n> release notes or re-test behavior?\n\nwhen was the last time you read the release notes for an entire distro?\n\nthey will test behavior, but if things that used to work just fail it's \nnot good.\n\n> What about people who skip straight from 5 to 7? It's OK for them not to\n> see the warning, because two major versions means they should read the\n> release notes and re-test?\n\nfor the 'enterprise distros' you would need to upgrade from 5 to 6 to 7 to \nremain supported. if you go directly from 5 to 7 you have been in \nunsupported territory for quite some time (probably measured in years).\n\nand it's not a matter of reading the release notes. it's a matter of them \nrunning a version that gives them a warning before you feed them a version \nthat will cause their existing stuff to fail.\n\nI recognise that not all software is concerned about backwards \ncompatibility, but if git wasn't concerned with backwards compatibility \nand a graceful upgrade process, this thread wouldn't exist.\n\nDavid Lang\n\n>> so a warning can go in at any time, but changing the default in a way\n>> that's not backwards compatible needs to be done over a _very_ long\n>> timeframe. so long that it's worth questioning if it's worth changing (as\n>> opposed to either just leaving the warning, or trying to figure out a\n>> different way)\n>\n> There has been a lot of questioning, and a lot of discussion of\n> alternatives already. Please check the list archive for some of it.\n>\n> I don't think there is a timetable set at this point.\n>\n> -Peff\n>\n"},{"id":"104903","messageId":"alpine.DEB.1.10.0902152143430.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"20090216043708.GB12986@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T05:55:24Z","receivedAt":"2009-02-16T05:55:24Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 15 Feb 2009, Jeff King wrote:\n\n> On Sun, Feb 15, 2009 at 09:18:47PM -0800, david@lang.hm wrote:\n>\n>>> So people doing major version upgrades of their OS don't need to read\n>>> release notes or re-test behavior?\n>>\n>> when was the last time you read the release notes for an entire distro?\n>\n> Since you ask, I track Debian unstable and I read the release notes\n> (NEWS.Debian) for every package that I upgrade, and skim the changelogs\n> for perhaps half.\n>\n> But yes, I realize that is not common; I don't expect that every user\n> reads every release note.\n>\n> My point is that things _are_ going to change in a major version OS\n> upgrade. It is up to the user to make the tradeoff of how much time they\n> want to spend researching those changes versus the likelihood and\n> severity of breakage. If I have a mission critical system running git,\n> I'm going to read git's release notes. If I don't, then I will probably\n> accept that something could break, and fix it if it does.\n\nin that case there's no reason for any warning time. just change the \ndefault and put a comment about it in the changelog.\n\nthat worked well for the dashed names didn't it.\n\n>> and it's not a matter of reading the release notes. it's a matter of them\n>> running a version that gives them a warning before you feed them a version\n>> that will cause their existing stuff to fail.\n>\n> The warning is not a panacea:\n>\n> 1. It might actually cause breakage. Less likely than a straight\n> change in behavior, but still possible.\n>\n> 2. Users don't necessarily see the warning. By definition, it is not\n> changing the behavior. So unless they are examining the output\n> (which might not be the case for an unattended system), it can go\n> unnoticed.\n>\n> So all of the problems you are talking about are still possible even\n> with an extremely long change cycle.\n>\n>> I recognise that not all software is concerned about backwards\n>> compatibility, but if git wasn't concerned with backwards compatibility\n>> and a graceful upgrade process, this thread wouldn't exist.\n>\n> I think git is much better about backwards compatibility than most\n> packages I have seen. But there is a cost to maintaining it completely\n> and forever, in that you are either hampered in what you can do (i.e.,\n> there are enhancements you would like to make but can't) or you pay an\n> awful burden in development cost maintaining two diverging codebases.\n>\n> Based on the numbers in your last email, you seem to be advocating a\n> 9-15 year lag on making any behavior changes in git. I'm sorry, but I\n> have no interest in waiting that long to see enhancements I work on in\n> git make it into a released version.\n\ntwo cycles of changes, not three, so 6-10 years for changes that break \nexisting bahavior without a _really_ pressing reason. so new functions, \nnew commands, new flags don't have to wait at all. it's only if you want \nto change something that will cause grief for users if they get a new \nversion and run their existing tools against it.\n\n> I think Junio is doing a fine job at dealing with backwards\n> compatibility and keeping things moving at a reasonable pace. If you\n> think it should go slower, you are certainly welcome to fork and release\n> an \"ultra-stable\" version of git that reverts any backwards incompatible\n> changes while keeping up with other new features.\n\nI am not interested in forking git. but I am saying that a backwards \nincompatible change had better _really_ be worth it, and not just be worth \nit for the people who live an breath git, but for the users as well (this \nis a test that the dashed name elimination failed. in spite of a volcal \nfew saying that all the commands in the path were causing problems, most \npeople couldn't understand why the git people wanted to remove them)\n\nfor anything less than a fairly critical bug, if it's in a public \ninterface you really don't want to change it (in part becouse the \ntimeframe to properly depriciate it, with warnings, needs to happen on \ntimescales measured in years)\n\nand I agree that Junio is doing a good job with this. he's the one who \nstarted this thread to discuss the possible changes after all.\n\nDavid Lang\n\n> -Peff\n>\n"},{"id":"104910","messageId":"20090216075534.GA11838@neumann","threadId":"17807","inReplyTo":"20090216000732.GC3503@coredump.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-02-16T07:55:34Z","receivedAt":"2009-02-16T07:55:34Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\nOn Sun, Feb 15, 2009 at 07:07:32PM -0500, Jeff King wrote:\n> On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:\n> > I have mixed feelings about this one, if some messages get delayed in \n> > transit the deep threads still keeps them in order, while the 2-layer \n> > option doesn't.\n> \n> Is that the case? mutt at least orders by thread, but by rfc822 date\n> within a single level of thread. So as long as the date fields (set by\n> the sender) are correct, it looks right no matter what order they arrive\n> in.\n> \n> Are there common readers that thread but do not order by date?\n\nGmane.\n\n(e.g. http://thread.gmane.org/gmane.comp.version-control.git/110068)\n\nRegards,\nGábor\n"},{"id":"104911","messageId":"20090216080432.GA16453@atjola.homenet","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-02-16T08:04:32Z","receivedAt":"2009-02-16T08:04:32Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.02.15 15:53:50 -0800, david@lang.hm wrote:\n> On Sun, 15 Feb 2009, Junio C Hamano wrote:\n>\n>> Thanks.\n>>\n>> * git-push to update the checked out branch will be refused by default\n>>\n>> Make \"git push\" into a repository to update the branch that is checked\n>> out fail by default.\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n>\n> If I understand this one, it will cause grief for quite a few people.\n>\n> I have a public repository that I push to and then have a trigger that \n> checks out the current version, compiles it, publishes the compiled \n> version, sends an announcement, etc\n>\n> if I am understanding the purpose of this change, you would prohibit the \n> update from taking place.\n\nIn the \"non-bare\" FAQ entry, there's a link to a post-update hook that\ntries to resolve pushes to the branch head referenced by HEAD, and\nat least on #git, there were people that preferred using that hook\ninstead of setting up a bare repo. So you're probably not the only one\nwith such a setup.\n\nHow about having the default in the code being a warning, but the\ndefault for new repos being \"reject\"? IOW, set receive.denyCurrentBranch\naccordingly in the .git/config file for new non-bare repos? That way,\nfor your existing repos, you get a warning with instruction that you can\nset a config entry to kill the warning or to forbid the potentially\ndestructive operation. So it's just a new warning, and your existing\nsetups don't break.\n\nBut for new repos, you get the rejection behaviour and have to change\nthe config if you really want to push to the current branch, along with\nsetting up the hook and whatever else you need, so it's just one more\nstep you need to take now.\n\nBjörn\n"},{"id":"104912","messageId":"alpine.LNX.1.00.0902160322530.19665@iabervon.org","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151738450.14911@asgard.lang.hm","subject":"Re: disallowing push to currently checked-out branch","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-02-16T08:33:29Z","receivedAt":"2009-02-16T08:33:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 15 Feb 2009, david@lang.hm wrote:\n\n> If there is some reason for the normal push to try and update the HEAD, index,\n> and workdir. instead of refusing the push, how about having it put the commits\n> in the repository and then fail to change the HEAD, index, and workdir if any\n> of them contain changes? (along with a warning that it's doing so).\n\nA push cannot help but update HEAD, because HEAD is generally literally \n\"ref: refs/heads/\"; it doesn't store its own value, and \nthe storage that it references is the storage that push is updating.\n\nIn fact, if you expect to be pushing to a non-bare repository, you \nprobably want to have HEAD contain the actual commit currently checked out \n(instead of a reference to externally mutable storage), which you can do \nwith \"git checkout refs/heads/master\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"104913","messageId":"7viqnabwb3.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"20090216080432.GA16453@atjola.homenet","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-16T08:49:52Z","receivedAt":"2009-02-16T08:49:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> How about having the default in the code being a warning, but the\n> default for new repos being \"reject\"?\n\nTo reserve time to manage git itself, I will try not to point people to\nprevious discussions, but I'd like help from people who've already seen\nthe previous discussions to do so. This is one of the things that was\nproposed and already shot down.\n"},{"id":"104914","messageId":"7veixybw7u.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"alpine.LNX.1.00.0902160322530.19665@iabervon.org","subject":"Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-16T08:51:49Z","receivedAt":"2009-02-16T08:51:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> In fact, if you expect to be pushing to a non-bare repository, you\n> probably want to have HEAD contain the actual commit currently checked\n> out (instead of a reference to externally mutable storage), which you\n> can do with \"git checkout refs/heads/master\".\n\n\"git checkout master^0\" is shorter ;-)\n\nFor people who do not follow the git list regularly, a \"HEAD contain the\nactual commit\" is often called \"detached\".\n"},{"id":"104916","messageId":"20090216090741.GB16453@atjola.homenet","threadId":"17807","inReplyTo":"7viqnabwb3.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-02-16T09:07:41Z","receivedAt":"2009-02-16T09:07:41Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.02.16 00:49:52 -0800, Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n> > How about having the default in the code being a warning, but the\n> > default for new repos being \"reject\"?\n> \n> To reserve time to manage git itself, I will try not to point people to\n> previous discussions, but I'd like help from people who've already seen\n> the previous discussions to do so. This is one of the things that was\n> proposed and already shot down.\n\nOK, I'm sorry. Seems that my quick look through the other thread was too\nquick :-(\n\nBjörn\n"},{"id":"104921","messageId":"2612F8BC-FF9F-4708-A4A1-A64F680D6B1F@wincent.com","threadId":"17807","inReplyTo":"20090216024308.GB18780@sigill.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-02-16T09:56:16Z","receivedAt":"2009-02-16T09:56:16Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 16/2/2009, a las 3:43, Jeff King escribió:\n\n> On Mon, Feb 16, 2009 at 12:09:11AM +0000, Pieter de Bie wrote:\n>\n>> On 16 feb 2009, at 00:07, Jeff King wrote:\n>>\n>>> Are there common readers that thread but do not order by date?\n>>\n>> Apple's Mail orders by date received, rather than date sent\n>\n> Hmph. I guess it is a potential problem, then. If you use Apple Mail,\n> can you report on whether out of order threads have been a problem\n> (since earlier discussion revealed that both deep and shallow threads\n> are found in the wild)?\n\nYes, I use Apple Mail and I often see out-of-order threads.\n\nBut frankly, this is a total non-problem with absolutely zero impact \n(given that most people use numbered subject lines and it is easy to \nsee the order in which the patches should be read).\n\nCheers,\nWincent\n"},{"id":"104925","messageId":"loom.20090216T095523-830@post.gmane.org","threadId":"17807","inReplyTo":"20090216000220.GA3503@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-02-16T10:06:37Z","receivedAt":"2009-02-16T10:06:37Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"In my workflows (and let me remark it, in mine, which might well be mine only or\neven very stupid), what would be nice would be the possibility of triggering the\nfollowing scenario:\n\n- When you push to a repo which is not bare, if you push to a checked out\nbranch, the branch gets updated, the worktree is not touched, the head becomes\ndetached, the branch the head was on gets saved somewhere, and when someone\ntries asking for status or committing on the repo he gets a message like:\n\n\"The branch has been changed behind your shoulders from remote. Your work tree\nchanges are anyway safe. Head has been detached, your former branch was .... You\ncan either:\n- start a new branch with the changes that are currently in your worktree with\ncommand so and so...\n- stash the current status, peek at the new head of your former branch, try\napplying your current changes there.\"\n\nAlso it would be nice to be able to store my \"standard initial setup\" in\n.gitinit or something like this, so that whenever I git init I have my own\ndefaults (which is not the same as having global config info).\n\n...thanks for pre-announcing incompatible changes.\n\nSergio\n"},{"id":"104926","messageId":"loom.20090216T101457-231@post.gmane.org","threadId":"17807","inReplyTo":"7veixybw7u.fsf@gitster.siamese.dyndns.org","subject":"Re: disallowing push to currently checked-out branch","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-02-16T10:17:01Z","receivedAt":"2009-02-16T10:17:01Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Junio C Hamano pobox.com> writes:\n\n> \n> Daniel Barkalow iabervon.org> writes:\n> \n> > In fact, if you expect to be pushing to a non-bare repository, you\n> > probably want to have HEAD contain the actual commit currently checked\n> > out (instead of a reference to externally mutable storage), which you\n> > can do with \"git checkout refs/heads/master\".\n> \n> \"git checkout master^0\" is shorter \n> \n> For people who do not follow the git list regularly, a \"HEAD contain the\n> actual commit\" is often called \"detached\".\n> \n\n\nCould you have that done automatically?\nNamely rather to denying push to a branch b where HEAD->b, when you get such\npush you detach head?\n"},{"id":"104928","messageId":"alpine.DEB.1.00.0902161121290.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902151636510.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T10:23:26Z","receivedAt":"2009-02-16T10:23:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Feb 2009, david@lang.hm wrote:\n\n> please be careful with the term 'deprecated', just becouse you would do \n> something a different way doesn't make it 'deprecated', that term should \n> only be used for features that are on their way out of the product, but \n> haven't been removed yet.\n\nIt is not deprecated because I do not like it. Actually, I am pretty \nindifferent about the pushing into a non-bare repository.\n\nIt is deprecated because a lot of people active in the Git community spend \na real lot of time explaining to a whole bunch of new users on IRC and \nrecently even on this list why their pushing into a non-bare repository \ndoes not work, and why their suggestions how to solve the issue does not \nwork either.\n\nHth,\nDscho\n"},{"id":"104934","messageId":"mj+md-20090216.103512.5791.nikam@ucw.cz","threadId":"17807","inReplyTo":"20090216000732.GC3503@coredump.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Martin Mares","fromEmail":"mj@ucw.cz","sentAt":"2009-02-16T10:38:24Z","receivedAt":"2009-02-16T10:38:24Z","isPatch":false,"sender":{"key":"mj@ucw.cz","avatar":null},"body":"Hello, world!\\n\n\n> Is that the case? mutt at least orders by thread, but by rfc822 date\n> within a single level of thread. So as long as the date fields (set by\n> the sender) are correct, it looks right no matter what order they arrive in.\n\nActually, it matters, because the Date field has limited precision\nand it frequently happens that the sender produces several mails\nwithin a single second.\n\n\t\t\t\tHave a nice fortnight\n-- \nMartin `MJ' Mares http://mj.ucw.cz/\nFaculty of Math and Physics, Charles University, Prague, Czech Rep., Earth\nPress any key to quit or any other key to continue\n"},{"id":"104931","messageId":"alpine.DEB.1.00.0902161147390.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902152143430.14911@asgard.lang.hm","subject":"dashed commands, was Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T10:50:12Z","receivedAt":"2009-02-16T10:50:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Feb 2009, david@lang.hm wrote:\n\n> I am not interested in forking git. but I am saying that a backwards \n> incompatible change had better _really_ be worth it, and not just be \n> worth it for the people who live an breath git, but for the users as \n> well (this is a test that the dashed name elimination failed. in spite \n> of a volcal few saying that all the commands in the path were causing \n> problems, most people couldn't understand why the git people wanted to \n> remove them)\n\nNope. It was not just because we could. It was an explicit request by \nmore than one person that we do not put 110+ commands into /usr/bin/.\n\nAs for your argument that it should be worth for the users: if you are \nreally thinking about the users, and not just yourself, you will see that \nthe receive.denyCurrentBranch change is required.\n\nBTW there is a timeline. Junio said already that it will be in 1.7 and \nnot earlier.\n\nCiao,\nDscho\n"},{"id":"104932","messageId":"alpine.DEB.1.00.0902161150500.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"20090216050608.GA13181@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T10:53:45Z","receivedAt":"2009-02-16T10:53:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Feb 2009, Jeff King wrote:\n\n> On Sun, Feb 15, 2009 at 09:55:24PM -0800, david@lang.hm wrote:\n> \n> > two cycles of changes, not three, so 6-10 years for changes that break \n> > existing bahavior without a _really_ pressing reason. so new \n> > functions, new commands, new flags don't have to wait at all. it's \n> > only if you want to change something that will cause grief for users \n> > if they get a new version and run their existing tools against it.\n> \n> I think you have to think about _how much_ grief it will cause, too.\n\nExactly.\n\nBTW I already get angry questions by Git users why this bug -- as they \nthink about it -- is not fixed in the next Git release, and I patiently \nexplain that a lot of existing users would get hurt by that change.\n\nAnd on this list I get flak when pushing for Git users' needs (who will \nnever be subscribed to the Git list because of the sheer volume).\n\nI guess if both camps would just start to think a little bit about the \nother camp's needs, everybody would get a little calmer.\n\nCiao,\nDscho\n"},{"id":"104947","messageId":"20090216135812.GA20377@coredump.intra.peff.net","threadId":"17807","inReplyTo":"loom.20090216T101457-231@post.gmane.org","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T13:58:12Z","receivedAt":"2009-02-16T13:58:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 10:17:01AM +0000, Sergio Callegari wrote:\n\n> > For people who do not follow the git list regularly, a \"HEAD contain the\n> > actual commit\" is often called \"detached\".\n> \n> Could you have that done automatically?\n> Namely rather to denying push to a branch b where HEAD->b, when you get such\n> push you detach head?\n\nSee\n\n http://article.gmane.org/gmane.comp.version-control.git/108923\n\nfor discussion.\n\n-Peff\n"},{"id":"104950","messageId":"bd6139dc0902160640n3a95223j71ae7f26bc0ff0b4@mail.gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.10.0902160731420.14911@asgard.lang.hm","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-16T14:40:11Z","receivedAt":"2009-02-16T14:40:11Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Mon, Feb 16, 2009 at 16:33, wrote:\n> if it is the correct thing to do with some workloads, it's not being\n> deprecated. if it was deprecated then it is a capability that would be\n> scheduled for complete removal, and nobody should ever use. not just the\n> case where it needs to be used carefully, and you are putting in a warning\n> about it.\n\nNitpicking much? The reasons why the warning/default-to-disallow are\nbeing put in place have been explained, what value did your message\nabove add to the discussion? From my point of view it didn't add much,\nif anything at all. It might be a good idea to end this thread here,\nas Junio requested. If you feel the undying need to continue this\ndiscussion, please do not do so in this thread.\n\nThank you.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104949","messageId":"alpine.DEB.1.10.0902160731420.14911@asgard.lang.hm","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902161121290.10279@pacific.mpi-cbg.de","subject":"Re: [RFC - draft] List of proposed future changes that are backward incompatible","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-16T15:33:28Z","receivedAt":"2009-02-16T15:33:28Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 16 Feb 2009, Johannes Schindelin wrote:\n\n> On Sun, 15 Feb 2009, david@lang.hm wrote:\n>\n>> please be careful with the term 'deprecated', just becouse you would do\n>> something a different way doesn't make it 'deprecated', that term should\n>> only be used for features that are on their way out of the product, but\n>> haven't been removed yet.\n>\n> It is not deprecated because I do not like it. Actually, I am pretty\n> indifferent about the pushing into a non-bare repository.\n>\n> It is deprecated because a lot of people active in the Git community spend\n> a real lot of time explaining to a whole bunch of new users on IRC and\n> recently even on this list why their pushing into a non-bare repository\n> does not work, and why their suggestions how to solve the issue does not\n> work either.\n\nif it is the correct thing to do with some workloads, it's not being \ndeprecated. if it was deprecated then it is a capability that would be \nscheduled for complete removal, and nobody should ever use. not just the \ncase where it needs to be used carefully, and you are putting in a warning \nabout it.\n\nDavid Lang\n"},{"id":"104978","messageId":"49999ED6.7010608@gmail.com","threadId":"17807","inReplyTo":"20090216135812.GA20377@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-02-16T17:13:58Z","receivedAt":"2009-02-16T17:13:58Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Jeff King wrote:\n> On Mon, Feb 16, 2009 at 10:17:01AM +0000, Sergio Callegari wrote:\n>\n> \n>>> For people who do not follow the git list regularly, a \"HEAD contain the\n>>> actual commit\" is often called \"detached\".\n>>> \n>> Could you have that done automatically?\n>> Namely rather to denying push to a branch b where HEAD->b, when you get such\n>> push you detach head?\n>> \n>\n> See\n>\n> http://article.gmane.org/gmane.comp.version-control.git/108923\n>\n> for discussion.\n>\n> -Peff\n> \nThanks for the pointer!\n\nHowever, wrt point 1)\n\n> If you set 'detach' option, this clueless user is not helped; he will\n> happily keep working and would make tons of commits on detached HEAD,\n> and next time he switches to another branch, will lose all of them.\n> \nI guess that git does not let you commit on a detached head without \ncrying out loud.\n\nFurthermore, one could do just a bit more than detaching, namely store \nthe fact that head got detached and the name of the branch where the \nhead was.\nWith this, when the unconscious user types git status or git commit the \nsystem could alert him that head got detached because someone updated \nthe branch behind his shoulders from remote... and then suggest the \noption to either create a new branch from the detached head (I believe \nthat this is what gets suggested anyway when one tries to commit from a \ndetached head) or to stash the current tree status, get back onto the \nformer branch and try applying the changes on the new head of the branch.\nThe flag triggering this warning at a git status or git commit command \nshould then be cleared at the first occasion when the head is changed.\n\nTo me this seems natural and helpful. Am I missing something?\n\nSergio\n"},{"id":"104990","messageId":"vpq4oyu70dn.fsf@bauges.imag.fr","threadId":"17807","inReplyTo":"49999ED6.7010608@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-02-16T17:33:08Z","receivedAt":"2009-02-16T17:33:08Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sergio Callegari writes:\n\n> I guess that git does not let you commit on a detached head without\n> crying out loud.\n\nFor some definition of \"crying out loud\" only ;-)\n\n$ git branch\n* (no branch)\n master\n$ git commit -a -m foo\n[detached HEAD b27b4e3] foo\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\n-- \nMatthieu\n"},{"id":"104982","messageId":"alpine.DEB.1.00.0902161839120.6289@intel-tinevez-2-302","threadId":"17807","inReplyTo":"49999ED6.7010608@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T17:43:25Z","receivedAt":"2009-02-16T17:43:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Feb 2009, Sergio Callegari wrote:\n\n> Jeff King wrote:\n> \n> > If you set 'detach' option, this clueless user is not helped; he will \n> > happily keep working and would make tons of commits on detached HEAD, \n> > and next time he switches to another branch, will lose all of them.\n>\n> I guess that git does not let you commit on a detached head without \n> crying out loud.\n\nWrong. It cries out loud when you detach, not when you commit to a \ndetached HEAD. For good reason: Already at the second commit it would \nstop being funny.\n\n> Furthermore, one could do just a bit more than detaching, namely store \n> the fact that head got detached and the name of the branch where the \n> head was. With this, when the unconscious user types git status or git \n> commit the system could alert him that head got detached because someone \n> updated the branch behind his shoulders from remote...\n\nAnd of course, you need a way to show the user all the updates the branch \nwent through while the HEAD was detached, so that the user has a chance of \nunderstanding what happened in the meantime.\n\nSo much additional work, just to fix up the shortcomings of the 'detach' \nparadigm? I take it as a clear mark of a not-so-elegant design.\n\nCiao,\nDscho\n"},{"id":"104992","messageId":"76718490902161048i3c19bb43h30b1cfc62dd9a61e@mail.gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902161839120.6289@intel-tinevez-2-302","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-16T18:48:08Z","receivedAt":"2009-02-16T18:48:08Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 16, 2009 at 12:43 PM, Johannes Schindelin\n wrote:\n> And of course, you need a way to show the user all the updates the branch\n> went through while the HEAD was detached, so that the user has a chance of\n> understanding what happened in the meantime.\n>\n> So much additional work, just to fix up the shortcomings of the 'detach'\n> paradigm? I take it as a clear mark of a not-so-elegant design.\n\nYou did plant a seed in my head with PUSH_HEAD though, and I'm still\nthinking about it. :-)\n\nI think the right thing is *not to detach*, but rather when pushing\ninto a non-bare repo for it to go into refs/remotes. Too bad clone\ndoesn't set it up this way by default when cloning from a non-bare\nrepo[*]. That would probably make more sense for new users.\n\n[*] Clone can't currently know it's cloning from a non-bare repo, at\nleast via git://, as I recall...\n\nj.\n"},{"id":"104995","messageId":"4999BD54.8090805@gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902161839120.6289@intel-tinevez-2-302","subject":"Re: disallowing push to currently checked-out branch","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-02-16T19:24:04Z","receivedAt":"2009-02-16T19:24:04Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Wrong. It cries out loud when you detach, not when you commit to a \n> detached HEAD. For good reason: Already at the second commit it would \n> stop being funny.\n> \nRight, I was wrong in expecting complaints. But... if it cried out at \nthe first commit, for many people there would probably not be a second. \nBtw, I am ignorant on this: is there some case where one wants and has \nreasons to commit to a detached head before making a temporary branch on it?\n> \n>> Furthermore, one could do just a bit more than detaching, namely store \n>> the fact that head got detached and the name of the branch where the \n>> head was. With this, when the unconscious user types git status or git \n>> commit the system could alert him that head got detached because someone \n>> updated the branch behind his shoulders from remote...\n>> \n>\n> And of course, you need a way to show the user all the updates the branch \n> went through while the HEAD was detached, so that the user has a chance of \n> understanding what happened in the meantime.\n> \n> So much additional work, just to fix up the shortcomings of the 'detach' \n> paradigm? I take it as a clear mark of a not-so-elegant design.\n> \nWell not that much additional work...\n\nwhen you push to the checked out branch, head gets detached and branch \nname (say /ref/heads/master) gets stored (say in .git/pre_push_branch).\nwhen you run status or commit, you realize that there is a \npre_push_branch and you give the warning, saying what the \npre_push_branch was.\nNow, since before the push you were at the tip of that branch, to know \nwhat happened it should be enough to ask the log (or the diff) from \npre_push_branch to HEAD.\nAt the first user command that moves HEAD, pre_push_branch should get \ndeleted.\nBtw, what does happen now if you delete the branch the remote worktree \nis on? Don't you get a \"dangling\" head pointing to a non-existing branch \nand the system claiming that it is at the initial commit? Maybe, this \ntoo is a bit inelegant. In the other scenario, you would get a detached \nhead and in pre_push_branch the info the name of a no more existing \nbranch (mainig clear that you were on a branch that got deleted) and \nthis info could be returned to the user.\n\nOf course, I am not claiming that forbidding pushes to branches with \nchecked out tree is bad. It is a good idea in my opinion.\nI am just suggesting that one still wanting to allow that push in spite \nof all the potential consequences (namely wanting to mess with the \nrelevant config variable), might prefer detaching head, storing the \npre_push_branch and getting some info on status and commit rather than \nmerely allowing the push.\n\nIn fact, I believe that the point is that with the current push-allowing \nbehavior, when the push happens you loose the information about the \nprecise commit against which the changes in the worktree were made. \nWhich might be a useful piece of info.\n\nCiao,\n\nSergio\n"},{"id":"105001","messageId":"alpine.DEB.1.00.0902162102180.6289@intel-tinevez-2-302","threadId":"17807","inReplyTo":"76718490902161048i3c19bb43h30b1cfc62dd9a61e@mail.gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T20:02:49Z","receivedAt":"2009-02-16T20:02:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Feb 2009, Jay Soffian wrote:\n\n> I think the right thing is *not to detach*, but rather when pushing\n> into a non-bare repo for it to go into refs/remotes.\n\nI do not think that is consistent.\n\nCiao,\nDscho\n"},{"id":"105009","messageId":"alpine.DEB.1.00.0902162103580.6289@intel-tinevez-2-302","threadId":"17807","inReplyTo":"4999BD54.8090805@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T20:09:11Z","receivedAt":"2009-02-16T20:09:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Feb 2009, Sergio Callegari wrote:\n\n> Johannes Schindelin wrote:\n> > Wrong. It cries out loud when you detach, not when you commit to a \n> > detached HEAD. For good reason: Already at the second commit it would \n> > stop being funny.\n>\n> Right, I was wrong in expecting complaints. But... if it cried out at \n> the first commit, for many people there would probably not be a second. \n\nWhat you are suggesting, though, is that the _pusher_ detaches the HEAD. \nSo the _local_ user will never know.\n\n> Btw, I am ignorant on this: is there some case where one wants and has \n> reasons to commit to a detached head before making a temporary branch on \n> it?\n\nYes. When you try fixups on a commit you just jumped to, for example. Or \nwhen bisecting.\n\nI often use the detached HEAD as kind of a stash during a bisect. I try \nto fix it there, at the bad commit, and then cherry-pick HEAD@{1} into \nthe branch after resetting the bisect.\n\n> > > Furthermore, one could do just a bit more than detaching, namely \n> > > store the fact that head got detached and the name of the branch \n> > > where the head was. With this, when the unconscious user types git \n> > > status or git commit the system could alert him that head got \n> > > detached because someone updated the branch behind his shoulders \n> > > from remote...\n> >\n> > And of course, you need a way to show the user all the updates the branch\n> > went through while the HEAD was detached, so that the user has a chance of\n> > understanding what happened in the meantime.\n> >\n> > So much additional work, just to fix up the shortcomings of the \n> > 'detach' paradigm? I take it as a clear mark of a not-so-elegant \n> > design.\n> \n> Well not that much additional work...\n> \n> when you push to the checked out branch, head gets detached and branch name\n> (say /ref/heads/master) gets stored (say in .git/pre_push_branch).\n> when you run status or commit, you realize that there is a pre_push_branch and\n> you give the warning, saying what the pre_push_branch was.\n\nOf course, you assume there that it was only one push between detaching \nthe HEAD and inspecting the mess.\n\n> Now, since before the push you were at the tip of that branch, to know \n> what happened it should be enough to ask the log (or the diff) from \n> pre_push_branch to HEAD. At the first user command that moves HEAD, \n> pre_push_branch should get deleted.\n\nAnd you call that not much work?\n\n> Btw, what does happen now if you delete the branch the remote worktree \n> is on?\n\nSee the related discussion of receive.denyDeleteCurrent.\n\nCiao,\nDscho\n"},{"id":"105006","messageId":"m363jat7fc.fsf@localhost.localdomain","threadId":"17807","inReplyTo":"7vskmff6fp.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC - draft #2] List of proposed future changes that are backward incompatible","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-16T21:10:47Z","receivedAt":"2009-02-16T21:10:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> Here is a draft of a message I am preparing to send out around 1.6.2-rc2\n> is tagged to this mailing list, and mailing list of the projects that use\n> git to track their changes, to announce possible future changes that may\n> affect the users in a backward incompatible way, and solicit comments.\n\n> - If your favourite project that uses git is not listed in:\n> \n> http://git.or.cz/gitwiki/ProjectContacts\n> \n> or it does not have \"Forwarder\" field filled in, please add the project\n> with an appropriate address for the message to be sent.\n> \n> Be careful NOT to list a mailing list address that non-subscribers\n> cannot send messages to. For such mailing lists, we need to find a\n> subscribed volunteer to forward it. If you are volunteering, great.\n\nFirst, I have send announcements about Git User's Survey 2007 and 2008\nto mailing list of various projects using git. I can find which didn't\nbounced back with 'waiting for moderation', or 'subscribe only' and\nprovide you (on private or here on git mailing list) with the list of\naddresses of mailing list which at least seem public.\n\nSecond, you can ask major git hosting sites: repo.or.cz, gitorious and\nGitHub (and perhaps also Ohloh software metric site) to announce this\ninformation about future incompatibilities somewhere public on the\nsite, or alternatively either in news section of a site, or in blog\n(or announcements section) if there is any.\n\n\nP.S. Hmmm... you can try asking on Stackoverflow how to announce and\npropagate backward incompatibile changes for packaged OSS project,\nlike git :-)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"105008","messageId":"76718490902161312j2aee999bga00d95231fa85647@mail.gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902162102180.6289@intel-tinevez-2-302","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-16T21:12:58Z","receivedAt":"2009-02-16T21:12:58Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 16, 2009 at 3:02 PM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Mon, 16 Feb 2009, Jay Soffian wrote:\n>\n>> I think the right thing is *not to detach*, but rather when pushing\n>> into a non-bare repo for it to go into refs/remotes.\n>\n> I do not think that is consistent.\n\nNot consistent with what?\n\nSo let's say I have a workstation and a laptop. The \"sane\" thing to do\nis probably something like this:\n\nworkstation$ mkdir project && cd project && git init\nworkstation$ (add, commit, ...)\nworkstation$ git clone --bare . ../project.git\nworkstation$ git remote add origin ../project.git\nlaptop$ git clone ssh://workstation/~/project.git project\n\nAnd now I have two non-bare working repos with the intermediate bare\nrepo. So at both ends I can push/pull in the way that the designers of\ngit had in mind. :-)\n\nBut I don't think this recipe is well documented for beginners. So\nthey end up w/o the intermediate bare repository, and all the ensues.\n\nIOW, I think pushing into refs/remotes makes sense in the situation\nwhere the user has two non-bare repos that they want to exchange\ncommits between.\n\nj.\n"},{"id":"105019","messageId":"alpine.DEB.1.00.0902162215200.6289@intel-tinevez-2-302","threadId":"17807","inReplyTo":"76718490902161312j2aee999bga00d95231fa85647@mail.gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-16T21:15:50Z","receivedAt":"2009-02-16T21:15:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Feb 2009, Jay Soffian wrote:\n\n> On Mon, Feb 16, 2009 at 3:02 PM, Johannes Schindelin\n> wrote:\n>\n> > On Mon, 16 Feb 2009, Jay Soffian wrote:\n> >\n> >> I think the right thing is *not to detach*, but rather when pushing \n> >> into a non-bare repo for it to go into refs/remotes.\n> >\n> > I do not think that is consistent.\n> \n> Not consistent with what?\n\nWith pushing into bare repositories. And worse, with the existing mode of \noperation.\n\nCiao,\nDscho\n"},{"id":"105012","messageId":"76718490902161342w176c2dfawb35e97fcaf934b05@mail.gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902162103580.6289@intel-tinevez-2-302","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-16T21:42:07Z","receivedAt":"2009-02-16T21:42:07Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 16, 2009 at 3:09 PM, Johannes Schindelin\n wrote:\n> What you are suggesting, though, is that the _pusher_ detaches the HEAD.\n> So the _local_ user will never know.\n\nI'm going to be presumptuous here and say that I think that you're\nthinking about this the wrong way.\n\nI would wager that when someone is pushing into a non-bare repo, it is\nvery likely that the pusher and the local user are the same person.\ni.e., there are two common combinations: 1) a shared bare repo; 2) an\nindividual (non-shared) non-bare repo.\n\nI think it is the shared non-bare repo which is rather uncommon, and\nused mostly by advanced users or for specialized situations like\npublishing web-roots.\n\nIf I'm right, then I still think that what might better sense is:\n\n\nnon-bare repo non-bare repo\n------------------- ---------------------\nrefs/heads ---push--> refs/remotes/incoming\n ^ |\n | merge\n merge |\n | v\nrefs/remotes/origin <--fetch-- refs/heads\n\n\nYes, you can set this up, but it is quite a few extra steps to do so.\nThe defaults assume there is a bare repo that you're pulling/pushing\nfrom/to, hence the confusion for new users when that's not the\nscenario they are in.\n\nBut instead of all this talk, maybe I should pony up some RFC patches. :-)\n\nj.\n"},{"id":"105014","messageId":"7vprhidpnc.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"4999BD54.8090805@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-16T21:43:03Z","receivedAt":"2009-02-16T21:43:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergio Callegari writes:\n\n> ... is there some case where one wants\n> and has reasons to commit to a detached head before making a temporary\n> branch on it?\n\nAbsolutely. I do it all the time for minor fix-ups after applying other's\npatches on a newly created topic branch.\n\nIf you want a push to the current branch of _your_ repository detach HEAD\nautomatically and record which branch it was pointing at before you\ndetached, I am reasonably sure you can do that in post-receive hook, no?\n\nI do not think it is such a bad thing to have a new value 'detach' to\nreceive.denyCurrentBranch as a possible non-default choice per-se, but the\nearlier discussion Jeff pointed out is only showing that detaching alone\nis not enough to help the user recover from the resulting state, and Dscho\ndiscussed in this thread that detaching and recording the original branch\nmay not be enough either. IOW, we do not know yet precisely what needs to\nhappen other than detaching HEAD when the configuration tells us to\n'detach' to be useful.\n\nSo how about you experiment the workflow by setting the configuration to\n'ignore', setting up a hook to detach _and do some other useful things_ as\nnecessary, and help all of us figuring out what other information is\nuseful to record when you receive such a push, and what new indications\nyou could give users to reduce the possibility of confusion? Once we know\nwhat we want to happen, we can have it as one of the canned choices and it\nwould help users.\n"},{"id":"105020","messageId":"76718490902161428k7d252a02i3e79e4f197608891@mail.gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902162215200.6289@intel-tinevez-2-302","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-16T22:28:38Z","receivedAt":"2009-02-16T22:28:38Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin\n wrote:\n>> Not consistent with what?\n>\n> With pushing into bare repositories. And worse, with the existing mode of\n> operation.\n\nI don't understand why pushing into a bare repo should have the same\nbehavior as pushing into a non-bare repo. They are different workflows\nafter-all.\n\nj.\n"},{"id":"105021","messageId":"20090216224330.GA23764@sigill.intra.peff.net","threadId":"17807","inReplyTo":"7vprhidpnc.fsf@gitster.siamese.dyndns.org","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T22:43:30Z","receivedAt":"2009-02-16T22:43:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 01:43:03PM -0800, Junio C Hamano wrote:\n\n> Sergio Callegari writes:\n> \n> > ... is there some case where one wants\n> > and has reasons to commit to a detached head before making a temporary\n> > branch on it?\n> \n> Absolutely. I do it all the time for minor fix-ups after applying other's\n> patches on a newly created topic branch.\n\nThis question got me thinking. At the time that detached HEAD was\nintroduced, I argued for a loud warning message, claiming that for most\nusers, commiting on a detached HEAD was dangerous and unintentional and\nthere _should_ be a big warning message. And like then, committing on a\ndetached HEAD is still not something I generally do.\n\nBut then I realized there is actually one time: during interactive\nrebase, which detaches HEAD during the rebase processs, and then puts\nthe final detached value back into the branch ref for you (or not, if\nyou abort).\n\nWhich made me think how such a process interacts with pushing into a\nnon-bare repo. If we are detached, the push cannot, by definition, touch\nthe ref pointed to by HEAD, since ther isn't one. But there is still\nsome sense of \"current branch\" recorded by rebase; after the rebase is\ncompleted, it attempts to put a new value in the ref.\n\nSo this is still some conflict possible even with the current safety\nvalves. Fortunately, the ref update is smart enough to realize the value\nhas changed behind our back:\n\n $ git rebase --continue\n error: Ref refs/heads/master is at 5836aa51b217a1c88f32107cbcd606bece018657 but expected d2d7bf3fcaa927ef997dbcdaf9d9a9e176d6a8d0\n fatal: Cannot lock the ref 'refs/heads/master'.\n\nBut that doesn't give any hint to the user about what happened, or how\nto fix it.\n\nSo:\n\n 1. How can we improve this situation?\n\n One option is including \"the branch we are rebasing on\" in the list\n of refs to deny. I don't like that, though, because that becomes an\n ever-growing list of places for receive-pack to look, some of which\n are not even part of core git.\n\n I think the best bet is just detecting the situation (which we\n already do) and giving a sane recipe for resolution. Probably\n something like:\n\n git branch incoming master ;# stash newly pushed changes\n git branch -f master $old_sha1 ;# restore previous state\n git rebase --continue ;# finish the rebase\n git merge incoming ;# pull in the pushed changes\n\n 2. Are there other \"we are implicitly assuming $ref won't change\n behind our backs\" long-term commands?\n\n-Peff\n"},{"id":"105023","messageId":"20090216225226.GB23764@sigill.intra.peff.net","threadId":"17807","inReplyTo":"76718490902161428k7d252a02i3e79e4f197608891@mail.gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-16T22:52:26Z","receivedAt":"2009-02-16T22:52:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 05:28:38PM -0500, Jay Soffian wrote:\n\n> On Mon, Feb 16, 2009 at 4:15 PM, Johannes Schindelin\n> wrote:\n> >> Not consistent with what?\n> >\n> > With pushing into bare repositories. And worse, with the existing mode of\n> > operation.\n> \n> I don't understand why pushing into a bare repo should have the same\n> behavior as pushing into a non-bare repo. They are different workflows\n> after-all.\n\nActually, I think it is pulling from the non-bare repo that will get\nconfusing.\n\nYou are proposing to push, when pushing into a non-bare repo, into a\npush refspec like refs/incoming/ (for example). But what is your fetch\nrefspec?\n\nIf it fetches as usual from refs/heads/, then you have an asymmetry.\nThat is, if I do \"git push\" on one client, then \"git pull\" on another\nwon't fetch the changes. I have to wait for the non-bare repo to pull\nthem into its refs/heads/ hierarchy (one by one, if there are multiple\nbranches).\n\nSo you can try putting refs/incoming into your fetch refspec if it is a\nnon-bare repo. But there are two issues there:\n\n - how do you know the remote is non-bare?\n\n - now you have to \"push\" in the non-bare upstream in order to make\n commits available. So it no longer works to do:\n\n workstation$ cd repo && hack hack hack && commit commit commit\n laptop$ git clone workstation:repo\n\n since you will silently end up with stale results.\n\n In some ways, this is nicely rigorous: non-bare repos become\n essentially \"uncontactable\" remotely, and you have a de facto bare\n repo in the form of refs/incoming sitting in between. But I'm not\n sure it matches what most users want to do, and certainly it causes\n more breakage to their workflows than receive.denyCurrentBranch.\n\n-Peff\n"},{"id":"105026","messageId":"7vhc2uezl7.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"20090216224330.GA23764@sigill.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-16T23:23:00Z","receivedAt":"2009-02-16T23:23:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> 1. How can we improve this situation?\n\nThe situation you described is all about \"don't allow a push that is NOT\nCONTROLLED BY YOU and that can interfere with what you are doing into a\nlive repository\", and you are right, we have operations that deliberately\ndetach the HEAD and expect nobody mucks with the branch.\n\nBut is this something even worth considering about in the same context as\nthe denyCurrentBranch? The same thing can happen even if you are not\ndetaching HEAD.\n\nFor example, I sometimes end up with an ugly series on a branch, whose\nendpoint is a good looking tree. And a refactoring I would want to do\nwould be too cumbersome for the interactive rebase (I could do it, but the\nmachinery does not help as much as it would for a simpler case). In such\na case, often I would just say:\n\n\t$ git branch -f goal\n $ git reset --hard master\n : repeat from here until \"diff HEAD goal\" becomes empty\n ... cherry-pick $a_commit_in_goal_branch, or\n ... edit \"show $a_commit_in_goal_branch\" output and apply, or\n ... edit the files in place.\n ... make a commit, perhaps using -c $a_commit_in_goal_branch\n\t: repeat up to here\n\nI would not push into this repository to update the branch \"goal\" while I\nam doing this, as it will obviously screw up the whole process. I think\nit is the same thing that you would not push from elsewhere to update the\nbranch you are in the middle of interactively rebasing. Mucking with the\nsame repository from two different places at the same time, when you know\nthere can be only one version of a work tree that is checked out, is\nsimply insane.\n\nIt's just a common sense thing. What denyCurrentBranch protects you from\nis a push from elsewhere *while* you are not there, and then next day,\ngetting confused by what such a push did in the receiving repository. In\nthat scenario, you are not mucking with the receiving repository from two\nplaces at the same time, but still you can get your repository into a\nconfusing state, and it is worth protecting new people from.\n\nObviously you can tell receive-pack to refuse pushing into a non-bare\nrepository, with a \"I know what I am doing\" configuration, but I think at\nthat point the whole \"you could break things this way, so let's prevent a\nnew user from making such mistake\" goes into the realm of absurdity.\n"},{"id":"105030","messageId":"4999FFCE.3060605@gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902162103580.6289@intel-tinevez-2-302","subject":"Re: disallowing push to currently checked-out branch","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-02-17T00:07:42Z","receivedAt":"2009-02-17T00:07:42Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> What you are suggesting, though, is that the _pusher_ detaches the HEAD. \n> So the _local_ user will never know.\n>\n> \nI am not sure that I get what you mean. But if I get it right, the only \nreason why the local\nuser cannot know is precisely because \"git commit\" does not complain if \nyou call it from a detached head.\nOtherwise the local user would find out that a push happened behind his \nshoulder right at the first \"status\" or \"commit\", as he was expecting to \nbe on a branch and he finds himself off it.\n>> Btw, I am ignorant on this: is there some case where one wants and has \n>> reasons to commit to a detached head before making a temporary branch on \n>> it?\n>> \n>\n> Yes. When you try fixups on a commit you just jumped to, for example. Or \n> when bisecting.\n>\n> I often use the detached HEAD as kind of a stash during a bisect. I try \n> to fix it there, at the bad commit, and then cherry-pick HEAD@{1} into \n> the branch after resetting the bisect.\n>\n> \nInteresting. But it is sort of abusing the detached head thing, isn't \nit? You use it as a temporary unnamed branch, and it becomes the tip of \na short-lived development burst... It is not anymore just a way to peek \nat some status as I remember it was initially introduced, is it?\n>>>> Furthermore, one could do just a bit more than detaching, namely \n>>>> store the fact that head got detached and the name of the branch \n>>>> where the head was. With this, when the unconscious user types git \n>>>> status or git commit the system could alert him that head got \n>>>> detached because someone updated the branch behind his shoulders \n>>>> from remote...\n>>>> \n>>> And of course, you need a way to show the user all the updates the branch\n>>> went through while the HEAD was detached, so that the user has a chance of\n>>> understanding what happened in the meantime.\n>>>\n>>> So much additional work, just to fix up the shortcomings of the \n>>> 'detach' paradigm? I take it as a clear mark of a not-so-elegant \n>>> design.\n>>> \n>> \n>> Well not that much additional work...\n>>\n>> when you push to the checked out branch, head gets detached and branch name\n>> (say /ref/heads/master) gets stored (say in .git/pre_push_branch).\n>> when you run status or commit, you realize that there is a pre_push_branch and\n>> you give the warning, saying what the pre_push_branch was.\n>> \n>\n> Of course, you assume there that it was only one push between detaching \n> the HEAD and inspecting the mess.\n> \nAfter the first push, the head is already detached, so pre_push_branch \ndoes not get touched by the second, the third, the forth push, etc...\nWhich I guess is what the local user should want. He expected to be at \nsome commit at the tip of some branch and he needs to find out what has \nhappened between that commit and the new tip of that branch. Does he \nreally need to know in how many and what precise push operations the \nbranch tip moved?\n\n>> Now, since before the push you were at the tip of that branch, to know \n>> what happened it should be enough to ask the log (or the diff) from \n>> pre_push_branch to HEAD. At the first user command that moves HEAD, \n>> pre_push_branch should get deleted.\n>> \n>\n> And you call that not much work?\n>\n> \n>> Btw, what does happen now if you delete the branch the remote worktree \n>> is on?\n>> \n>\n> \nI tried. With current git 1.6.1.3, head remains pointing at a non \nexistent branch and git status thinks that you need to do your initial \ncommit.\nWhen you commit, the deleted branch is immediately recreated from \nscratch and you loose the history that got you at that status.\n\nWhich brings me back to my former consideration.\n\nI initially thought of detaching head because it looks like a way to \nsave a bit of info that I would like to see preserved. When someone \npushes in my repo, if my current branch tip moves, at the first action \nthat I attempt on the repo I would like to see a big alert that it did \nand have an easy way to find out at what commit I was before the push \nhappened. Otherwise, I cannot really find out what the push precisely \nchanged, I cannot easily revert it if it was wrong, etc.\n\nSergio\n"},{"id":"105031","messageId":"alpine.DEB.1.00.0902170112580.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"4999FFCE.3060605@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-17T00:18:33Z","receivedAt":"2009-02-17T00:18:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Feb 2009, Sergio Callegari wrote:\n\n> Johannes Schindelin wrote:\n>\n> > What you are suggesting, though, is that the _pusher_ detaches the \n> > HEAD. So the _local_ user will never know.\n>\n> the only reason why the local user cannot know is precisely because \"git \n> commit\" does not complain if you call it from a detached head.\n\nNo, the only reason is that you sneakily detached the HEAD behind his \nback. It is not possible in physical life -- at least not without the \nowner of the head noticing -- and it should not be possible with Git, \neither.\n\nAll this \"we need more complaining\" is just a fix up for a failed design.\n\n> > > Btw, I am ignorant on this: is there some case where one wants and \n> > > has reasons to commit to a detached head before making a temporary \n> > > branch on it?\n> >\n> > Yes. When you try fixups on a commit you just jumped to, for example. \n> > Or when bisecting.\n> >\n> > I often use the detached HEAD as kind of a stash during a bisect. I \n> > try to fix it there, at the bad commit, and then cherry-pick HEAD@{1} \n> > into the branch after resetting the bisect.\n>\n> Interesting. But it is sort of abusing the detached head thing, isn't \n> it? You use it as a temporary unnamed branch,\n\nThat is exactly what a detached HEAD is.\n\n> > Of course, you assume there that it was only one push between \n> > detaching the HEAD and inspecting the mess.\n>\n> After the first push, the head is already detached, so pre_push_branch \n> does not get touched by the second, the third, the forth push, etc...\n\nOh, so the user should be really fscked for not realizing just how much \nhappened in the meantime?\n\n> > > Now, since before the push you were at the tip of that branch, to \n> > > know what happened it should be enough to ask the log (or the diff) \n> > > from pre_push_branch to HEAD. At the first user command that moves \n> > > HEAD, pre_push_branch should get deleted.\n>\n> > And you call that not much work?\n\nThat point is still valid. If you have to do too much to make your idea \nwork, if you have to bolt on this and that, it is a sure sign that the \ndesign is borked.\n\n> > > Btw, what does happen now if you delete the branch the remote \n> > > worktree is on?\n>\n> I tried. With current git 1.6.1.3, head remains pointing at a non \n> existent branch and git status thinks that you need to do your initial \n> commit. When you commit, the deleted branch is immediately recreated \n> from scratch and you loose the history that got you at that status.\n\nAs I remarked already, this is a bug that is actively being squashed.\n\nOf course, you can go on and on and on with the detached HEAD ide, but so \nfar you haven't convinced me that this is a sensible thing to do.\n\nCiao,\nDscho\n"},{"id":"105033","messageId":"20090217002352.GA23507@coredump.intra.peff.net","threadId":"17807","inReplyTo":"7vhc2uezl7.fsf@gitster.siamese.dyndns.org","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-17T00:23:52Z","receivedAt":"2009-02-17T00:23:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 03:23:00PM -0800, Junio C Hamano wrote:\n\n> > 1. How can we improve this situation?\n> \n> The situation you described is all about \"don't allow a push that is NOT\n> CONTROLLED BY YOU and that can interfere with what you are doing into a\n> live repository\", and you are right, we have operations that deliberately\n> detach the HEAD and expect nobody mucks with the branch.\n\nI don't agree that it has to be a push not controlled by you. I have\nmany times left a rebase-in-progress sitting in a repository, either\naccidentally because I meant to \"--abort\" it after a conflict but\nforgot, or because I got interrupted during an interactive edit and\nneeded to come back to it.\n\nSo the problem is simply that the repository you're pushing into is not\nin the state you think it is (either because you forgot what state you\nleft it in, didn't realize what state you left it in, or because it is\nsomebody else's repo).\n\n> But is this something even worth considering about in the same context as\n> the denyCurrentBranch? The same thing can happen even if you are not\n> detaching HEAD.\n\nI don't think it's the same, but I think it is a related problem. I\ndon't think the solutions are related, though.\n\n> For example, I sometimes end up with an ugly series on a branch, whose\n> endpoint is a good looking tree. And a refactoring I would want to do\n> would be too cumbersome for the interactive rebase (I could do it, but the\n> machinery does not help as much as it would for a simpler case). In such\n> a case, often I would just say:\n> \n> \t$ git branch -f goal\n> $ git reset --hard master\n> : repeat from here until \"diff HEAD goal\" becomes empty\n> ... cherry-pick $a_commit_in_goal_branch, or\n> ... edit \"show $a_commit_in_goal_branch\" output and apply, or\n> ... edit the files in place.\n> ... make a commit, perhaps using -c $a_commit_in_goal_branch\n> \t: repeat up to here\n> \n> I would not push into this repository to update the branch \"goal\" while I\n> am doing this, as it will obviously screw up the whole process. I think\n\nOK, that is a good example of how this is basically impossible to\nprotect from fully (and a good argument why pushing into a repo used for\nwork is probably not a good idea in general). I think the rebase example\nis a little worse because:\n\n - It's subtle. with denyCurrentBranch, we generally protect the user\n from pushing into the current branch and messing things up. But\n during a rebase we don't, and the only way the user would realize\n that is if they understand that rebasing happens on a detached HEAD.\n\n - the error message is confusing, and there is no clear way out of the\n error case. You can \"rebase --abort\" which throws away your rebase\n work _and_ the push. But what you probably want to do, I described\n earlier.\n\n> It's just a common sense thing. What denyCurrentBranch protects you from\n> is a push from elsewhere *while* you are not there, and then next day,\n> getting confused by what such a push did in the receiving repository. In\n\nSee above for why I think this can happen while you are not there. It is\nabout repo state for long-running workflows. I'm not too concerned with\nsomebody pushing in the exact half second while you are making running\n\"git commit\".\n\n> Obviously you can tell receive-pack to refuse pushing into a non-bare\n> repository, with a \"I know what I am doing\" configuration, but I think at\n> that point the whole \"you could break things this way, so let's prevent a\n> new user from making such mistake\" goes into the realm of absurdity.\n\nI think that is insane, too. This is not all that likely to happen\ncompared to the possible benefits of pushing into a non-bare repo. And\nas you say, in most cases common sense rules: don't push into something\nyou are actively working on.\n\nI am really just proposing that the \"ref was not what we expected\"\nmessage to better indicate what is going on, and how the user might get\nout of it. Do you not agree with that?\n\n-Peff\n"},{"id":"105036","messageId":"499A07C4.5000908@gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902170112580.10279@pacific.mpi-cbg.de","subject":"Re: disallowing push to currently checked-out branch","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-02-17T00:41:40Z","receivedAt":"2009-02-17T00:41:40Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Of course, you can go on and on and on with the detached HEAD ide, but so \n> far you haven't convinced me that this is a sensible thing to do.\n> \nI will not... it's time to sleep where I am! And I am just a user of git \nand you are a developer, which makes me think that you might know much \nbetter.\nBut the exchange was insightful, thanks.\n\nRather, I'll turn again the question...\n\nLet us assume that I am working on branch B and that my worktree is \nbased on commit XYZ. Let's also assume that someone pushes behind my \nshoulders and moves the tip of B (or even deletes B alltogether) either \nin one or in multiple pushes. Is there an easy way so that I can now \nfind out at what commit (XYZ) I was before the push(es)? That would \nalready make me quite satisfied, because with this I can write wrappers \nor aliases that can check the HEAD against that commit on every \nstatus/commit operation and warn the user just in case.\n\nSergio\n\n> Ciao,\n> Dscho\n>\n> \n"},{"id":"105037","messageId":"7vocx1evvs.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"20090217002352.GA23507@coredump.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-17T00:43:03Z","receivedAt":"2009-02-17T00:43:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Feb 16, 2009 at 03:23:00PM -0800, Junio C Hamano wrote:\n>\n>> > 1. How can we improve this situation?\n>> \n>> The situation you described is all about \"don't allow a push that is NOT\n>> CONTROLLED BY YOU and that can interfere with what you are doing into a\n>> live repository\", and you are right, we have operations that deliberately\n>> detach the HEAD and expect nobody mucks with the branch.\n>\n> I don't agree that it has to be a push not controlled by you. I have\n> many times left a rebase-in-progress sitting in a repository, either\n> accidentally because I meant to \"--abort\" it after a conflict but\n> forgot, or because I got interrupted during an interactive edit and\n> needed to come back to it.\n\nThat sounds similar to saying \"I left my editor open without saving my\nchanges, and accidentally opened another instance of an editor from a\ndifferent terminal and edited the same file, the result is a mess\". The\neditors protect users from such a situation by locking the file they are\nediting.\n\nPerhaps operations that detaches HEAD (rebase and perhaps sequencer) can\nall agree to use a single marker file that says \"Do not mess with these\nrefs via push or fetch\" and make receive-pack and fetch honor that? Then\nthe issue you raised in your earlier message about receive-pack having to\nknow random states random set of tools leave will be alleviated. We need\nto make sure that the marker is cleaned up correctly when the command is\ndone with the lock, of course.\n\nIf we were to go that route, I think the same receive.denyCurrentBranch\nconfiguration variable can and should be used to control this, even though\nits name originally comes from the most visible operation that can cause\nthe confusion (i.e. \"pushing into the current branch\"). It is about\nprotecting the person who is currently using the work tree, or who will\nuse the work tree next.\n\n> I am really just proposing that the \"ref was not what we expected\"\n> message to better indicate what is going on, and how the user might get\n> out of it. Do you not agree with that?\n\nThe recovery recipe you described looked good.\n"},{"id":"105041","messageId":"alpine.DEB.1.00.0902170154330.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"499A07C4.5000908@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-17T00:56:29Z","receivedAt":"2009-02-17T00:56:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Feb 2009, Sergio Callegari wrote:\n\n> Let us assume that I am working on branch B and that my worktree is based on\n> commit XYZ. Let's also assume that someone pushes behind my shoulders and\n> moves the tip of B (or even deletes B alltogether) either in one or in\n> multiple pushes. Is there an easy way so that I can now find out at what\n> commit (XYZ) I was before the push(es)?\n\nNope. There was code flying around at some stage to record in the index \nwhat commit it was based on.\n\nI forgot why it was thrown out again; you'll have to look up the \ndiscussion yourself.\n\nCiao,\nDscho\n"},{"id":"105049","messageId":"7veixxev70.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"499A07C4.5000908@gmail.com","subject":"Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-17T00:57:55Z","receivedAt":"2009-02-17T00:57:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergio Callegari writes:\n\n> Johannes Schindelin wrote:\n>> Of course, you can go on and on and on with the detached HEAD ide,\n>> but so far you haven't convinced me that this is a sensible thing to\n>> do.\n>>\n> I will not... it's time to sleep where I am! And I am just a user of\n> git and you are a developer, which makes me think that you might know\n> much better.\n> But the exchange was insightful, thanks.\n>\n> Rather, I'll turn again the question...\n>\n> Let us assume that I am working on branch B and that my worktree is\n> based on commit XYZ. Let's also assume that someone pushes behind my\n> shoulders and moves the tip of B (or even deletes B alltogether)\n> either in one or in multiple pushes. Is there an easy way so that I\n> can now find out at what commit (XYZ) I was before the push(es)?\n\nI am afraind that you are going on-and-on-and-on Dscho warned you about.\n\nWhat commit XYZ your next commit should build on is already recorded by\nHEAD (which in turn often refers to the tip of the branch you have checked\nout by pointing at it).\n\nHEAD (and the tip of the branch) is *supposed* to be updated by operations\nyou do from the work tree *alone*, not by push from sideways. Therefore\nthere is no such duplicated information kept.\n\nThe index is an obvious place to save that duplicated information if you\nreally wanted to, and you are welcome to try it again, but I have to warn\nyou that we have already tried this once and the fallout was not very\npretty.\n"},{"id":"105055","messageId":"7v7i3peu7y.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902170154330.10279@pacific.mpi-cbg.de","subject":"Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-17T01:18:57Z","receivedAt":"2009-02-17T01:18:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Nope. There was code flying around at some stage to record in the index \n> what commit it was based on.\n>\n> I forgot why it was thrown out again; you'll have to look up the \n> discussion yourself.\n\nA good starting point may be:\n\n http://article.gmane.org/gmane.comp.version-control.git/67089/\n http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508\n\nIt is frustrating that I cannot seem to find a way to tell gmane to \"jump\nto approximately this timeperiod\", but right now, the thread appears at\naround 635th page from the tip. By the time you read this message you may\nhave to flip a bit more pages, though ;-)\n"},{"id":"105056","messageId":"20090217012915.GB24822@coredump.intra.peff.net","threadId":"17807","inReplyTo":"7vocx1evvs.fsf@gitster.siamese.dyndns.org","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-17T01:29:15Z","receivedAt":"2009-02-17T01:29:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 16, 2009 at 04:43:03PM -0800, Junio C Hamano wrote:\n\n> That sounds similar to saying \"I left my editor open without saving my\n> changes, and accidentally opened another instance of an editor from a\n> different terminal and edited the same file, the result is a mess\". The\n> editors protect users from such a situation by locking the file they are\n> editing.\n\nIt is definitely similar.\n\n> Perhaps operations that detaches HEAD (rebase and perhaps sequencer) can\n> all agree to use a single marker file that says \"Do not mess with these\n> refs via push or fetch\" and make receive-pack and fetch honor that? Then\n> the issue you raised in your earlier message about receive-pack having to\n> know random states random set of tools leave will be alleviated. We need\n> to make sure that the marker is cleaned up correctly when the command is\n> done with the lock, of course.\n\nI think such a marker is a fine idea in general, because it would be\nnice to be able to say \"what is all state in the repo that I might care\nabout\" (which I think has been talked about several times). In fact, I\nhave had a similar problem _without_ pushing just by leaving and coming\nback in the middle of operations, especially failed ones (e.g., \"git\nam\", realize the patch doesn't apply, forget to --abort, then make more\ncommits, realize only when you try to \"git am\" something else, but now\naborting will intermediate work).\n\nI'm not sure that supporting it in receive-pack is necessary. The\ncurrent rebase code already detects the situation; it just doesn't\nhandle it as gracefully as it might. And it doesn't close _all_\npossibility for danger, as the example you gave previously shows; the\nuser can still be surprised by the ref changing.\n\nWhereas improving the local tool support for \"rebase --abort\" and \"am\n--abort\" to help a user recover from such a situation means that we help\nnot only the situation of somebody pushing, but also local \"I forgot\nand changed the repo\" situations.\n\n> > I am really just proposing that the \"ref was not what we expected\"\n> > message to better indicate what is going on, and how the user might get\n> > out of it. Do you not agree with that?\n> \n> The recovery recipe you described looked good.\n\nOK. I'll look at working up a patch.\n\n-Peff\n"},{"id":"105079","messageId":"76718490902162153m6a524b2dv335be66a0f0294ca@mail.gmail.com","threadId":"17807","inReplyTo":"20090216225226.GB23764@sigill.intra.peff.net","subject":"Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-17T05:53:31Z","receivedAt":"2009-02-17T05:53:31Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 16, 2009 at 5:52 PM, Jeff King wrote:\n> Actually, I think it is pulling from the non-bare repo that will get\n> confusing.\n>\n> You are proposing to push, when pushing into a non-bare repo, into a\n> push refspec like refs/incoming/ (for example). But what is your fetch\n> refspec?\n>\n> If it fetches as usual from refs/heads/, then you have an asymmetry.\n> That is, if I do \"git push\" on one client, then \"git pull\" on another\n> won't fetch the changes. I have to wait for the non-bare repo to pull\n> them into its refs/heads/ hierarchy (one by one, if there are multiple\n> branches).\n>\n> So you can try putting refs/incoming into your fetch refspec if it is a\n> non-bare repo. But there are two issues there:\n>\n> - how do you know the remote is non-bare?\n>\n> - now you have to \"push\" in the non-bare upstream in order to make\n> commits available. So it no longer works to do:\n>\n> workstation$ cd repo && hack hack hack && commit commit commit\n> laptop$ git clone workstation:repo\n>\n> since you will silently end up with stale results.\n>\n> In some ways, this is nicely rigorous: non-bare repos become\n> essentially \"uncontactable\" remotely, and you have a de facto bare\n> repo in the form of refs/incoming sitting in between. But I'm not\n> sure it matches what most users want to do, and certainly it causes\n> more breakage to their workflows than receive.denyCurrentBranch.\n\nMy head is playing around with two ideas now that Dscho has mentioned:\n\nreceive.localBranches = (refuse | allow)\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065\n\nAnd PUSH_HEAD.\n\nThe idea would be for side-pushes never to update a local branch, but\nto be recorded in PUSH_HEAD. You'd be able to rebase/merge local\nbranch on-top of changes in PUSH_HEAD. I'm trying to figure out what\ncan make sense when pulling from such a repo.\n\nj.\n"},{"id":"105095","messageId":"499A75B0.5050600@op5.se","threadId":"17807","inReplyTo":"20090216000732.GC3503@coredump.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-02-17T08:30:40Z","receivedAt":"2009-02-17T08:30:40Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Sun, Feb 15, 2009 at 03:53:50PM -0800, david@lang.hm wrote:\n> \n>>> * git-send-email won't make deep threads by default\n>>>\n>>> Many people said that by default when sending more than 2 patches the\n>>> threading git-send-email makes by default is hard to read, and they\n>>> prefer the default be one cover letter and each patch as a direct\n>>> follow-up to the cover letter.\n>>>\n>>> http://article.gmane.org/gmane.comp.version-control.git/109790\n>> I have mixed feelings about this one, if some messages get delayed in \n>> transit the deep threads still keeps them in order, while the 2-layer \n>> option doesn't.\n> \n> Is that the case? mutt at least orders by thread, but by rfc822 date\n> within a single level of thread. So as long as the date fields (set by\n> the sender) are correct, it looks right no matter what order they arrive\n> in.\n> \n> Are there common readers that thread but do not order by date?\n> \n\nThunderbird does it. I haven't found an option to sort by \"date sent\"\ninside threads, .\n\nFWIW, I like this change either way. Deep threading is nice for up to\nfive or so patches. After that it becomes messy. Shallow threading\nsimply scales much better, so it's easier to be consistent if that's\nthe default.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"105097","messageId":"499A769B.2080308@op5.se","threadId":"17807","inReplyTo":"mj+md-20090216.103512.5791.nikam@ucw.cz","subject":"Re: send-email sending shallow threads by default","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-02-17T08:34:35Z","receivedAt":"2009-02-17T08:34:35Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Martin Mares wrote:\n> Hello, world!\\n\n> \n>> Is that the case? mutt at least orders by thread, but by rfc822 date\n>> within a single level of thread. So as long as the date fields (set by\n>> the sender) are correct, it looks right no matter what order they arrive in.\n> \n> Actually, it matters, because the Date field has limited precision\n> and it frequently happens that the sender produces several mails\n> within a single second.\n> \n\nThere's no need to have the date field be set to the time the mails were\nactually sent though. AFAIR, they get the AUTHOR_DATE now, and I doubt more\nthan one commit can be authored every second.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"105106","messageId":"mj+md-20090217.090514.32275.nikam@ucw.cz","threadId":"17807","inReplyTo":"499A769B.2080308@op5.se","subject":"Re: send-email sending shallow threads by default","fromName":"Martin Mares","fromEmail":"mj@ucw.cz","sentAt":"2009-02-17T09:06:18Z","receivedAt":"2009-02-17T09:06:18Z","isPatch":false,"sender":{"key":"mj@ucw.cz","avatar":null},"body":"Hello, world!\\n\n\n> There's no need to have the date field be set to the time the mails were\n> actually sent though. AFAIR, they get the AUTHOR_DATE now, and I doubt more\n> than one commit can be authored every second.\n\nIs it really so? Last time I have used git send-email, they got the current\ndate. It was in Git 1.5.5, though, so it is possible that it has changed since\nthen.\n\n\t\t\t\tHave a nice fortnight\n-- \nMartin `MJ' Mares http://mj.ucw.cz/\nFaculty of Math and Physics, Charles University, Prague, Czech Rep., Earth\n\"All that is necessary for the triumph of evil is that good men do nothing.\" -- E. Burke\n"},{"id":"105124","messageId":"alpine.DEB.1.00.0902171200250.6185@intel-tinevez-2-302","threadId":"17807","inReplyTo":"76718490902162153m6a524b2dv335be66a0f0294ca@mail.gmail.com","subject":"PUSH_HEAD, was Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-17T11:28:46Z","receivedAt":"2009-02-17T11:28:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Feb 2009, Jay Soffian wrote:\n\n> My head is playing around with two ideas now that Dscho has mentioned:\n> \n> receive.localBranches = (refuse | allow)\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065\n\nIn the meantime, we have receive.denyCurrentBranch, which is much superior \nto the localBranches design: it tackles the _real_ issue -- the only \nreason why a current branch cannot be updated lightly is that it might \nhave a working directory which would be forced out-of-sync.\n\n> And PUSH_HEAD.\n> \n> The idea would be for side-pushes never to update a local branch, but to \n> be recorded in PUSH_HEAD. You'd be able to rebase/merge local branch \n> on-top of changes in PUSH_HEAD. I'm trying to figure out what can make \n> sense when pulling from such a repo.\n\nSorry, I should clarify what I mean by PUSH_HEAD:\n\nThe idea is to have the _same_ as FETCH_HEAD, i.e. a simple file \n(.git/FETCH_HEAD) listing all the branch tips that have been pushed, _no \nmatter_ if they were successfully stored as refs.\n\nJust do this in a repository which is lagging behind origin a little:\n\n\t$ git fetch origin\n\nand then see that a file .git/FETCH_HEAD exists. As long as you are only \ninterested in the first rev, you can even use \"FETCH_HEAD\" as a rev name:\n\n\t$ git show FETCH_HEAD\n\nThe important feature of this method is that FETCH_HEAD is not fetchable. \nNeither 'ls-remote' nor 'branch' will show it.\n\nBTW a PUSH_HEAD could also help the issue that when updating of a ref was \nrefused, all the objects will have to be transferred via the wire again \nwhen pushing somewhere else.\n\nHaving said all that, I can easily live without PUSH_HEAD.\n\nCiao,\nDscho\n"},{"id":"105183","messageId":"76718490902170929v3ed9e3c2tb2f7fb1bfc01b3ab@mail.gmail.com","threadId":"17807","inReplyTo":"alpine.DEB.1.00.0902171200250.6185@intel-tinevez-2-302","subject":"Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-17T17:29:53Z","receivedAt":"2009-02-17T17:29:53Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 17, 2009 at 6:28 AM, Johannes Schindelin\n wrote:\n>> receive.localBranches = (refuse | allow)\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78065\n>\n> In the meantime, we have receive.denyCurrentBranch, which is much superior\n> to the localBranches design: it tackles the _real_ issue -- the only\n> reason why a current branch cannot be updated lightly is that it might\n> have a working directory which would be forced out-of-sync.\n\nHmpfh.\n\nSo both you and Junio have changed your mind since that thread then.\nBecause in that thread, you propose receive.guardCurrentBranch, which\nwas quite similar to today's receive.denyCurrentBranch. Junio then\nargues that treating just the checked-out branch as special, as\nopposed to all local branches is not the right thing to do:\n\n--- snip ---\nhttp://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062\n\nStep back a bit and think _why_ you wanted to prevent current branch tip\nfrom getting updated in the first place. There are two issues:\n\n * Why is it _current_ branch, and not _these branches_, that can be\n configured by the user to be protected from a push from sideways?\n\n * Why is it undesirable for the work tree and the index to go out of sync\n with respect to the branch tip to begin with?\n\nThe latter is simpler to answer, so let's deal with it first. The reason\nwhy it is bad is because allowing a push to the current branch interferes\nwith the work actively being done in the repository, using the work tree\ncontents. There is a person, you, who is actively editing the work tree\nin order to advance the tip of the branch by making commits. If the\nbranch tip moves without your knowing, that destabilizes your working\nenvironment. Your work tree wanted to make a new commit on top of some\nknown state, but that state was moved underneath you. Not good.\n\nWhen you are using the repository for real work (i.e. advance the tips of\nits branches), you want a stable environment. You do not want its HEAD\nbobbing around outside your control, and silently detaching to cause your\nlater commits to go to unnamed branch without your knowing is just as bad\n(which you already correctly objected to).\n--- snip ---\n\nAnd you end up agreeing:\n\n--- snip ---\nhttp://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062\n\n> Now think. What if one of these operations you do in the repository to\n> advance the tip was to merge from one of _your_ local branches? Yes,\n> you end up merging something you did not expect to merge if you allowed\n> a push from sideways to affect that local branch, only because the\n> branch happened to be un-checked-out and you implemented this protection\n> to forbid only to current branch. Allowing a push from sideways to any\n> local branch destabilizes your work environment, not just the current\n> one.\n\nOkay, I am starting to see the light.\n\nHow about\n\n\treceive.localBranches = (refuse | allow)\n--- snip ---\n\nThen the thread died, with receive.localBranches going into TODO, but\nnever got an implementation. Sometime later, receive.denyCurrentBranch\ncame along, which is the original idea you proposed, Junio argued\nagainst, and then you agreed.\n\nSo, I'm not sure what happened in the intervening time between the\nreceive.localBranches proposal and the receive.denyCurrentBranch\nimplementation that suddenly what is basically guardCurrentBranch\nbecame a good idea.\n\nBut, I happen to agree with Junio's argument in gmane 77955.\n\nj.\n"},{"id":"105208","messageId":"20090217192855.GB15625@coredump.intra.peff.net","threadId":"17807","inReplyTo":"mj+md-20090217.090514.32275.nikam@ucw.cz","subject":"Re: send-email sending shallow threads by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-17T19:28:55Z","receivedAt":"2009-02-17T19:28:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 17, 2009 at 10:06:18AM +0100, Martin Mares wrote:\n\n> > There's no need to have the date field be set to the time the mails\n> > were actually sent though. AFAIR, they get the AUTHOR_DATE now, and\n> > I doubt more than one commit can be authored every second.\n> \n> Is it really so? Last time I have used git send-email, they got the\n> current date. It was in Git 1.5.5, though, so it is possible that it\n> has changed since then.\n\nsend-email does write a new date header. Which is actually desirable,\nIMHO, because otherwise rebased patches would get sent with their\noriginal date, which might very well long in the past (and not only is\nthat confusing, but it would probably trip spam filters).\n\n-Peff\n"},{"id":"105211","messageId":"20090217194827.GB16067@coredump.intra.peff.net","threadId":"17807","inReplyTo":"76718490902170929v3ed9e3c2tb2f7fb1bfc01b3ab@mail.gmail.com","subject":"Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-17T19:48:27Z","receivedAt":"2009-02-17T19:48:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 17, 2009 at 12:29:53PM -0500, Jay Soffian wrote:\n\n> So both you and Junio have changed your mind since that thread then.\n> Because in that thread, you propose receive.guardCurrentBranch, which\n> was quite similar to today's receive.denyCurrentBranch. Junio then\n> argues that treating just the checked-out branch as special, as\n> opposed to all local branches is not the right thing to do:\n\nI have to admit, I found that thread a very interesting read, because I\nsomehow missed it the first time and it seemed the opposite of what\nhappened later.\n\n> So, I'm not sure what happened in the intervening time between the\n> receive.localBranches proposal and the receive.denyCurrentBranch\n> implementation that suddenly what is basically guardCurrentBranch\n> became a good idea.\n\nI think what happened (partially) is that I never read the original,\nthen at GitTogether somebody (Sam?) was complaining about usability\nissues, so I wrote the denyCurrentBranch patch. Why and how people\nchanged their minds is a mystery to me, though.\n\n-Peff\n\nPS I seem to have an uncanny knack for writing a patch, then finding out\nthat Dscho wrote the exact same patch months or years earlier. I think\nthis is the third time it has happened.\n"},{"id":"105221","messageId":"7vy6w43duw.fsf@gitster.siamese.dyndns.org","threadId":"17807","inReplyTo":"76718490902170929v3ed9e3c2tb2f7fb1bfc01b3ab@mail.gmail.com","subject":"Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-17T22:20:07Z","receivedAt":"2009-02-17T22:20:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> So both you and Junio have changed your mind since that thread then.\n\nAt least I didn't.\n\nI personally was not too worried about protecting either local branches\nnor the current branch (and I do not lose sleep over them now either).\nEither is about forbidding an end user who knows from doing an operation\nwe have allowed so far, only because an abuse of the feature by other end\nusers who either don't know what they are doing or are careless can result\nin confusing the latter. I do not particularly like that kind of safety\nvalve.\n\nThe current round of protecting only local branches is there because it is\nof much lessor impact, with simpler code (and easier revertibility if\nneeded), than the full blown \"protect these branches\" one in which issues\nin its design still has to be ironed out if we go that route (see my other\nmessage from yesterday to Jeff --- we discuss exactly that in the context\nof detached HEAD and other operations). The need for \"current branch\nprotection\" this round implements also comes from an observed confusions\nin real world users Dscho and others saw on #git and other places. The\nmore general \"protect these branches\" is conceptually nicer but the need\nfor such safeguard is still under discussion as far as I understood what\nwas said in the recent discussions.\n"},{"id":"105224","messageId":"76718490902171442q38dd8977ob5754fc071812f98@mail.gmail.com","threadId":"17807","inReplyTo":"7vy6w43duw.fsf@gitster.siamese.dyndns.org","subject":"Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-17T22:42:35Z","receivedAt":"2009-02-17T22:42:35Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 17, 2009 at 5:20 PM, Junio C Hamano wrote:\n> Jay Soffian writes:\n>\n>> So both you and Junio have changed your mind since that thread then.\n>\n> At least I didn't.\n\nAh, I didn't mean to mischaracterize your intent from that thread then.\n\n> I personally was not too worried about protecting either local branches\n> nor the current branch (and I do not lose sleep over them now either).\n> Either is about forbidding an end user who knows from doing an operation\n> we have allowed so far, only because an abuse of the feature by other end\n> users who either don't know what they are doing or are careless can result\n> in confusing the latter. I do not particularly like that kind of safety\n> valve.\n>\n> The current round of protecting only local branches is there because it is\n> of much lessor impact, with simpler code (and easier revertibility if\n> needed), than the full blown \"protect these branches\" one in which issues\n> in its design still has to be ironed out if we go that route (see my other\n> message from yesterday to Jeff --- we discuss exactly that in the context\n> of detached HEAD and other operations). The need for \"current branch\n> protection\" this round implements also comes from an observed confusions\n> in real world users Dscho and others saw on #git and other places. The\n> more general \"protect these branches\" is conceptually nicer but the need\n> for such safeguard is still under discussion as far as I understood what\n> was said in the recent discussions.\n\nOkay, that makes sense.\n\nj.\n"},{"id":"105226","messageId":"alpine.DEB.1.00.0902172352090.10279@pacific.mpi-cbg.de","threadId":"17807","inReplyTo":"76718490902170929v3ed9e3c2tb2f7fb1bfc01b3ab@mail.gmail.com","subject":"Re: PUSH_HEAD, was Re: disallowing push to currently checked-out branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-17T22:54:12Z","receivedAt":"2009-02-17T22:54:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Feb 2009, Jay Soffian wrote:\n\n> So both you and Junio have changed your mind since that thread then.\n\nI never claimed to be unable to learn.\n\nCiao,\nDscho\n"},{"id":"105548","messageId":"m1bpsxq074.fsf@fess.ebiederm.org","threadId":"17807","inReplyTo":"20090217192855.GB15625@coredump.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2009-02-20T03:03:27Z","receivedAt":"2009-02-20T03:03:27Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Jeff King writes:\n\n> On Tue, Feb 17, 2009 at 10:06:18AM +0100, Martin Mares wrote:\n>\n>> > There's no need to have the date field be set to the time the mails\n>> > were actually sent though. AFAIR, they get the AUTHOR_DATE now, and\n>> > I doubt more than one commit can be authored every second.\n>> \n>> Is it really so? Last time I have used git send-email, they got the\n>> current date. It was in Git 1.5.5, though, so it is possible that it\n>> has changed since then.\n>\n> send-email does write a new date header. Which is actually desirable,\n> IMHO, because otherwise rebased patches would get sent with their\n> original date, which might very well long in the past (and not only is\n> that confusing, but it would probably trip spam filters).\n\nCan we ensure that all of the messages sent differ in date by 1 second?\nKeeping them in order for anyone who looks at the transmit date.\n\nI know at one point I started using --change-reply-to because of the problem\nof threads showing up in the wrong order, and making it hard to read.\n\nEric\n"},{"id":"105551","messageId":"20090220032607.GE22419@coredump.intra.peff.net","threadId":"17807","inReplyTo":"m1bpsxq074.fsf@fess.ebiederm.org","subject":"Re: send-email sending shallow threads by default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-20T03:26:07Z","receivedAt":"2009-02-20T03:26:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 19, 2009 at 07:03:27PM -0800, Eric W. Biederman wrote:\n\n> > send-email does write a new date header. Which is actually desirable,\n> > IMHO, because otherwise rebased patches would get sent with their\n> > original date, which might very well long in the past (and not only is\n> > that confusing, but it would probably trip spam filters).\n> \n> Can we ensure that all of the messages sent differ in date by 1 second?\n> Keeping them in order for anyone who looks at the transmit date.\n\nI think it already does:\n\n $ git show a5370b16\n commit a5370b16c34993c1d0f65171d5704244901e005b\n Author: Eric Wong \n Date: Sat Mar 25 03:01:01 2006 -0800\n\n send-email: try to order messages in email clients more correctly\n\n If --no-chain-reply-to is set, patches may not always be ordered\n correctly in email clients. This patch makes sure each email\n sent from a different second.\n\n-Peff\n"},{"id":"105552","messageId":"m1bpsxlp8s.fsf@fess.ebiederm.org","threadId":"17807","inReplyTo":"20090220032607.GE22419@coredump.intra.peff.net","subject":"Re: send-email sending shallow threads by default","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2009-02-20T04:13:39Z","receivedAt":"2009-02-20T04:13:39Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Jeff King writes:\n\n> On Thu, Feb 19, 2009 at 07:03:27PM -0800, Eric W. Biederman wrote:\n>\n>> > send-email does write a new date header. Which is actually desirable,\n>> > IMHO, because otherwise rebased patches would get sent with their\n>> > original date, which might very well long in the past (and not only is\n>> > that confusing, but it would probably trip spam filters).\n>> \n>> Can we ensure that all of the messages sent differ in date by 1 second?\n>> Keeping them in order for anyone who looks at the transmit date.\n>\n> I think it already does:\n>\n> $ git show a5370b16\n> commit a5370b16c34993c1d0f65171d5704244901e005b\n> Author: Eric Wong \n> Date: Sat Mar 25 03:01:01 2006 -0800\n>\n> send-email: try to order messages in email clients more correctly\n>\n> If --no-chain-reply-to is set, patches may not always be ordered\n> correctly in email clients. This patch makes sure each email\n> sent from a different second.\n\nWell that date's my experiments with git-send-email. And yes looking at the\ncode the transmit date still appears to be computed that way.\n\n$time = time - scalar $#files;\nmy $date = format_2822_time($time++);\n\nSo it appears that problem has been solved if a person simply sorts by\ntransmit date.\n\nSo it sounds like a good change in defaults to me.\n\nEric\n"}]}