Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote: * bc/gpg-sign-everywhere (2014-02-11) 9 commits - pull: add the --gpg-sign option. - rebase: add the --gpg-sign option - rebase: parse options in stuck-long mode - rebase: don't try to match -M option - rebase: remove useless arguments check - am: add the --gpg-sign option - am: parse options in stuck-long mode - git-sh-setup.sh: add variable to use the stuck-long mode - cherry-pick, revert: add the --gpg-sign option Teach --gpg-sign option to many commands that create commits. Changes to some scripted Porcelains use unsafe variable substitutions and still need to be tightened. Will merge to 'next'. Junio, did you want a reroll with that fixed commit message, or will you fix it up yourself? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
brian m. carlson sand...@crustytoothpaste.net writes: Changes to some scripted Porcelains use unsafe variable substitutions and still need to be tightened. Will merge to 'next'. Junio, did you want a reroll with that fixed commit message, or will you fix it up yourself? I haven't merged them yet---if there are need to update any one of them, please reroll a replacement set. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote: As a workaround to make life easier for third-party tools, the upcoming major release will be called Git 1.9.0 (not Git 1.9). The first maintenance release for it will be Git 1.9.1, and the major release after Git 1.9.0 will either be Git 2.0.0 or Git 1.10.0. Apologies if this ground has been tread before, but has there been a version numbering discussion? A quick google didn't seem to turn anything up. This seems to be an opportune time to drop the useless first digit. Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0, 3.0, 4.0, etc, with the 2nd digit would take the meaning of the current 3rd digit and so on. Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
Andrew Eikum aei...@codeweavers.com writes: On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote: As a workaround to make life easier for third-party tools, the upcoming major release will be called Git 1.9.0 (not Git 1.9). The first maintenance release for it will be Git 1.9.1, and the major release after Git 1.9.0 will either be Git 2.0.0 or Git 1.10.0. Apologies if this ground has been tread before, but has there been a version numbering discussion? A quick google didn't seem to turn anything up. This seems to be an opportune time to drop the useless first digit. Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0, 3.0, 4.0, etc, with the 2nd digit would take the meaning of the current 3rd digit and so on. Considered, and discarded. cf. http://article.gmane.org/gmane.comp.version-control.git/241498 When you see a version number vX.Y.0 next time, think of it as just play vX.Y without the third digit, and you will be fine. People's script cannot learn the think of it as ... part overnight, and that is why we have the .0 there. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Fri, Feb 14, 2014 at 12:10:05PM -0800, Junio C Hamano wrote: Andrew Eikum aei...@codeweavers.com writes: On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote: As a workaround to make life easier for third-party tools, the upcoming major release will be called Git 1.9.0 (not Git 1.9). The first maintenance release for it will be Git 1.9.1, and the major release after Git 1.9.0 will either be Git 2.0.0 or Git 1.10.0. Apologies if this ground has been tread before, but has there been a version numbering discussion? A quick google didn't seem to turn anything up. This seems to be an opportune time to drop the useless first digit. Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0, 3.0, 4.0, etc, with the 2nd digit would take the meaning of the current 3rd digit and so on. Considered, and discarded. cf. http://article.gmane.org/gmane.comp.version-control.git/241498 Thank you for the link, it hadn't turned up in my searching. When you see a version number vX.Y.0 next time, think of it as just play vX.Y without the third digit, and you will be fine. People's script cannot learn the think of it as ... part overnight, and that is why we have the .0 there. Sorry if I wasn't clear, I meant the useless digit is the first one, which is currently 1. and has been hanging around for a bit over eight years. My worry is having 2. hang around for another decade or longer. I'd rather see X.0.0 denote a major feature release (currently represented as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. So the major release version sequence would become 1.8.0, 1.9.0, 2.0.0, 3.0.0, with minor releases like 2.1.0, and bugfix releases like 2.1.1. It seems reasonable to expect fewer backwards incompatible changes in the future as Git has become more mature. This reduces the utility of reserving X.0.0 for major backwards incompatible changes, especially considering it's already been eight years for the first increment. Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
Andrew Eikum aei...@codeweavers.com writes: My worry is having 2. hang around for another decade or longer. I'd rather see X.0.0 denote a major feature release (currently represented as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. We need three categories: (1) potentially incompatible, (2) feature, (3) fixes-only. We have been doing two levels of features by having both second and third numbers and we are flattening by removing the second one. It seems reasonable to expect fewer backwards incompatible changes in the future as Git has become more mature. This reduces the utility of reserving X.0.0 for major backwards incompatible changes, especially considering it's already been eight years for the first increment. We are not done yet, far from it. If we can stay at 2.X longer, that is a very good thing. If we followed your numbering scheme, you rob from the users a way to learn about a rare event, a potentially backward-incompatible change. How would you tell your users when the version gap really matters? After hearing You need to plan carefully when you update to version 47 and then updating to version 47 (or the user may skip that version), the user will learn about a new version 48 and does not hear such a you need to be careful. What should he think? No news is a good news? He should refrain from updating because the last one was a big one? What if the last time he updated was to version 43, stayed at that version for a long time without paying much attention (as Git grows more and more mature), and now we have version 50 after having a large compatibility gap at version 47 he did not pay much attention because he was skipping? The rarer the important event is, the more necessary that the importance is communicated clearly. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Fri, Feb 14, 2014 at 01:08:32PM -0800, Junio C Hamano wrote: Andrew Eikum aei...@codeweavers.com writes: My worry is having 2. hang around for another decade or longer. I'd rather see X.0.0 denote a major feature release (currently represented as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. We need three categories: (1) potentially incompatible, (2) feature, (3) fixes-only. We have been doing two levels of features by having both second and third numbers and we are flattening by removing the second one. It seems reasonable to expect fewer backwards incompatible changes in the future as Git has become more mature. This reduces the utility of reserving X.0.0 for major backwards incompatible changes, especially considering it's already been eight years for the first increment. We are not done yet, far from it. If we can stay at 2.X longer, that is a very good thing. Okay, fair enough. Thanks for explaining :) Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
