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
What's cooking in git.git (Feb 2014, #04; Wed, 12)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
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.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* al/docs (2014-02-11) 4 commits
- docs/git-blame: explain more clearly the example pickaxe use
- docs/git-clone: clarify use of --no-hardlinks option
- docs/git-remote: capitalize first word of initial blurb
- docs/merge-strategies: remove hyphen from mis-merges
A handful of documentation updates, all trivially harmless.
Will merge to 'next'.
* jk/test-ports (2014-02-10) 2 commits
- tests: auto-set git-daemon port
- tests: auto-set LIB_HTTPD_PORT from test name
(this branch is tangled with nd/http-fetch-shallow-fix.)
Avoid having to assign port number to be used in tests manually.
Will merge to 'next'.
* nd/daemonize-gc (2014-02-10) 2 commits
- gc: config option for running --auto in background
- daemon: move daemonize() to libgit.a
Allow running gc --auto in the background.
Will merge to 'next'.
* nd/gitignore-trailing-whitespace (2014-02-10) 2 commits
- dir: ignore trailing spaces in exclude patterns
- dir: warn about trailing spaces in exclude patterns
Warn and then ignore trailing whitespaces in .gitignore files,
unless they are quoted for fnmatch(3), e.g. path\ .
* nd/log-show-linear-break (2014-02-10) 1 commit
- log: add --show-linear-break to help see non-linear history
* ss/completion-rec-sub-fetch-push (2014-02-11) 1 commit
- completion: teach --recurse-submodules to fetch, pull and push
* ks/tree-diff-more (2014-02-12) 16 commits
- tree-diff: reuse base str(buf) memory on sub-tree recursion
- tree-diff: no need to call full diff_tree_sha1 from show_path()
- tree-diff: rework diff_tree interface to be sha1 based
- tree-diff: remove special-case diff-emitting code for empty-tree cases
- tree-diff: simplify tree_entry_pathcmp
- tree-diff: show_path prototype is not needed anymore
- tree-diff: rename compare_tree_entry - tree_entry_pathcmp
- tree-diff: move all action-taking code out of compare_tree_entry()
- tree-diff: don't assume compare_tree_entry() returns -1,0,1
- FIXUP!
- tree-diff: consolidate code for emitting diffs and recursion in one place
- tree-diff: show_tree() is not needed
- tree-diff: no need to pass match to skip_uninteresting()
- tree-diff: no need to manually verify that there is no mode change for a path
- combine-diff: move changed-paths scanning logic into its own function
- combine-diff: move show_log_first logic/action out of paths scanning
(this branch uses ks/combine-diff and ks/tree-diff-walk.)
* jh/note-trees-record-blobs (2014-02-12) 1 commit
- notes: Disallow reusing non-blob as a note object
* jk/run-network-tests-by-default (2014-02-12) 1 commit
- tests: turn on network daemon tests by default
Teach make test to run networking tests when possible by default.
Needs a bit more work.
e.g. $gmane/242013
--
[Stalled]
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
also its contents are a bit stale. It may be a good first step in
the right direction, but needs more work to at least get the
mark-up right before public consumption.
Will hold.
* jk/branch-at-publish-rebased (2014-01-17) 5 commits
- t1507 (rev-parse-upstream): fix typo in test title
- implement @{publish} shorthand
- branch_get: provide per-branch pushremote pointers
- branch_get: return early on error
- sha1_name: refactor upstream_mark
Give an easier access to the tracking branches from other side in
a triangular workflow by introducing B@{publish} that works in a
similar way to how B@{upstream} does.
Meant to be used as a basis for whatever Ram wants to build on.
Will hold.
* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits
- merge: drop unused arg from abort_commit method signature
- merge: make prepare_to_commit responsible for write_merge_state
- t7505: ensure cleanup after hook blocks merge
- t7505: add missing
Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
run during git merge. The log message stresses too much on one
hook, prepare-commit-msg, but it would equally apply to other hooks
like post-merge, I think.
Waiting for a reroll.
* jl/submodule-recursive-checkout (2013-12-26) 5 commits
- Teach checkout to recursively checkout
