Re: What's cooking in git.git (Jul 2013, #02; Fri, 5)
Hi, Junio C Hamano wrote: We are in the middle of 5th week now in the 11-week releace cycle for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have graduated to 'master'. I'd expect the rest of the week to be slow. I'd like this or the next release to be 2.0, so the common user trouble with git push pushing more branches than they intended can be over. Am I crazy? If not, what can I do to help make it happen? Thanks, Jonathan -- 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 (Jul 2013, #02; Fri, 5)
Jonathan Nieder jrnie...@gmail.com writes: We are in the middle of 5th week now in the 11-week releace cycle for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have graduated to 'master'. I'd expect the rest of the week to be slow. I'd like this or the next release to be 2.0, so the common user trouble with git push pushing more branches than they intended can be over. Am I crazy? If not, what can I do to help make it happen? There are currently three topics slated for 2.0 that changes the default behaviours in a big way. The default of the push behaviour switching from matching to simple is one of them, and it has been advertised with advice messages since 1.8.0 (Oct 2012). The other two, git add -u/-A without pathspec to operate on the entire tree, and git add with pathspec acting as if it were given -A option to also record removals to the index, haven't had enough time to be imprinted in users' minds. The former was only mentioned in the release notes of 1.8.2 (Mar 2013), and the advertisement for the latter change appeared first in 1.8.3 (May 2013). I'd prefer to see users have enough time to adjust to these big changes, at least 6 months (but preferrably 9 months). I would say that the change to the default git push behaviour may have had enough preparation period, but the other two that are scheduled for 2.0 is way too young. With recent triangular addition by Ram, the simple mode, the future behaviour of git push, was again changed, and has not have enough time to mature (isn't it still in 'next'?). Regarding that simple thing, I am not sure if the if you are pushing to a remote that is different from where you fetch from, we do exactly the same as 'current', which is what we tentatively agreed to implement, is safe enough for new people. I suspect we may want to tighten it a bit more (it would update the branch with the same name as your current local branch, but never try to create such a branch at the remote, for example). So in that sense, even the change to git push default may not be old enough for the upcoming release or the next one. -- 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 (Jul 2013, #02; Fri, 5)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We are in the middle of 5th week now in the 11-week releace cycle for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have graduated to 'master'. I'd expect the rest of the week to be slow. Please help ensure the quality of the upcoming release by testing the tip of 'master' (and if you are so inclined, 'next') early. 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 -- [Graduated to master] * tr/test-v-and-v-subtest-only (2013-06-29) 9 commits (merged to 'next' on 2013-06-30 at 1c5fac1) + perf-lib: fix start/stop of perf tests (merged to 'next' on 2013-06-26 at 8ff4d84) + test-lib: support running tests under valgrind in parallel + test-lib: allow prefixing a custom string before ok N etc. + test-lib: valgrind for only tests matching a pattern + test-lib: verbose mode for only tests matching a pattern + test-lib: self-test that --verbose works + test-lib: rearrange start/end of test_expect_* and test_skip + test-lib: refactor $GIT_SKIP_TESTS matching + test-lib: enable MALLOC_* for the actual tests Allows N instances of tests run in parallel, each running 1/N parts of the test suite under Valgrind, to speed things up. -- [New Topics] * jc/t1512-fix (2013-07-01) 2 commits - get_short_sha1(): correctly disambiguate type-limited abbreviation - t1512: correct leftover constants from earlier edition A test that should have failed but didn't revealed a bug that needs to be corrected. Will merge to 'next'. * jk/fetch-pack-many-refs (2013-07-02) 3 commits - fetch-pack: avoid quadratic behavior in rev_list_push - commit.c: make compare_commits_by_commit_date global - fetch-pack: avoid quadratic list insertion in mark_complete Fetching between repositories with many refs employed O(n^2) algorithm to match up the common objects, which has been corrected. Will merge to 'next'. * jk/format-patch-from (2013-07-03) 2 commits - teach format-patch to place other authors into in-body From - pretty.c: drop const-ness from pretty_print_context git format-patch learned --from[=whom] option, which sets the From: header to the specified person (or the person who runs the command, if =whom part is missing) and move the original author information to an in-body From: header as necessary. Will merge to 'next'. * ms/remote-tracking-branches-in-doc (2013-07-03) 1 commit - Change remote tracking to remote-tracking Will merge to 'next'. * tf/gitweb-extra-breadcrumbs (2013-07-04) 1 commit - gitweb: allow extra breadcrumbs to prefix the trail An Gitweb installation that is a part of larger site can optionally show extra links that point at the levels higher than the Gitweb pages itself in the link hierarchy of pages. Will merge to 'next'. * bc/commit-invalid-utf8 (2013-07-04) 2 commits - commit: reject overlong UTF-8 sequences - commit: reject invalid UTF-8 codepoints Will merge to 'next'. * bc/send-email-use-port-as-separate-param (2013-07-04) 1 commit - send-email: provide port separately from hostname Will merge to 'next'. * ml/cygwin-does-not-have-fifo (2013-07-05) 1 commit - test-lib.sh - cygwin does not have usable FIFOs Will merge to 'next'. -- [Stalled] * rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits - ### DONTMERGE: needs better explanation on what config they need - pack-refs.c: Add missing call to git_config() - show-ref.c: Add missing call to git_config() The changes themselves are probably good, but it is unclear what basic setting needs to be read for which exact operation. Waiting for clarification. $gmane/228294 * hv/config-from-blob (2013-05-12) 5 commits - do not die when error in config parsing of buf occurs - teach config --blob option to parse config from database - config: make parsing stack struct independent from actual data source - config: drop cf validity check in get_next_char() - config: factor out config file stack management Waiting for a reroll. $gmane/223964 * jh/shorten-refname (2013-05-07) 4 commits - t1514: refname shortening is done after dereferencing symbolic refs - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin - t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD - t1514: Add tests of shortening refnames in strict/loose mode When remotes/origin/HEAD is not a symbolic ref, rev-parse --abbrev-ref remotes/origin/HEAD ought to show origin, not origin/HEAD, which is fixed with this series (if it is a symbolic ref that points at remotes/origin/something, then it should show origin/something and it
