Re: What's cooking in git.git (Mar 2015, #07; Fri, 20)
brian m. carlson sand...@crustytoothpaste.net writes: On Fri, Mar 20, 2015 at 08:20:58PM -0700, Junio C Hamano wrote: I had an impression that the series may see at least one reroll to polish it further before it gets ready for 'next', as I only saw discussions on the tangent (e.g. possible futures) and didn't see serious reviews of the code that we will actually be using. If people have suggestions on how to improve it, I'm eager to hear them and submit a reroll or follow-up patches, as appropriate. Making changes now would be much better than having to do it down the line. Yeah, agreed on the last point, and that is why I kept it out of 'next' before people have enough time to think about it. 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 (Mar 2015, #07; Fri, 20)
On Fri, Mar 20, 2015 at 08:20:58PM -0700, Junio C Hamano wrote: I had an impression that the series may see at least one reroll to polish it further before it gets ready for 'next', as I only saw discussions on the tangent (e.g. possible futures) and didn't see serious reviews of the code that we will actually be using. If people have suggestions on how to improve it, I'm eager to hear them and submit a reroll or follow-up patches, as appropriate. Making changes now would be much better than having to do it down the line. -- 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 (Mar 2015, #07; Fri, 20)
On Mar 20, 2015, at 15:02, Junio C Hamano wrote: * bc/object-id (2015-03-13) 10 commits - apply: convert threeway_stage to object_id - patch-id: convert to use struct object_id - commit: convert parts to struct object_id - diff: convert struct combine_diff_path to object_id - bulk-checkin.c: convert to use struct object_id - zip: use GIT_SHA1_HEXSZ for trailers - archive.c: convert to use struct object_id - bisect.c: convert leaf functions to use struct object_id - define utility functions for object IDs - define a structure for object IDs Identify parts of the code that knows that we use SHA-1 hash to name our objects too much, and use (1) symbolic constants instead of hardcoded 20 as byte count and/or (2) use struct object_id instead of unsigned char [20] for object names. Will cook in 'next'. Has this been merged to 'next'? Even fetching github.com/gitster/ git.git I'm only seeing it in pu: $ git rev-parse bc/object-id d07d4ab401173a10173f2747cf5e0f074b6d2b39 $ git branch --contains d07d4ab401173a10173f2747cf5e0f074b6d2b39 --all bc/object-id jch pu remotes/github2/pu remotes/gob-private/pu remotes/gph/pu remotes/ko/pu remotes/repo/pu -Kyle -- 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 (Mar 2015, #07; Fri, 20)
On Mar 20, 2015, at 16:29, Stefan Beller wrote: On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay mack...@gmail.com wrote: On Mar 20, 2015, at 15:02, Junio C Hamano wrote: * bc/object-id (2015-03-13) 10 commits [snip] Will cook in 'next'. Has this been merged to 'next'? Usually Junio writes the mail first and then does a git push all the branches just before being done for the day. At least that's my suspicion as an observer of the timing when git fetch returns new shiny stuff and when these emails are sent. I would expect that if it said, Will merge to 'next'. However the What's cooking in git.git (Mar 2015, #06; Tue, 17) also says Will cook in 'next' for this topic so I think that perhaps it's fallen through the cracks somehow. -Kyle -- 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 (Mar 2015, #07; Fri, 20)
On Fri, Mar 20, 2015 at 4:24 PM, Kyle J. McKay mack...@gmail.com wrote: Has this been merged to 'next'? Usually Junio writes the mail first and then does a git push all the branches just before being done for the day. At least that's my suspicion as an observer of the timing when git fetch returns new shiny stuff and when these emails are sent. -- 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 (Mar 2015, #07; Fri, 20)
Kyle J. McKay mack...@gmail.com writes: Will cook in 'next'. Has this been merged to 'next'? Even fetching github.com/gitster/git.git I'm only seeing it in pu: That was a short-hand for will merge and cook in 'next' ;-) I had an impression that the series may see at least one reroll to polish it further before it gets ready for 'next', as I only saw discussions on the tangent (e.g. possible futures) and didn't see serious reviews of the code that we will actually be using. -- 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 (Mar 2015, #07; Fri, 20)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Now we are almost at the end of week #6, and hopefully we can do a -rc0 late next week to start wrapping this cycle up. 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] * jc/decorate-leaky-separator-color (2015-03-04) 7 commits (merged to 'next' on 2015-03-13 at 38e7cd1) + log --decorate: do not leak commit color into the next item + Documentation/config.txt: simplify boolean description in the syntax section + Documentation/config.txt: describe 'color' value type in the Values section + Documentation/config.txt: have a separate Values section + Documentation/config.txt: describe the structure first and then meaning + Documentation/config.txt: explain multi-valued variables once + Documentation/config.txt: avoid unnecessary negation (this branch is used by mg/log-decorate-HEAD.) git log --decorate did not reset colors correctly around the branch names. * km/bsd-shells (2015-03-10) 5 commits (merged to 'next' on 2015-03-13 at f839e4c) + t5528: do not fail with FreeBSD shell + help.c: use SHELL_PATH instead of hard-coded /bin/sh + git-compat-util.h: move SHELL_PATH default into header + git-instaweb: use @SHELL_PATH@ instead of /bin/sh + git-instaweb: allow running in a working tree subdirectory Portability fixes and workarounds for shell scripts have been added to help BSD-derived systems. * km/bsd-sysctl (2015-03-10) 2 commits (merged to 'next' on 2015-03-13 at c4557c9) + thread-utils.c: detect CPU count on older BSD-like systems + configure: support HAVE_BSD_SYSCTL option We now detect number of CPUs on older BSD-derived systems. * km/imap-send-libcurl-options (2015-03-10) 1 commit (merged to 'next' on 2015-03-13 at 569d0c4) + imap-send: use cURL automatically when NO_OPENSSL defined git imap-send learned to optionally talk with an IMAP server via libcURL; because there is no other option when Git is built with NO_OPENSSL option, use that codepath by default under such configuration. * kn/git-cd-to-empty (2015-03-06) 1 commit (merged to 'next' on 2015-03-12 at 54dea03) + git: treat git -C 'path' as a no-op when path is empty git -C '' subcmd refused to work in the current directory, unlike cd '' which silently behaves as a no-op. * mg/detached-head-report (2015-03-06) 2 commits (merged to 'next' on 2015-03-12 at 89443b5) + branch: name detached HEAD analogous to status + wt-status: refactor detached HEAD analysis git branch on a detached HEAD always said (detached from xyz), even when git status would report detached at xyz. The HEAD is actually at xyz and haven't been moved since it was detached in such a case, but the user cannot read what the current value of HEAD is when detached from is used. * mg/log-decorate-HEAD (2015-03-10) 2 commits (merged to 'next' on 2015-03-13 at 96ce660) + log: decorate HEAD with branch name + Merge branch 'jc/decorate-leaky-separator-color' into HEAD (this branch uses jc/decorate-leaky-separator-color.) Output from git log --decorate mentions HEAD when it points at a tip of an branch differently from a detached HEAD. This is a potentially backward-incompatible change. * mg/verify-commit (2015-03-10) 1 commit (merged to 'next' on 2015-03-13 at 292197f) + t7510: do not fail when gpg warns about insecure memory Workarounds for certain build of GPG that triggered false breakage in a test. * nd/versioncmp-prereleases (2015-03-10) 2 commits (merged to 'next' on 2015-03-10 at 1df647c) + config.txt: update versioncmp.prereleaseSuffix (merged to 'next' on 2015-03-03 at 6ab29cf) + versionsort: support reorder prerelease suffixes The versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0. * rs/daemon-hostname-in-strbuf (2015-03-09) 2 commits (merged to 'next' on 2015-03-12 at 7f61f07) + daemon: deglobalize hostname information + daemon: use strbuf for hostname info Code in git daemon to parse out and hold hostnames used in request interpolation has been simplified. * rs/use-isxdigit (2015-03-10) 1 commit (merged to 'next' on 2015-03-13 at 39e99dd) + use isxdigit() for checking if a character is a hexadecimal digit Code cleanup. * sb/leaks (2015-03-10) 3 commits (merged to 'next' on 2015-03-13 at 50317d6) + builtin/help.c: fix memory leak + bundle.c: fix memory leak + connect.c: do not leak conn after showing diagnosis Code cleanup. -- [New Topics] * jk/cleanup-failed-clone (2015-03-19) 2 commits - clone: drop period from end of die_errno message - clone: initialize atexit cleanup handler earlier An failure early in the git
