What's cooking in git.git (Jul 2015, #07; Mon, 27)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Git 2.5 final was tagged and tarballs were pushed out. Accumulated
fixes also went to a new maintenance release 2.4.7. Let's wait and
see for a few days for any regressions before opening the 'master'
branch for topics that have been waiting in 'next', as usual.
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]
* da/subtree-date-confusion (2015-07-23) 1 commit
- contrib/subtree: ignore log.date configuration
"git subtree" (in contrib/) depended on "git log" output to be
stable, which was a no-no. Apply a workaround to force a
particular date format.
Will merge to 'next'.
* db/send-pack-user-signingkey (2015-07-21) 1 commit
- builtin/send-pack.c: respect user.signingkey
The low-level "git send-pack" did not honor 'user.signingkey'
configuration variable when sending a signed-push.
Will merge to 'next'.
* jk/refspec-parse-wildcard (2015-07-27) 2 commits
- refs: loosen restriction on wildcard "*" refspecs
- refs: cleanup comments regarding check_refname_component()
Allow an asterisk as a substring (as opposed to the entirety) of
a path component for both side of a refspec, e.g.
"refs/heads/o*:refs/remotes/heads/i*".
Will merge to 'next'.
* jx/do-not-crash-receive-pack-wo-head (2015-07-22) 1 commit
- receive-pack: crash when checking with non-exist HEAD
Will merge to 'next'.
* kd/pull-rebase-autostash (2015-07-22) 1 commit
- pull: allow dirty tree when rebase.autostash enabled
(this branch uses pt/pull-builtin; is tangled with pt/am-builtin.)
Teach "git pull --rebase" to pay attention to rebase.autostash
configuration.
* es/doc-clean-outdated-tools (2015-07-25) 5 commits
- Documentation/git-tools: drop references to defunct tools
- Documentation/git-tools: drop references to defunct tools
- Documentation/git-tools: fix item text formatting
- Documentation/git-tools: improve discoverability of Git wiki
- Documentation/git: drop outdated Cogito reference
Will merge to 'next'.
--
[Stalled]
* jc/clone-bundle (2015-04-30) 1 commit
- repack: optionally create a clone.bundle
Waiting for further work.
Still an early WIP.
* jh/strbuf-read-use-read-in-full (2015-06-01) 1 commit
- strbuf_read(): skip unnecessary strbuf_grow() at eof
Avoid one extra iteration and strbuf_grow() of 8kB in
strbuf_read().
Looked reasonable; perhaps a log message clarification is needed.
Expecting a reroll.
* mg/index-read-error-messages (2015-06-01) 2 commits
- messages: uniform error messages for index write
- show-index: uniform error messages for index read
The tip was RFC.
Expecting a reroll.
* hv/submodule-config (2015-06-15) 4 commits
- do not die on error of parsing fetchrecursesubmodules option
- use new config API for worktree configurations of submodules
- extract functions for submodule config set and lookup
- implement submodule config API for lookup of .gitmodules values
The gitmodules API accessed from the C code learned to cache stuff
lazily.
Needs another reroll? ($gmane/273743).
* jk/log-missing-default-HEAD (2015-06-03) 1 commit
- log: diagnose empty HEAD more clearly
"git init empty && git -C empty log" said "bad default revision 'HEAD'",
which was found to be a bit confusing to new users.
What's the status of this one?
* bc/object-id (2015-06-17) 10 commits
. remote.c: use struct object_id in many functions
. object-id: use struct object_id in struct object
. remote.c: use struct object_id in ref_newer()
. transport-helper.c: use struct object_id in push_refs_with_export()
. connect.c: use struct object_id in get_remote_heads()
. remote-curl: use struct object_id in parse_fetch()
. fetch-pack: use struct object_id in add_sought_entry_mem()
. object_id: convert struct ref to use object_id.
. sha1_file: introduce has_object_file() helper
. refs: convert some internal functions to use object_id
More transition from "unsigned char[40]" to "struct object_id".
While GSoC and other topics are actively moving existing code
around, this cannot go in; ejected from 'pu'.
* wp/sha1-name-negative-match (2015-06-08) 2 commits
- sha1_name.c: introduce '^{/!-}' notation
- test for '!' handling in rev-parse's named commits
Introduce "branch^{/!-}" notation to name a commit
reachable from branch that does not match the given pattern.
Expecting a reroll.
* mk/utf8-no-iconv-warn (2015-06-08) 1 commit
- utf8.c: print warning about disabled iconv
Warn when a reencoding is requested in a build without iconv
support, as the end user is likely to get an unexpected result. I
think the same level of safety should be added to a build with
iconv suppo
Re: What's cooking in git.git (Jul 2015, #07; Mon, 27)
On Mon, Jul 27, 2015 at 02:23:04PM -0700, Junio C Hamano wrote: > * bc/object-id (2015-06-17) 10 commits > . remote.c: use struct object_id in many functions > . object-id: use struct object_id in struct object > . remote.c: use struct object_id in ref_newer() > . transport-helper.c: use struct object_id in push_refs_with_export() > . connect.c: use struct object_id in get_remote_heads() > . remote-curl: use struct object_id in parse_fetch() > . fetch-pack: use struct object_id in add_sought_entry_mem() > . object_id: convert struct ref to use object_id. > . sha1_file: introduce has_object_file() helper > . refs: convert some internal functions to use object_id > > More transition from "unsigned char[40]" to "struct object_id". > > While GSoC and other topics are actively moving existing code > around, this cannot go in; ejected from 'pu'. Is there anything I can do to make this series less painful (e.g. a reroll or such)? If waiting is the best technique, that's fine; I just want to minimize the impact of this change in terms of other code and maintainer burden. -- 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 (Jul 2015, #07; Mon, 27)
"brian m. carlson" writes: > On Mon, Jul 27, 2015 at 02:23:04PM -0700, Junio C Hamano wrote: >> * bc/object-id (2015-06-17) 10 commits >> . remote.c: use struct object_id in many functions >> . object-id: use struct object_id in struct object >> . remote.c: use struct object_id in ref_newer() >> . transport-helper.c: use struct object_id in push_refs_with_export() >> . connect.c: use struct object_id in get_remote_heads() >> . remote-curl: use struct object_id in parse_fetch() >> . fetch-pack: use struct object_id in add_sought_entry_mem() >> . object_id: convert struct ref to use object_id. >> . sha1_file: introduce has_object_file() helper >> . refs: convert some internal functions to use object_id >> >> More transition from "unsigned char[40]" to "struct object_id". >> >> While GSoC and other topics are actively moving existing code >> around, this cannot go in; ejected from 'pu'. > > Is there anything I can do to make this series less painful (e.g. a > reroll or such)? For the GSoC part, "Suggested 'pencils down' date" is August 17th. The "Firm 'pencils down date'" is on 21th, so things should stabilize. On the "unify ref-listing commands" side, the big code movement is in kn/for-each-ref which should hit master soon, but there are other less intrusive series active. (That doesn't really answer your question, but may be relevant information) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 2015, #07; Mon, 27)
On Thu, Jul 30, 2015 at 11:58:05AM +0200, Matthieu Moy wrote: > "brian m. carlson" writes: > > > On Mon, Jul 27, 2015 at 02:23:04PM -0700, Junio C Hamano wrote: > >> * bc/object-id (2015-06-17) 10 commits > > Is there anything I can do to make this series less painful (e.g. a > > reroll or such)? > > For the GSoC part, "Suggested 'pencils down' date" is August 17th. The > "Firm 'pencils down date'" is on 21th, so things should stabilize. > > On the "unify ref-listing commands" side, the big code movement is in > kn/for-each-ref which should hit master soon, but there are other less > intrusive series active. > > (That doesn't really answer your question, but may be relevant > information) It's certainly helpful to know the timeline. I'm fine with waiting, but I anticipate that there will be pain when it finally goes into pu, and if there's anything I can do to minimize that, I'd like to. -- 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
