Here are the list of topics that are in the "private edition" I use
for every day work, grouped by where they sit in the the near-term
plan of merging them up to 'next' and then to 'master'.
These will be merged to 'master' soonish.
ew/fast-import-unpack-limit
ah/no-verify-signature-with-pull-rebase
ew/daemon-socket-keepalive
sb/submodule-misc-cleanups
sb/submodule-recommend-shallowness
et/pretty-format-c-auto
jg/dash-is-last-branch-in-worktree-add
aq/upload-pack-use-parse-options
jc/clear-pathspec
wd/userdiff-css
jk/rev-list-count-with-bitmap
rs/xdiff-hunk-with-func-line
These will be in 'next' immediately after the above gets merged to
'master'.
cc/apply-introduce-state
These have been in 'next', but will be kicked back to give them
chance to clean up when 'next' is rewound.
mh/split-under-lock
mh/ref-iterators
jc/attr
sb/pathspec-label
These are expected to be merged to 'next' in the first batch after
'next' gets rewound.
pc/occurred
tr/doc-tt
ap/git-svn-propset-doc
jk/fetch-prune-doc
dn/gpg-doc
pb/strbuf-read-file-doc
lf/receive-pack-auto-gc-to-client
mg/cherry-pick-multi-on-unborn
sg/reflog-past-root
vs/prompt-avoid-unset-variable
rj/compat-regex-size-max-fix
jk/avoid-unbounded-alloca
et/add-chmod-x
jc/deref-tag
nb/gnome-keyring-build
lv/status-say-working-tree-not-directory
tb/complete-status
em/newer-freebsd-shells-are-fine-with-returns
These are the second batch for 'next'.
km/fetch-do-not-free-remote-name
jk/parseopt-string-list
jk/string-list-static-init
lf/sideband-returns-void
jk/bisect-show-tree
jk/add-i-diff-compact-heuristics
jk/big-and-future-archive-tar
jk/send-pack-stdio
lf/recv-sideband-cleanup
pb/commit-editmsg-path
nd/test-lib-httpd-show-error-log-in-verbose
ep/http-curl-trace
These are the third batch.
mh/connect
ew/mboxrd-format-am
jk/repack-keep-unreachable
jk/gpg-interface-cleanup
sb/submodule-clone-retry
mg/signature-doc
These are the fourth.
nd/worktree-cleanup-post-head-protection
jk/upload-pack-hook
nd/graph-width-padded
nd/shallow-deepen
sb/submodule-default-paths
nd/worktree-lock
These are the remainder.
jc/blame-reverse
jc/send-email-skip-backup
va/i18n-even-more
dt/index-helper
dk/blame-move-no-reason-for-1-line-context
sb/clone-shallow-passthru
Some of them that are regression fixes may need to jump the queue
and land on 'master' earlier than others.
On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano [off-list ref] wrote:
Here are the list of topics that are in the "private edition" I use
for every day work, grouped by where they sit in the the near-term
plan of merging them up to 'next' and then to 'master'.
These will be merged to 'master' soonish.
Thanks for such an overview!
On Mon, Jun 20, 2016 at 9:46 AM, Stefan Beller [off-list ref] wrote:
On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano [off-list ref] wrote:
quoted
Here are the list of topics that are in the "private edition" I use
for every day work, grouped by where they sit in the the near-term
plan of merging them up to 'next' and then to 'master'.
These will be merged to 'master' soonish.
Thanks for such an overview!
FYI, this can be obtained by running "git log --oneline --first-parent
master..pu".
The point where "Merge ... into jch" ends is what I usually use myself
(IOW, I do
attempt to build and test 'pu', but I do not run it regularly).
On Sun, Jun 19, 2016 at 03:52:04PM -0700, Junio C Hamano wrote:
Here are the list of topics that are in the "private edition" I use
for every day work, grouped by where they sit in the the near-term
plan of merging them up to 'next' and then to 'master'.
By the way, I wondered if you had thoughts on the number of the upcoming
version. We are looking at v2.10 in the current scheme. It was at the
v1.9/v1.10 boundary that we jumped to v2.0 last time.
Certainly it is nice to avoid bumping into double digits (if only to
prevent bugs created by lexical sorting). But it feels rather quick to
be jumping to v3.0. And indeed it is much quicker, as the v1.x series
had an extra level of versioning which meant that the second-biggest
number advanced ten times more slowly.
I know some people's opinion is that versions do not matter, are just
numbers, etc, but I am not sure I agree. If you have dots in your
version number, then bumping the one before the first dot seems like a
bigger change than usual, and I think we should reserve it for a moment
where we have bigger changes in the code.
And I am not at all sure that we have given much thought to what such
changes would be, or that such things would be ready in this cycle. Off
the top of my head, the repository-format bump for pluggable ref
backends, and protocol v2 support seem like possible candidates. It's
not a flag day for either, of course; we'll build in all of the usual
backwards-compatibility flags. But it's convenient for users to remember
that "3.0" is the minimum to support a new slate of
backwards-incompatible features.
So my inclination is that the next version is simply v2.10. And maybe
you thought of all of this already, and that's why you didn't even
bother mentioning it. :) I'm just curious to hear any thoughts on the
matter.
-Peff