{"thread":{"id":"35491","subject":"What's cooking in git.git (Dec 2013, #02; Fri, 6)","startedAt":"2013-12-06T23:52:39Z","lastAt":"2013-12-18T17:46:33Z","messageCount":23,"participants":["Junio C Hamano","Felipe Contreras","Thomas Rast","Matthieu Moy","Karsten Blees","Jonathan Nieder","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231689","messageId":"xmqqk3fh1qrc.fsf@gitster.dls.corp.google.com","threadId":"35491","inReplyTo":null,"subject":"What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-06T23:52:39Z","receivedAt":"2013-12-06T23:52:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nThe tip of 'next' has been rewound, ejecting a few topics that\nused to be there.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* jn/git-gui-chmod+x (2013-11-25) 1 commit\n - git-gui: chmod +x po2msg, windows/git-gui.sh\n\n Parked here until I get the same change back from the upstream\n git-gui tree.\n\n\n* jn/gitk-chmod+x (2013-11-25) 1 commit\n - gitk: chmod +x po2msg\n\n Parked here until I get the same change back from the upstream gitk\n tree.\n\n\n* jk/name-pack-after-byte-representation (2013-12-05) 2 commits\n - pack-objects: name pack files after trailer hash\n - sha1write: make buffer const-correct\n (this branch is tangled with jk/pack-bitmap.)\n\n\n* nd/negative-pathspec (2013-12-06) 3 commits\n - pathspec.c: support adding prefix magic to a pathspec with mnemonic magic\n - Support pathspec magic :(exclude) and its short form :!\n - glossary-content.txt: rephrase magic signature part\n\n\n* nd/transport-positive-depth-only (2013-12-06) 1 commit\n - clone,fetch: catch non positive --depth option value\n\n\n* zk/difftool-counts (2013-12-06) 1 commit\n - difftool: display the number of files in the diff queue in the prompt\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ak/submodule-foreach-quoting (2013-09-27) 1 commit\n  (merged to 'next' on 2013-10-14 at d77c5f1)\n + submodule foreach: skip eval for more than one argument\n\n A behavior change, but maybe a worthwhile one: \"git submodule\n foreach\" was treating its arguments as part of a single command to\n be concatenated and passed to a shell, making writing buggy scripts\n too easy.\n\n This patch preserves the old \"just pass it to the shell\" behavior\n when a single argument is passed to 'git submodule foreach' and\n moves to a new \"skip the shell and use the arguments passed\n unmolested\" behavior when more than one argument is passed.\n\n The old behavior (always concatenating and passing to the shell)\n was similar to the 'ssh' command, while the new behavior (switching\n on the number of arguments) is what 'xterm -e' does.\n\n May need more thought to make sure this change is advertised well;\n scripts that used multiple arguments but added their own extra\n layer of quoting are broken, and the users need to adjust them.\n\n\n* bc/http-100-continue (2013-10-31) 3 commits\n  (merged to 'next' on 2013-11-01 at e12ae23)\n + remote-curl: fix large pushes with GSSAPI\n + remote-curl: pass curl slot_results back through run_slot\n + http: return curl's AUTHAVAIL via slot_results\n\n Issue \"100 Continue\" responses to help use of GSS-Negotiate\n authentication scheme over HTTP transport when needed.\n\n\n* jc/bundle (2013-11-12) 1 commit\n  (merged to 'next' on 2013-11-21 at 535b046)\n + bundle: use argv-array\n\n Code clean-up.\n\n\n* jc/merge-base-reflog (2013-10-29) 2 commits\n  (merged to 'next' on 2013-11-01 at 6114764)\n + merge-base: teach \"--fork-point\" mode\n + merge-base: use OPT_CMDMODE and clarify the command line parsing\n\n Code the logic in \"pull --rebase\" that figures out a fork point\n from reflog entries in C.\n\n\n* jc/ref-excludes (2013-11-01) 5 commits\n  (merged to 'next' on 2013-11-04 at fac1ed0)\n + rev-parse: introduce --exclude=<glob> to tame wildcards\n + rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API\n + rev-list --exclude: tests\n + document --exclude option\n + revision: introduce --exclude=<glob> to tame wildcards\n\n People often wished a way to tell \"git log --branches\" (and \"git\n log --remotes --not --branches\") to exclude some local branches\n from the expansion of \"--branches\" (similarly for \"--tags\", \"--all\"\n and \"--glob=<pattern>\").  Now they have one.\n\n\n* jh/loose-object-dirs-creation-race (2013-10-28) 1 commit\n  (merged to 'next' on 2013-11-01 at 3169b0f)\n + sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs\n\n Two processes creating loose objects at the same time could have\n failed unnecessarily when they happened to have created objects\n whose names share the same first byte.\n\n\n* jk/remove-experimental-loose-object-support (2013-11-21) 1 commit\n  (merged to 'next' on 2013-11-21 at d37bab7)\n + drop support for \"experimental\" loose objects\n\n Read-only support for experimental loose-object format, in which\n users could optionally choose to write in their loose objects for a\n short while between v1.4.3 to v1.5.3 era, has been dropped.\n\n\n* jk/replace-perl-in-built-scripts (2013-10-29) 1 commit\n  (merged to 'next' on 2013-11-01 at 2384e29)\n + use @@PERL@@ in built scripts\n\n\n* jk/robustify-parse-commit (2013-10-24) 6 commits\n  (merged to 'next' on 2013-11-01 at 2bfbaab)\n + checkout: do not die when leaving broken detached HEAD\n + use parse_commit_or_die instead of custom message\n + use parse_commit_or_die instead of segfaulting\n + assume parse_commit checks for NULL commit\n + assume parse_commit checks commit->object.parsed\n + log_tree_diff: die when we fail to parse a commit\n\n\n* jk/two-way-merge-corner-case-fix (2013-11-04) 3 commits\n  (merged to 'next' on 2013-11-04 at 79f4fb0)\n + t1005: add test for \"read-tree --reset -u A B\"\n + t1005: reindent\n + unpack-trees: fix \"read-tree -u --reset A B\" with conflicted index\n\n Fix a rather longstanding corner-case bug in twoway \"reset to\n there\" merge, which is most often seen in \"git am --abort\".\n\n\n* jl/submodule-update-retire-orig-flags (2013-11-11) 1 commit\n  (merged to 'next' on 2013-11-13 at 4b70d15)\n + submodule update: remove unnecessary orig_flags variable\n\n Code clean-up.\n\n\n* jn/mediawiki-makefile-updates (2013-11-11) 4 commits\n  (merged to 'next' on 2013-11-13 at 71c8d20)\n + git-remote-mediawiki build: handle DESTDIR/INSTLIBDIR with whitespace\n + git-remote-mediawiki build: make 'install' command configurable\n + git-remote-mediawiki: honor DESTDIR in \"make install\"\n + git-remote-mediawiki: do not remove installed files in \"clean\" target\n\n Build and installation procedure clean-up.\n\n\n* jn/perl-lib-extra (2013-11-18) 2 commits\n  (merged to 'next' on 2013-11-20 at 8c90afae)\n + Makefile: add PERLLIB_EXTRA variable that adds to default perl path\n + Makefile: rebuild perl scripts when perl paths change\n\n The new PERLLIB_EXTRA makefile variable can be used to specify\n additional directories Perl modules (e.g. the ones necessary to run\n git-svn) are installed on the platform when building.\n\n\n* nd/magic-pathspec (2013-11-20) 1 commit\n  (merged to 'next' on 2013-11-21 at f914a30)\n + diff: restrict pathspec limitations to diff b/f case only\n\n \"git diff -- ':(icase)makefile'\" was unnecessarily rejected at the\n command line parser.\n\n Needs to be merged to 'maint' later.\n\n\n* nd/wt-status-align-i18n (2013-11-06) 1 commit\n  (merged to 'next' on 2013-11-13 at b033aa0)\n + wt-status: take the alignment burden off translators\n\n An attempt to automatically align the names in the \"git status\"\n output, taking the display width of (translated) section labels\n into account.\n\n\n* nv/parseopt-opt-arg (2013-10-31) 2 commits\n  (merged to 'next' on 2013-11-01 at cd2afd9)\n + rev-parse --parseopt: add the --stuck-long mode\n + Use the word 'stuck' instead of 'sticked'\n\n Enhance \"rev-parse --parseopt\" mode to help parsing options with\n an optional parameter.\n\n\n* rh/remote-hg-bzr-updates (2013-11-18) 8 commits\n  (merged to 'next' on 2013-11-20 at a36f3c4)\n + remote-bzr, remote-hg: fix email address regular expression\n + test-hg.sh: help user correlate verbose output with email test\n + test-hg.sh: fix duplicate content strings in author tests\n + test-hg.sh: avoid obsolete 'test' syntax\n + test-hg.sh: eliminate 'local' bashism\n + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple\n + test-bzr.sh, test-hg.sh: allow running from any dir\n + test-lib.sh: convert $TEST_DIRECTORY to an absolute path\n\n\n* rr/for-each-ref-decoration (2013-11-19) 6 commits\n  (merged to 'next' on 2013-11-21 at ee7b0ed)\n + for-each-ref: avoid color leakage\n + for-each-ref: introduce %(color:...) for color\n + for-each-ref: introduce %(upstream:track[short])\n + for-each-ref: introduce %(HEAD) asterisk marker\n + t6300 (for-each-ref): don't hardcode SHA-1 hexes\n + t6300 (for-each-ref): clearly demarcate setup\n\n \"git for-each-ref --format=...\" learned a few formatting directives;\n e.g. \"%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)\".\n\n\n* sb/sha1-loose-object-info-check-existence (2013-11-06) 1 commit\n  (merged to 'next' on 2013-11-06 at 1ea5b18)\n + sha1_loose_object_info(): do not return success on missing object\n\n \"git cat-file --batch-check=ok\" did not check the existence of the\n named object.\n\n--------------------------------------------------\n[Stalled]\n\n* fc/transport-helper-fixes (2013-11-13) 12 commits\n - remote-bzr: support the new 'force' option\n - transport-helper: add support to delete branches\n - fast-export: add support to delete refs\n - fast-import: add support to delete refs\n - transport-helper: add support for old:new refspec\n - fast-export: add new --refspec option\n - fast-export: improve argument parsing\n - test-hg.sh: tests are now expected to pass\n - transport-helper: check for 'forced update' message\n - transport-helper: add 'force' to 'export' helpers\n - transport-helper: don't update refs in dry-run\n - transport-helper: mismerge fix\n\n Updates transport-helper, fast-import and fast-export to allow the\n ref mapping and ref deletion in a way similar to the natively\n supported transports.\n\n The option name \"--refspec\" needs to be rethought. It does not mean\n what refspec usually means, even though it shares the same syntax\n with refspec; calling it --refspec only because it shares the same\n syntax is like calling it --asciistring and does not make sense.\n\n\n* nv/commit-gpgsign-config (2013-11-06) 1 commit\n - Add the commit.gpgsign option to sign all commits\n\n Introduce commit.gpgsign configuration variable to force every\n commit to be GPG signed.\n\n Needs tests, perhaps?\n\n\n* jt/commit-fixes-footer (2013-10-30) 1 commit\n - commit: Add -f, --fixes <commit> option to add Fixes: line\n\n There is an ongoing discussion around this topic; in general I am\n fairly negative on a new feature that is too narrow and prefer a\n more generic solution that can be tailored for specific needs, as\n many people stated in the thread.\n\n It appears that the discussion stalled.\n\n\n* np/pack-v4 (2013-09-18) 90 commits\n . packv4-parse.c: add tree offset caching\n . t1050: replace one instance of show-index with verify-pack\n . index-pack, pack-objects: allow creating .idx v2 with .pack v4\n . unpack-objects: decode v4 trees\n . unpack-objects: allow to save processed bytes to a buffer\n - ...\n\n Nico and Duy advancing the eternal vaporware pack-v4.  This is here\n primarily for wider distribution of the preview edition.\n\n Temporarily ejected from 'pu', to try out jk/pack-bitmap, which\n this topic conflicts with.\n\n\n* jk/pack-bitmap (2013-11-18) 22 commits\n - compat/mingw.h: Fix the MinGW and msvc builds\n - pack-bitmap: implement optional name_hash cache\n - t/perf: add tests for pack bitmaps\n - t: add basic bitmap functionality tests\n - count-objects: recognize .bitmap in garbage-checking\n - repack: consider bitmaps when performing repacks\n - repack: handle optional files created by pack-objects\n - repack: turn exts array into array-of-struct\n - repack: stop using magic number for ARRAY_SIZE(exts)\n - pack-objects: implement bitmap writing\n - rev-list: add bitmap mode to speed up object lists\n - pack-objects: use bitmaps when packing objects\n - pack-bitmap: add support for bitmap indexes\n - documentation: add documentation for the bitmap format\n - ewah: compressed bitmap implementation\n - compat: add endianness helpers\n - sha1_file: export `git_open_noatime`\n - revision: allow setting custom limiter function\n - pack-objects: factor out name_hash\n - pack-objects: refactor the packing list\n - revindex: export new APIs\n - sha1write: make buffer const-correct\n (this branch is tangled with jk/name-pack-after-byte-representation.)\n\n Borrows the bitmap index into packfiles from JGit to speed up\n enumeration of objects involved in a commit range without having to\n fully traverse the history.\n\n\n* mf/graph-show-root (2013-10-25) 1 commit\n . graph.c: mark root commit differently\n\n In a repository with multiple-roots, \"log --graph\", especially with\n \"--oneline\", does not give the reader enough visual cue to see\n where one line of history ended and a separate history began.\n\n This is the version that marks the roots 'x' when they would have\n been marked as '*'; Keshav Kini suggested an alternative of giving\n an extra blank line after every root, which I tend to think is a\n better approach to the problem.\n\n\n* tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits\n - perf-lib: add test_perf_cleanup target\n - perf-lib: split starting the test from the execution\n\n Add test_perf_cleanup shell function to the perf suite, that allows\n the script writers to define a test with a clean-up action.\n\n Holding until needed.\n\n\n* yt/shortened-rename (2013-10-18) 2 commits\n - SQUASH??? style fixes and s/omit/shorten/ where appropriate\n - diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible\n\n Attempts to give more weight on the fact that a filepair represents\n a rename than showing substring of the actual path when diffstat\n lines are not wide enough.\n\n I am not sure if that is solving a right problem, though.\n\n\n* rv/send-email-cache-generated-mid (2013-08-21) 2 commits\n - git-send-email: Cache generated message-ids, use them when prompting\n - git-send-email: add optional 'choices' parameter to the ask sub\n\n\n* rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits\n - ### DONTMERGE: needs better explanation on what config they need\n - pack-refs.c: Add missing call to git_config()\n - show-ref.c: Add missing call to git_config()\n\n The changes themselves are probably good, but it is unclear what\n basic setting needs to be read for which exact operation.\n\n Waiting for clarification.\n $gmane/228294\n\n\n* jc/format-patch (2013-04-22) 2 commits\n - format-patch: --inline-single\n - format-patch: rename \"no_inline\" field\n\n A new option to send a single patch to the standard output to be\n appended at the bottom of a message.  I personally have no need for\n this, but it was easy enough to cobble together.  Tests, docs and\n stripping out more MIMEy stuff are left as exercises to interested\n parties.\n\n\n* jk/gitweb-utf8 (2013-04-08) 4 commits\n - gitweb: Fix broken blob action parameters on blob/commitdiff pages\n - gitweb: Don't append ';js=(0|1)' to external links\n - gitweb: Make feed title valid utf8\n - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch\n\n Various fixes to gitweb.\n\n Drew Northup volunteered to take a look into this.\n $gmane/226216\n\n\n* jc/show-branch (2013-06-07) 5 commits\n - show-branch: use commit slab to represent bitflags of arbitrary width\n - show-branch.c: remove \"all_mask\"\n - show-branch.c: abstract out \"flags\" operation\n - show-branch.c: lift all_mask/all_revs to a global static\n - show-branch.c: update comment style\n\n Waiting for the final step to lift the hard-limit before sending it out.\n\n--------------------------------------------------\n[Cooking]\n\n* jl/commit-v-strip-marker (2013-12-05) 1 commit\n - commit -v: strip diffs and submodule shortlogs from the commit message\n\n\n* cl/p4-use-diff-tree (2013-11-22) 1 commit\n  (merged to 'next' on 2013-12-06 at fc3c89e)\n + git p4: Use git diff-tree instead of format-patch\n\n Originally merged to 'next' on 2013-11-27\n\n Will merge to 'master'.\n\n\n* jn/scripts-updates (2013-11-26) 7 commits\n  (merged to 'next' on 2013-12-06 at 60a7026)\n + remove #!interpreter line from shell libraries\n + test: replace shebangs with descriptions in shell libraries\n + test: make FILEMODE a lazy prereq\n + contrib: remove git-p4import\n + mark contributed hooks executable\n + mark perl test scripts executable\n + mark Windows build scripts executable\n\n Will merge to 'master'.\n\n\n* tr/commit-slab-cleanup (2013-12-02) 3 commits\n  (merged to 'next' on 2013-12-06 at faee247)\n + commit-slab: sizeof() the right type in xrealloc\n + commit-slab: declare functions \"static inline\"\n + commit-slab: document clear_$slabname()\n\n Originally merged to 'next' on 2013-12-02\n\n Will merge to 'master'.\n\n\n* tr/doc-git-cherry (2013-11-27) 1 commit\n  (merged to 'next' on 2013-12-06 at 9a1ba7a)\n + Documentation: revamp git-cherry(1)\n\n Originally merged to 'next' on 2013-11-27\n\n Will merge to 'master'.\n\n\n* rs/doc-submitting-patches (2013-11-27) 1 commit\n  (merged to 'next' on 2013-12-06 at 0628818)\n + SubmittingPatches: document how to handle multiple patches\n\n Originally merged to 'next' on 2013-11-27\n\n Will merge to 'master'.\n\n\n* cc/starts-n-ends-with (2013-12-05) 4 commits\n - replace {pre,suf}fixcmp() with {starts,ends}_with()\n - strbuf: introduce starts_with() and ends_with()\n - builtin/remote: remove postfixcmp() and use suffixcmp() instead\n - environment: normalize use of prefixcmp() by removing \" != 0\"\n (this branch is used by cc/starts-n-ends-with-endgame; uses jk/remove-deprecated.)\n\n Remove a few duplicate implementations of prefix/suffix comparison\n functions, and rename them to starts_with and ends_with.\n\n To avoid unnecessary merge conflicts, this is queued on top of\n jk/remove-deprecated topic.\n\n\n* cc/starts-n-ends-with-endgame (2013-12-05) 1 commit\n - strbuf: remove prefixcmp() and suffixcmp()\n (this branch uses cc/starts-n-ends-with and jk/remove-deprecated.)\n\n Endgame for the above topic, that needs to be evil-merged with\n other topics that introduce new uses of prefix/suffix-cmp\n functions.\n\n\n* jc/push-refmap (2013-12-04) 3 commits\n - push: also use \"upstream\" mapping when pushing a single ref\n - push: use remote.$name.push as a refmap\n - builtin/push.c: use strbuf instead of manual allocation\n\n Make \"git push origin master\" update the same ref that would be\n updated by our 'master' when \"git push origin\" (no refspecs) is run\n while the 'master' branch is checked out, which makes \"git push\"\n more symmetric to \"git fetch\" and more usable for the triangular\n workflow.\n\n\n* jk/t5000-gzip-simplify (2013-12-04) 1 commit\n - t5000: simplify gzip prerequisite checks\n\n Test fix.\n\n\n* js/gnome-keyring (2013-12-04) 1 commit\n - contrib/git-credential-gnome-keyring.c: small stylistic cleanups\n\n Style fix.\n\n\n* kn/gitweb-extra-branch-refs (2013-12-04) 4 commits\n - gitweb: Denote non-heads, non-remotes branches\n - gitweb: Add a feature for adding more branch refs\n - gitweb: Return plain booleans in validation methods\n - gitweb: Move check-ref-format code into separate function\n\n Allow gitweb to be configured to show refs out of refs/heads/ as if\n they were branches.\n\n\n* mm/mv-file-to-no-such-dir-with-slash (2013-12-04) 1 commit\n - mv: let 'git mv file no-such-dir/' error out\n\n\n* nd/gettext-vsnprintf (2013-12-04) 1 commit\n - gettext.c: detect the vsnprintf bug at runtime\n\n\n* tr/send-email-ssl (2013-12-04) 3 commits\n - send-email: set SSL options through IO::Socket::SSL::set_client_defaults\n - send-email: --smtp-ssl-cert-path takes an argument\n - send-email: pass Debug to Net::SMTP::SSL::new\n\n\n* tb/clone-ssh-with-colon-for-port (2013-12-04) 10 commits\n - git_connect(): use common return point\n - connect.c: refactor url parsing\n - git_connect(): refactor the port handling for ssh\n - git fetch: support host:/~repo\n - t5500: add test cases for diag-url\n - git fetch-pack: add --diag-url\n - git_connect: factor out discovery of the protocol and its parts\n - git_connect: remove artificial limit of a remote command\n - t5601: add tests for ssh\n - t5601: remove clear_ssh, refactor setup_ssh_wrapper\n\n\n* cn/thin-push-capability (2013-11-25) 1 commit\n  (merged to 'next' on 2013-12-06 at a7ae524)\n + send-pack: don't send a thin pack to a server which doesn't support it\n\n Allow receive-pack to insist on receiving a fat pack from \"git\n push\" clients.\n\n Will merge to 'master'.\n\n\n* jk/remove-deprecated (2013-12-05) 6 commits\n  (merged to 'next' on 2013-12-06 at c0c91a2)\n + Sync with 1.8.5\n + stop installing git-tar-tree link\n + peek-remote: remove deprecated alias of ls-remote\n + lost-found: remove deprecated command\n + tar-tree: remove deprecated command\n + repo-config: remove deprecated alias for \"git config\"\n (this branch is used by cc/starts-n-ends-with and cc/starts-n-ends-with-endgame.)\n\n Originally merged to 'next' on 2013-12-03\n\n Will merge to 'master'.\n\n\n* tr/config-multivalue-lift-max (2013-12-06) 1 commit\n  (merged to 'next' on 2013-12-06 at 92afee2)\n + config: arbitrary number of matches for --unset and --replace-all\n\n Originally merged to 'next' on 2013-11-20\n\n Will merge to 'master'.\n\n\n* kb/doc-exclude-directory-semantics (2013-11-07) 1 commit\n - gitignore.txt: clarify recursive nature of excluded directories\n\n Originally merged to 'next' on 2013-11-13\n\n Kicked back to 'pu' to replace with a newer reroll ($gmane/237814\n looked OK but there seems to have some loose ends in the\n discussion).\n\n\n* jc/create-directories-microopt (2013-11-11) 1 commit\n - checkout: most of the time we have good leading directories\n\n Of unknown value until tested on non-Linux platforms (especially\n Windows).\n\n Will hold.\n\n\n* gj/push-more-verbose-advice (2013-11-13) 1 commit\n  (merged to 'next' on 2013-12-06 at 574b18a)\n + push: switch default from \"matching\" to \"simple\"\n\n Originally merged to 'next' on 2013-11-21\n\n Explain 'simple' and 'matching' in \"git push\" advice message; the\n topmost patch is a rebase of jc/push-2.0-default-to-simple on top\n of it.\n\n Will cook in 'next'.\n\n\n* tr/merge-recursive-index-only (2013-10-28) 3 commits\n - merge-recursive: -Xindex-only to leave worktree unchanged\n - merge-recursive: internal flag to avoid touching the worktree\n - merge-recursive: remove dead conditional in update_stages()\n\n Will hold until using script appears.\n\n\n* mh/fetch-tags-in-addition-to-normal-refs (2013-10-30) 23 commits\n  (merged to 'next' on 2013-12-06 at 3b9c44a)\n + fetch: improve the error messages emitted for conflicting refspecs\n + handle_duplicate(): mark error message for translation\n + ref_remote_duplicates(): extract a function handle_duplicate()\n + ref_remove_duplicates(): simplify loop logic\n + t5536: new test of refspec conflicts when fetching\n + ref_remove_duplicates(): avoid redundant bisection\n + git-fetch.txt: improve description of tag auto-following\n + fetch-options.txt: simplify ifdef/ifndef/endif usage\n + fetch, remote: properly convey --no-prune options to subprocesses\n + builtin/remote.c:update(): use struct argv_array\n + builtin/remote.c: reorder function definitions\n + query_refspecs(): move some constants out of the loop\n + fetch --prune: prune only based on explicit refspecs\n + fetch --tags: fetch tags *in addition to* other stuff\n + fetch: only opportunistically update references based on command line\n + get_expanded_map(): avoid memory leak\n + get_expanded_map(): add docstring\n + builtin/fetch.c: reorder function definitions\n + get_ref_map(): rename local variables\n + api-remote.txt: correct section \"struct refspec\"\n + t5510: check that \"git fetch --prune --tags\" does not prune branches\n + t5510: prepare test refs more straightforwardly\n + t5510: use the correct tag name in test\n\n Originally merged to 'next' on 2013-11-06\n\n The \"--tags\" option to \"git fetch\" used to be literally a synonym to\n a \"refs/tags/*:refs/tags/*\" refspec, which meant that (1) as an\n explicit refspec given from the command line, it silenced the lazy\n \"git fetch\" default that is configured, and (2) also as an explicit\n refspec given from the command line, it interacted with \"--prune\"\n to remove any tag that the remote we are fetching from does not\n have.\n\n This demotes it to an option; with it, we fetch all tags in\n addition to what would be fetched without the option, and it does\n not interact with the decision \"--prune\" makes to see what\n remote-tracking refs the local has are missing the remote\n counterpart.\n\n Will merge to 'master'.\n\n\n* kb/fast-hashmap (2013-11-18) 14 commits\n  (merged to 'next' on 2013-12-06 at f90be3d)\n + read-cache.c: fix memory leaks caused by removed cache entries\n + builtin/update-index.c: cleanup update_one\n + fix 'git update-index --verbose --again' output\n + remove old hash.[ch] implementation\n + name-hash.c: remove cache entries instead of marking them CE_UNHASHED\n + name-hash.c: use new hash map implementation for cache entries\n + name-hash.c: remove unreferenced directory entries\n + name-hash.c: use new hash map implementation for directories\n + diffcore-rename.c: use new hash map implementation\n + diffcore-rename.c: simplify finding exact renames\n + diffcore-rename.c: move code around to prepare for the next patch\n + buitin/describe.c: use new hash map implementation\n + add a hashtable implementation that supports O(1) removal\n + submodule: don't access the .gitmodules cache entry after removing it\n\n Improvements to our hash table to get it to meet the needs of the\n msysgit fscache project, with some nice performance improvements.\n\n Will cook in 'next'.\n\n\n* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit\n  (merged to 'next' on 2013-12-06 at ead2ec8)\n + git add: -u/-A now affects the entire working tree\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/core-checkstat-2.0 (2013-05-06) 1 commit\n  (merged to 'next' on 2013-12-06 at ae18007)\n + core.statinfo: remove as promised in Git 2.0\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/push-2.0-default-to-simple (2013-06-18) 1 commit\n  (merged to 'next' on 2013-12-06 at 6fad61c)\n + push: switch default from \"matching\" to \"simple\"\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/add-2.0-ignore-removal (2013-04-22) 1 commit\n  (merged to 'next' on 2013-12-06 at fbaa75a)\n + git add <pathspec>... defaults to \"-A\"\n\n Updated endgame for \"git add <pathspec>\" that defaults to \"--all\"\n aka \"--no-ignore-removal\".\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/hold-diff-remove-q-synonym-for-no-deletion (2013-07-19) 1 commit\n  (merged to 'next' on 2013-12-06 at 083d67c)\n + diff: remove \"diff-files -q\" in a version of Git in a distant future\n\n Will cook in 'next' until a distant future.\n\n--------------------------------------------------\n[Discarded]\n\n* aa/transport-non-positive-depth-only (2013-11-26) 1 commit\n . transport: catch non positive --depth option value\n\n\n* cc/remote-remove-redundant-postfixcmp (2013-11-06) 2 commits\n . Rename suffixcmp() to has_suffix() and invert its result\n . builtin/remote: remove postfixcmp() and use suffixcmp() instead\n\n\n* th/reflog-annotated-tag (2013-10-28) 1 commit\n . reflog: handle lightweight and annotated tags equally\n\n \"git log -g $annotated_tag\", when there is no reflog history, should\n have produced a single output entry (i.e. the ref creation event),\n but instead showed the history leading to the tag.\n\n Broken at the design level.  Any reflog entry that points at a non\n commit needs to be handled with new code that does not exist yet,\n and lifting the \"this code handles only commits\" without adding\n such code does not solve anything.\n"},{"id":"231698","messageId":"52a2f27bfe07_29836d5e98f5@nysa.notmuch","threadId":"35491","inReplyTo":"xmqqk3fh1qrc.fsf@gitster.dls.corp.google.com","subject":"RE: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-12-07T10:03:39Z","receivedAt":"2013-12-07T10:03:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> * fc/transport-helper-fixes (2013-11-13) 12 commits\n>  - remote-bzr: support the new 'force' option\n>  - transport-helper: add support to delete branches\n>  - fast-export: add support to delete refs\n>  - fast-import: add support to delete refs\n>  - transport-helper: add support for old:new refspec\n>  - fast-export: add new --refspec option\n>  - fast-export: improve argument parsing\n>  - test-hg.sh: tests are now expected to pass\n>  - transport-helper: check for 'forced update' message\n>  - transport-helper: add 'force' to 'export' helpers\n>  - transport-helper: don't update refs in dry-run\n>  - transport-helper: mismerge fix\n> \n>  Updates transport-helper, fast-import and fast-export to allow the\n>  ref mapping and ref deletion in a way similar to the natively\n>  supported transports.\n> \n>  The option name \"--refspec\" needs to be rethought. It does not mean\n>  what refspec usually means, even though it shares the same syntax\n>  with refspec; calling it --refspec only because it shares the same\n>  syntax is like calling it --asciistring and does not make sense.\n\nNot true. remote.<name>.fetch is a refspec, and doesn't specify what to fetch,\nso does the \"refspec\" capability in remote helpers, and so does the proposed\n--refspec option.\n\nIt is exactly what it already means.\n\n-- \nFelipe Contreras\n"},{"id":"231730","messageId":"87ppp8h9ut.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098","threadId":"35491","inReplyTo":"xmqqk3fh1qrc.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-12-07T17:03:22Z","receivedAt":"2013-12-07T17:03:22Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> * jk/pack-bitmap (2013-11-18) 22 commits\n>  - compat/mingw.h: Fix the MinGW and msvc builds\n>  - pack-bitmap: implement optional name_hash cache\n>  - t/perf: add tests for pack bitmaps\n>  - t: add basic bitmap functionality tests\n>  - count-objects: recognize .bitmap in garbage-checking\n>  - repack: consider bitmaps when performing repacks\n>  - repack: handle optional files created by pack-objects\n>  - repack: turn exts array into array-of-struct\n>  - repack: stop using magic number for ARRAY_SIZE(exts)\n>  - pack-objects: implement bitmap writing\n>  - rev-list: add bitmap mode to speed up object lists\n>  - pack-objects: use bitmaps when packing objects\n>  - pack-bitmap: add support for bitmap indexes\n>  - documentation: add documentation for the bitmap format\n>  - ewah: compressed bitmap implementation\n>  - compat: add endianness helpers\n>  - sha1_file: export `git_open_noatime`\n>  - revision: allow setting custom limiter function\n>  - pack-objects: factor out name_hash\n>  - pack-objects: refactor the packing list\n>  - revindex: export new APIs\n>  - sha1write: make buffer const-correct\n>  (this branch is tangled with jk/name-pack-after-byte-representation.)\n>\n>  Borrows the bitmap index into packfiles from JGit to speed up\n>  enumeration of objects involved in a commit range without having to\n>  fully traverse the history.\n\nPeff can decide if he wants to reroll with my nits or not; either way\nI'm all for moving it forward and aiming for one of the next releases.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"231735","messageId":"vpqzjocwl63.fsf@anie.imag.fr","threadId":"35491","inReplyTo":"xmqqk3fh1qrc.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-12-07T18:49:56Z","receivedAt":"2013-12-07T18:49:56Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> * mm/mv-file-to-no-such-dir-with-slash (2013-12-04) 1 commit\n>  - mv: let 'git mv file no-such-dir/' error out\n\nWhy is it \"stalled\"? I think I took all remarks into account.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"231739","messageId":"52A37D70.3090400@gmail.com","threadId":"35491","inReplyTo":"xmqqk3fh1qrc.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-07T19:56:32Z","receivedAt":"2013-12-07T19:56:32Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 07.12.2013 00:52, schrieb Junio C Hamano:\n\n> * kb/doc-exclude-directory-semantics (2013-11-07) 1 commit\n>  - gitignore.txt: clarify recursive nature of excluded directories\n> \n>  Originally merged to 'next' on 2013-11-13\n> \n>  Kicked back to 'pu' to replace with a newer reroll ($gmane/237814\n>  looked OK but there seems to have some loose ends in the\n>  discussion).\n\nI'm unaware of any loose ends, could you clarify?\n\nBtw. $gmane/237814 seems to be a different topic, the version in next (and now in pu) was $gmane/237429.\n\n\n> * kb/fast-hashmap (2013-11-18) 14 commits\n>   (merged to 'next' on 2013-12-06 at f90be3d) \n\nDamn, a day too late :-) I found these two glitches today...is a fixup patch OK or should I do a reroll (or separate patch on top)?\n\nThanks,\nKarsten\n\n--- 8< ---\nSubject: [PATCH] fixup! add a hashtable implementation that supports O(1) removal\n\nUse 'unsigned int' for hash-codes everywhere.\n\nExtending 'struct hashmap_entry' with an int-sized member shouldn't waste\nmemory on 64-bit systems. This is already documented in api-hashmap.txt,\nbut needs '__attribute__((__packed__))' to work. Reduces e.g.\n\n struct name_entry {\n     struct hashmap_entry ent;\n     int namelen;\n     char *name;\n };\n\nfrom 32 to 24 bytes.\n\nSigned-off-by: Karsten Blees <blees@dcon.de>\n---\n hashmap.h | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/hashmap.h b/hashmap.h\nindex f5b3b61..b64567b 100644\n--- a/hashmap.h\n+++ b/hashmap.h\n@@ -15,7 +15,7 @@ extern unsigned int memihash(const void *buf, size_t len);\n \n /* data structures */\n \n-struct hashmap_entry {\n+struct __attribute__((__packed__)) hashmap_entry {\n \tstruct hashmap_entry *next;\n \tunsigned int hash;\n };\n@@ -43,7 +43,7 @@ extern void hashmap_free(struct hashmap *map, int free_entries);\n \n /* hashmap_entry functions */\n \n-static inline void hashmap_entry_init(void *entry, int hash)\n+static inline void hashmap_entry_init(void *entry, unsigned int hash)\n {\n \tstruct hashmap_entry *e = entry;\n \te->hash = hash;\n-- \n1.8.5.1.178.g0a9afc1.dirty\n"},{"id":"231740","messageId":"CAMP44s0sankG67rknVo=g5aOJXS_GZBh+hkr9cyVSiYrEvt83Q@mail.gmail.com","threadId":"35491","inReplyTo":"52a2f27bfe07_29836d5e98f5@nysa.notmuch","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-12-07T20:30:40Z","receivedAt":"2013-12-07T20:30:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Dec 7, 2013 at 4:03 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> Junio C Hamano wrote:\n>> * fc/transport-helper-fixes (2013-11-13) 12 commits\n>>  - remote-bzr: support the new 'force' option\n>>  - transport-helper: add support to delete branches\n>>  - fast-export: add support to delete refs\n>>  - fast-import: add support to delete refs\n>>  - transport-helper: add support for old:new refspec\n>>  - fast-export: add new --refspec option\n>>  - fast-export: improve argument parsing\n>>  - test-hg.sh: tests are now expected to pass\n>>  - transport-helper: check for 'forced update' message\n>>  - transport-helper: add 'force' to 'export' helpers\n>>  - transport-helper: don't update refs in dry-run\n>>  - transport-helper: mismerge fix\n>>\n>>  Updates transport-helper, fast-import and fast-export to allow the\n>>  ref mapping and ref deletion in a way similar to the natively\n>>  supported transports.\n>>\n>>  The option name \"--refspec\" needs to be rethought. It does not mean\n>>  what refspec usually means, even though it shares the same syntax\n>>  with refspec; calling it --refspec only because it shares the same\n>>  syntax is like calling it --asciistring and does not make sense.\n>\n> Not true. remote.<name>.fetch is a refspec, and doesn't specify what to fetch,\n> so does the \"refspec\" capability in remote helpers, and so does the proposed\n> --refspec option.\n>\n> It is exactly what it already means.\n\nNot to mention that you can apply the first part of the series without\nany problems:\n\n>>  - fast-export: improve argument parsing\n>>  - test-hg.sh: tests are now expected to pass\n>>  - transport-helper: check for 'forced update' message\n>>  - transport-helper: add 'force' to 'export' helpers\n>>  - transport-helper: don't update refs in dry-run\n>>  - transport-helper: mismerge fix\n\nEven:\n\n>>  - remote-bzr: support the new 'force' option\n\nThe rest is for old:new :to-delete refspecs.\n\nTo take hostage the whole patch series because of the name --refspec\n(which is perfectly fine) is just an excuse to not fix the issues\nalready present.\n\n-- \nFelipe Contreras\n"},{"id":"231749","messageId":"87fvq41esw.fsf@thomasrast.ch","threadId":"35491","inReplyTo":"52A37D70.3090400@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-12-07T22:23:11Z","receivedAt":"2013-12-07T22:23:11Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Karsten Blees <karsten.blees@gmail.com> writes:\n\n> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste\n> memory on 64-bit systems. This is already documented in api-hashmap.txt,\n> but needs '__attribute__((__packed__))' to work. Reduces e.g.\n\nYou'd have to guard __attribute__((__packed__)) with some compiler\ndetection in git-compat-util.h though.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"231750","messageId":"52A3A1F5.3080906@gmail.com","threadId":"35491","inReplyTo":"87fvq41esw.fsf@thomasrast.ch","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-07T22:32:21Z","receivedAt":"2013-12-07T22:32:21Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 07.12.2013 23:23, schrieb Thomas Rast:\n> Karsten Blees <karsten.blees@gmail.com> writes:\n> \n>> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste\n>> memory on 64-bit systems. This is already documented in api-hashmap.txt,\n>> but needs '__attribute__((__packed__))' to work. Reduces e.g.\n> \n> You'd have to guard __attribute__((__packed__)) with some compiler\n> detection in git-compat-util.h though.\n> \n\nIsn't that already handled? __attribute__ is already widely used (e.g. for printf formats), and platforms that don't support it define it as empty (e.g. MSVC). Or do you mean I should account for compiler-specific variants (#pragma pack...)?\n"},{"id":"231763","messageId":"87lhzvhceb.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098","threadId":"35491","inReplyTo":"52A3A1F5.3080906@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-12-08T10:20:44Z","receivedAt":"2013-12-08T10:20:44Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Karsten Blees <karsten.blees@gmail.com> writes:\n\n> Am 07.12.2013 23:23, schrieb Thomas Rast:\n>> Karsten Blees <karsten.blees@gmail.com> writes:\n>> \n>>> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste\n>>> memory on 64-bit systems. This is already documented in api-hashmap.txt,\n>>> but needs '__attribute__((__packed__))' to work. Reduces e.g.\n>> \n>> You'd have to guard __attribute__((__packed__)) with some compiler\n>> detection in git-compat-util.h though.\n>> \n>\n> Isn't that already handled? __attribute__ is already widely used\n> (e.g. for printf formats), and platforms that don't support it define\n> it as empty (e.g. MSVC). Or do you mean I should account for\n> compiler-specific variants (#pragma pack...)?\n\nTrue, __attribute__ expands to nothing on unknown compilers, but what\ndoes the compiler do when it sees an unknown attribute?  If some of them\nchoke, you need a separate macro.\n\nI'm a bit confused myself though, many attributes have special macros in\ngit-compat-util.h but others we just use in the code.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"231788","messageId":"52A5CDB0.2020206@gmail.com","threadId":"35491","inReplyTo":"87lhzvhceb.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-09T14:03:28Z","receivedAt":"2013-12-09T14:03:28Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 08.12.2013 11:20, schrieb Thomas Rast:\n> Karsten Blees <karsten.blees@gmail.com> writes:\n> \n>> Am 07.12.2013 23:23, schrieb Thomas Rast:\n>>> Karsten Blees <karsten.blees@gmail.com> writes:\n>>>\n>>>> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste\n>>>> memory on 64-bit systems. This is already documented in api-hashmap.txt,\n>>>> but needs '__attribute__((__packed__))' to work. Reduces e.g.\n>>>\n>>> You'd have to guard __attribute__((__packed__)) with some compiler\n>>> detection in git-compat-util.h though.\n>>>\n>>\n>> Isn't that already handled? __attribute__ is already widely used\n>> (e.g. for printf formats), and platforms that don't support it define\n>> it as empty (e.g. MSVC). Or do you mean I should account for\n>> compiler-specific variants (#pragma pack...)?\n> \n> True, __attribute__ expands to nothing on unknown compilers, but what\n> does the compiler do when it sees an unknown attribute?  If some of them\n> choke, you need a separate macro.\n> \n> I'm a bit confused myself though, many attributes have special macros in\n> git-compat-util.h but others we just use in the code.\n> \n\nSo what do you propose? I basically see three options:\n\n1.) Trial and error\n\nGCC supports __packed__ as of 2.3 (1992), so any other compilers that copied the __attribute__ feature probably won't complain.\n\n2.) Accept the wasted memory\n\nMoving the hash code from the hash table (as in hash.[ch]) to the entry is already a big improvement, as it no longer multiplies hash code + wasted bytes with the load factor. 64-bit software uses more memory in general, so we could just live with it (and only fix the documentation in api-hashmap.txt).\n\n3.) Inject individual fields via macro\n\nInstead of injecting a struct hashmap_entry, which implies alignment to sizeof(struct hashmap_entry), we could inject the individual fields, e.g.\n\n #define HASHMAP_ENTRY_HEADER struct hashmap_entry __next; unsinged int __hash;\n\n struct name_entry {\n   HASHMAP_ENTRY_HEADER\n   int namelen;\n   char *name;\n };\n\n\nWhat do you think?\n\nKarsten\n"},{"id":"231791","messageId":"xmqqbo0p2a3x.fsf@gitster.dls.corp.google.com","threadId":"35491","inReplyTo":"52A37D70.3090400@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T17:43:46Z","receivedAt":"2013-12-09T17:43:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karsten Blees <karsten.blees@gmail.com> writes:\n\n> Am 07.12.2013 00:52, schrieb Junio C Hamano:\n>\n>> * kb/doc-exclude-directory-semantics (2013-11-07) 1 commit\n>>  - gitignore.txt: clarify recursive nature of excluded directories\n>> \n>>  Originally merged to 'next' on 2013-11-13\n>> \n>>  Kicked back to 'pu' to replace with a newer reroll ($gmane/237814\n>>  looked OK but there seems to have some loose ends in the\n>>  discussion).\n>\n> I'm unaware of any loose ends, could you clarify?\n>\n> Btw. $gmane/237814 seems to be a different topic, the version in next (and now in pu) was $gmane/237429.\n\nAh, my mistake. I thought I still had $gmane/237416 and needed to\nwait for the discussion to conclude; in fact, a later one in that\nthread $gmane/237429 is what came out of that discussion, so this is\ngood to go, perhaps with an amend with Acked-by: peff.\n\nThanks.\n"},{"id":"231792","messageId":"xmqq7gbd29vw.fsf@gitster.dls.corp.google.com","threadId":"35491","inReplyTo":"52A37D70.3090400@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T17:48:35Z","receivedAt":"2013-12-09T17:48:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karsten Blees <karsten.blees@gmail.com> writes:\n\n>> * kb/fast-hashmap (2013-11-18) 14 commits\n>>   (merged to 'next' on 2013-12-06 at f90be3d) \n>\n> Damn, a day too late :-) I found these two glitches today...is a\n> fixup patch OK or should I do a reroll (or separate patch on top)?\n\nA separate patch on top would be the most appropriate.  People have\nbeen looking at the change since mid November, and nobody noticed\nthe problem; having a separate fix on top is a good way to document\nwhat the specific gotcha that can be easily missed is.\n\nI think the patch you attached describes the issue well, possibly\nwith a retitle (perhaps \"hashmap.h: make sure map entries are\ntightly packed\", or something.)\n\nThanks.\n\n> --- 8< ---\n> Subject: [PATCH] fixup! add a hashtable implementation that supports O(1) removal\n>\n> Use 'unsigned int' for hash-codes everywhere.\n>\n> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste\n> memory on 64-bit systems. This is already documented in api-hashmap.txt,\n> but needs '__attribute__((__packed__))' to work. Reduces e.g.\n>\n>  struct name_entry {\n>      struct hashmap_entry ent;\n>      int namelen;\n>      char *name;\n>  };\n>\n> from 32 to 24 bytes.\n>\n> Signed-off-by: Karsten Blees <blees@dcon.de>\n> ---\n>  hashmap.h | 4 ++--\n>  1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/hashmap.h b/hashmap.h\n> index f5b3b61..b64567b 100644\n> --- a/hashmap.h\n> +++ b/hashmap.h\n> @@ -15,7 +15,7 @@ extern unsigned int memihash(const void *buf, size_t len);\n>  \n>  /* data structures */\n>  \n> -struct hashmap_entry {\n> +struct __attribute__((__packed__)) hashmap_entry {\n>  \tstruct hashmap_entry *next;\n>  \tunsigned int hash;\n>  };\n> @@ -43,7 +43,7 @@ extern void hashmap_free(struct hashmap *map, int free_entries);\n>  \n>  /* hashmap_entry functions */\n>  \n> -static inline void hashmap_entry_init(void *entry, int hash)\n> +static inline void hashmap_entry_init(void *entry, unsigned int hash)\n>  {\n>  \tstruct hashmap_entry *e = entry;\n>  \te->hash = hash;\n"},{"id":"231804","messageId":"20131209200820.GU29959@google.com","threadId":"35491","inReplyTo":"52A5CDB0.2020206@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-12-09T20:08:20Z","receivedAt":"2013-12-09T20:08:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Karsten Blees wrote:\n\n> GCC supports __packed__ as of 2.3 (1992), so any other compilers\n> that copied the __attribute__ feature probably won't complain.\n\nAlas, it looks like HP C doesn't support __packed__ (not that I\ncare much about HP C):\n\n http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#Attributes\n\nMaybe a macro expanding to __attribute__((aligned(1))) on the fields\nwould work?  The same macro could expand to __declspec(align(1)) in\nthe MSVC build.\n\nThanks,\nJonathan\n"},{"id":"231818","messageId":"xmqq4n6hyc2e.fsf@gitster.dls.corp.google.com","threadId":"35491","inReplyTo":"CAMP44s0sankG67rknVo=g5aOJXS_GZBh+hkr9cyVSiYrEvt83Q@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T21:00:25Z","receivedAt":"2013-12-09T21:00:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> To take hostage the whole patch series because of the name\n> --refspec (which is perfectly fine) is just an excuse to not fix\n> the issues already present.\n\nI actually was wondering why you are taking the fixes to the hostage\nto force a wrong option name.\n"},{"id":"231833","messageId":"20131209223345.GB11677@sigill.intra.peff.net","threadId":"35491","inReplyTo":"87ppp8h9ut.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-12-09T22:33:47Z","receivedAt":"2013-12-09T22:33:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 07, 2013 at 06:03:22PM +0100, Thomas Rast wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > * jk/pack-bitmap (2013-11-18) 22 commits\n> [...]\n> Peff can decide if he wants to reroll with my nits or not; either way\n> I'm all for moving it forward and aiming for one of the next releases.\n\nI'm going to be a bit slow this week, as I'm traveling in China.\n\nI have at least one more local fix queued up (one of the re-rolls\nintroduced a use-after-free). Your comments make sense to me, though\nsome of them are \"if this is not too hard\", and I haven't looked yet to\nsee how hard some of the requisite refactoring would be. So expect at\nleast one more re-roll, and I'll try to incorporate your comments.\nThanks for giving it a careful reading.\n\nAs an aside, we have been running the last version sent to the list\n(modulo the fix I mentioned above) on github.com for a week or two\n(previously we were running the old, based-on-v1.8.4 version). So it is\ngetting exercised.\n\n-Peff\n"},{"id":"231835","messageId":"xmqqtxehvdt2.fsf@gitster.dls.corp.google.com","threadId":"35491","inReplyTo":"20131209223345.GB11677@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T22:51:05Z","receivedAt":"2013-12-09T22:51:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sat, Dec 07, 2013 at 06:03:22PM +0100, Thomas Rast wrote:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>> \n>> > * jk/pack-bitmap (2013-11-18) 22 commits\n>> [...]\n>> Peff can decide if he wants to reroll with my nits or not; either way\n>> I'm all for moving it forward and aiming for one of the next releases.\n>\n> I'm going to be a bit slow this week, as I'm traveling in China.\n>\n> I have at least one more local fix queued up (one of the re-rolls\n> introduced a use-after-free). Your comments make sense to me, though\n> some of them are \"if this is not too hard\", and I haven't looked yet to\n> see how hard some of the requisite refactoring would be. So expect at\n> least one more re-roll, and I'll try to incorporate your comments.\n> Thanks for giving it a careful reading.\n>\n> As an aside, we have been running the last version sent to the list\n> (modulo the fix I mentioned above) on github.com for a week or two\n> (previously we were running the old, based-on-v1.8.4 version). So it is\n> getting exercised.\n\n;-).\n"},{"id":"231838","messageId":"52A64FE9.5010004@gmail.com","threadId":"35491","inReplyTo":"20131209200820.GU29959@google.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-09T23:19:05Z","receivedAt":"2013-12-09T23:19:05Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 09.12.2013 21:08, schrieb Jonathan Nieder:\n> Karsten Blees wrote:\n> \n>> GCC supports __packed__ as of 2.3 (1992), so any other compilers\n>> that copied the __attribute__ feature probably won't complain.\n> \n> Alas, it looks like HP C doesn't support __packed__ (not that I\n> care much about HP C):\n> \n>  http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#Attributes\n> \n\nThanks for the link\n\n> Maybe a macro expanding to __attribute__((aligned(1))) on the fields\n> would work?  The same macro could expand to __declspec(align(1)) in\n> the MSVC build.\n> \n\nBut alignment is not the same as packing. We still want the structure to be 8-byte aligned (i.e. variables of the type should start at 8-byte boundaries). We just don't want the size of the structure to be padded to a multiple of 8, so that we can extend it without penalty. (Besides, __attribute__((aligned)) / __declspec(align) can only _increase_ the alignment, so aligned(1) would have no effect).\n\nGoogling some more, I believe the most protable way to achieve this via 'compiler settings' is\n\n #pragma pack(push)\n #pragma pack(4)\n struct hashmap_entry {\n   struct hashmap_entry *next;\n   unsigned int hash;\n };\n #pragma pack(pop)\n\nThis is supported by at least GCC, MSVC and HP (see your link). The downside is that we cannot use macros (in git-compat-util.h) to emit #pragmas. But we wouldn't have to, as compilers aren't supposed to barf on unknown #pragmas.\n\n\nHowever, considering the portability issues, the macro solution (injecting just the two fields instead of a struct) becomes more and more attractive in my mind...\n\nKarsten\n"},{"id":"231842","messageId":"20131209234500.GY29959@google.com","threadId":"35491","inReplyTo":"52A64FE9.5010004@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-12-09T23:45:01Z","receivedAt":"2013-12-09T23:45:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Karsten Blees wrote:\n\n> (Besides, __attribute__((aligned)) / __declspec(align) can only\n> _increase_ the alignment, so aligned(1) would have no effect).\n\nGood catch.\n\n> Googling some more, I believe the most protable way to achieve this\n> via 'compiler settings' is\n>\n>  #pragma pack(push)\n>  #pragma pack(4)\n>  struct hashmap_entry {\n>    struct hashmap_entry *next;\n>    unsigned int hash;\n>  };\n>  #pragma pack(pop)\n>\n> This is supported by at least GCC, MSVC and HP (see your link). The\n> downside is that we cannot use macros (in git-compat-util.h) to emit\n> #pragmas. But we wouldn't have to, as compilers aren't supposed to\n> barf on unknown #pragmas.\n\nTechnically this can be done using macros:\n\n #if (gcc)\n #\tdefine BEGIN_PACKED _Pragma(\"pack(push,4)\")\n #\tdefine END_PACKED _Pragma(\"pack(pop)\")\n #elif (msvc)\n #\tdefine BEGIN_PACKED __pragma(pack(push,4))\n #\tdefine END_PACKED __pragma(pack(pop))\n #else\n \t/* Just tolerate a little padding. */\n #\tdefine BEGIN_PACKED\n #\tdefine END_PACKED\n #end\n\nThen you can do:\n\n BEGIN_PACKED\n struct hashmap_entry {\n \t...\n };\n END_PACKED\n\nWhether that's nicer or uglier than the alternatives I leave to you.\n;-)\n\nThanks,\nJonathan\n"},{"id":"232144","messageId":"52B19EBC.50609@gmail.com","threadId":"35491","inReplyTo":"20131209234500.GY29959@google.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-18T13:10:20Z","receivedAt":"2013-12-18T13:10:20Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 10.12.2013 00:45, schrieb Jonathan Nieder:\n> Karsten Blees wrote:\n> \n>> Googling some more, I believe the most protable way to achieve this\n>> via 'compiler settings' is\n>>\n>>  #pragma pack(push)\n>>  #pragma pack(4)\n>>  struct hashmap_entry {\n>>    struct hashmap_entry *next;\n>>    unsigned int hash;\n>>  };\n>>  #pragma pack(pop)\n>>\n>> This is supported by at least GCC, MSVC and HP (see your link). The\n>> downside is that we cannot use macros (in git-compat-util.h) to emit\n>> #pragmas. But we wouldn't have to, as compilers aren't supposed to\n>> barf on unknown #pragmas.\n> \n> Technically this can be done using macros:\n> \n>  #if (gcc)\n>  #\tdefine BEGIN_PACKED _Pragma(\"pack(push,4)\")\n>  #\tdefine END_PACKED _Pragma(\"pack(pop)\")\n>  #elif (msvc)\n>  #\tdefine BEGIN_PACKED __pragma(pack(push,4))\n>  #\tdefine END_PACKED __pragma(pack(pop))\n>  #else\n>  \t/* Just tolerate a little padding. */\n>  #\tdefine BEGIN_PACKED\n>  #\tdefine END_PACKED\n>  #end\n> \n> Then you can do:\n> \n>  BEGIN_PACKED\n>  struct hashmap_entry {\n>  \t...\n>  };\n>  END_PACKED\n> \n\nSorry for the delay...\n\nMy intention with #pragma pack was to support as many compilers / platforms as possible (even though I can't test them all). From what I could find on the 'net, support for the _Pragma operator is slim. And as the MSVC build is 32-bit only (AFAIK), this is pretty much a GCC-only solution (and thus equivalent, but much more verbose than the initial __attribute__((__packed__)) variant).\n\n> Whether that's nicer or uglier than the alternatives I leave to you.\n> ;-)\n\nIf it was really up to me ( :-) ), I'd like to do this:\n\n------ 8< -------\nSubject: [PATCH] hashmap.h: make sure map entries are tightly packed\n\nExtending 'struct hashmap_entry' with an int-sized member shouldn't waste\nmemory on 64-bit systems. This is already documented in api-hashmap.txt,\nbut struct hashmap_entry needs to be packed for this to work. E.g.\n\n struct name_entry {\n   struct hashmap_entry ent; /* consists of pointer + int */\n   int namelen;\n   char *name;\n };\n\nshould be 24 instead of 32 bytes.\n\nPacking structures is compiler-specific, most compilers support [1]:\n\n #pragma pack(n) - to set structure packing\n #pragma pack()  - to reset structure packing to default\n\nCompilers are supposed to ignore unknown #pragmas, so using this without\nfurther #if <compiler> guards should be safe.\n\nWasting a few bytes for padding is acceptable, however, compiling the rest\nof git with packed structures (and thus mis-aligned arrays of structs) is\nnot. Add a test to ensure that '#pragma pack()' really resets the packing.\n\n[1] Compiler docs regarding #pragma pack:\nhttp://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas\nhttp://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx\nhttp://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#pragma-PACK\nhttp://clang.llvm.org/docs/UsersManual.html#microsoft-extensions\nhttp://uw714doc.sco.com/en/SDK_cprog/_Preprocessing_Directives.html\nhttp://osr507doc.sco.com/en/tools/ANSI_F.3.13_Preprocessing.html\nhttp://docs.oracle.com/cd/E19422-01/819-3690/Pragmas_App.html#73499\nhttp://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Fcompiler%2Fref%2Frnpgpack.htm\n\nSupposedly wants #pragma pack(0) to reset:\nhttp://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/Pragmas/sgi_html/ch04.html\n\nNot supported:\nhttp://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-DD32852C-A0F9-4AC6-BF67-D10D064CC87A.htm\n\nSigned-off-by: Karsten Blees <blees@dcon.de>\n---\n hashmap.h          |  7 +++++++\n t/t0011-hashmap.sh |  6 ++++++\n test-hashmap.c     | 17 +++++++++++++++++\n 3 files changed, 30 insertions(+)\n\ndiff --git a/hashmap.h b/hashmap.h\nindex a816ad4..93b330b 100644\n--- a/hashmap.h\n+++ b/hashmap.h\n@@ -15,10 +15,17 @@ extern unsigned int memihash(const void *buf, size_t len);\n \n /* data structures */\n \n+/*\n+ * Set struct packing to 4 so that we don't waste memory on 64-bit systems.\n+ * Struct hashmap_entry is used as prefix to other (un-packed) structures,\n+ * so this won't cause alignment issues e.g. for odd elements in an array.\n+ */\n+#pragma pack(4)\n struct hashmap_entry {\n \tstruct hashmap_entry *next;\n \tunsigned int hash;\n };\n+#pragma pack()\n \n typedef int (*hashmap_cmp_fn)(const void *entry, const void *entry_or_key,\n \t\tconst void *keydata);\ndiff --git a/t/t0011-hashmap.sh b/t/t0011-hashmap.sh\nindex 391e2b6..3f3c90b 100755\n--- a/t/t0011-hashmap.sh\n+++ b/t/t0011-hashmap.sh\n@@ -237,4 +237,10 @@ test_expect_success 'grow / shrink' '\n \n '\n \n+test_expect_success '\"#pragma pack()\" resets packing to default' '\n+\n+\ttest_hashmap \"pragma-pack\" \"ok\"\n+\n+'\n+\n test_done\ndiff --git a/test-hashmap.c b/test-hashmap.c\nindex f5183fb..2d5a63a 100644\n--- a/test-hashmap.c\n+++ b/test-hashmap.c\n@@ -36,6 +36,12 @@ static struct test_entry *alloc_test_entry(int hash, char *key, int klen,\n \treturn entry;\n }\n \n+struct pointer_int\n+{\n+\tvoid *ptr;\n+\tint i;\n+};\n+\n #define HASH_METHOD_FNV 0\n #define HASH_METHOD_I 1\n #define HASH_METHOD_IDIV10 2\n@@ -136,6 +142,7 @@ static void perf_hashmap(unsigned int method, unsigned int rounds)\n  * remove key -> NULL / old value\n  * iterate -> key1 value1\\nkey2 value2\\n...\n  * size -> tablesize numentries\n+ * pragma-pack -> ok / failure\n  *\n  * perfhashmap method rounds -> test hashmap.[ch] performance\n  */\n@@ -239,6 +246,16 @@ int main(int argc, char *argv[])\n \t\t\t/* print table sizes */\n \t\t\tprintf(\"%u %u\\n\", map.tablesize, map.size);\n \n+\t\t} else if (!strcmp(\"pragma-pack\", cmd)) {\n+\n+\t\t\tif ((sizeof(struct pointer_int) % sizeof(void *)) == 0)\n+\t\t\t\tprintf(\"ok\\n\");\n+\t\t\telse\n+\t\t\t\tprintf(\"sizeof(pointer+int) (%u) is not a \"\n+\t\t\t\t       \"multiple of sizeof(pointer) (%u)!\\n\",\n+\t\t\t\t       sizeof(struct pointer_int),\n+\t\t\t\t       sizeof(void *));\n+\n \t\t} else if (!strcmp(\"perfhashmap\", cmd) && l1 && l2) {\n \n \t\t\tperf_hashmap(atoi(p1), atoi(p2));\n-- \n1.8.5.1.276.g562b27a\n"},{"id":"232146","messageId":"52B1A607.5000509@gmail.com","threadId":"35491","inReplyTo":"xmqq7gbd29vw.fsf@gitster.dls.corp.google.com","subject":"[PATCH] hashmap.h: Use 'unsigned int' for hash-codes everywhere","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-18T13:41:27Z","receivedAt":"2013-12-18T13:41:27Z","isPatch":true,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Signed-off-by: Karsten Blees <blees@dcon.de>\n---\n\nAm 09.12.2013 18:48, schrieb Junio C Hamano:\n> Karsten Blees <karsten.blees@gmail.com> writes:\n> \n>>> * kb/fast-hashmap (2013-11-18) 14 commits\n>>>   (merged to 'next' on 2013-12-06 at f90be3d) \n>>\n>> Damn, a day too late :-) I found these two glitches today...is a\n>> fixup patch OK or should I do a reroll (or separate patch on top)?\n> \n> A separate patch on top would be the most appropriate.\n\nOK, this one's a no-brainer I think. See $gmane/239430 for the latest proposal on the struct packing front.\n\n\n Documentation/technical/api-hashmap.txt | 2 +-\n hashmap.h                               | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/technical/api-hashmap.txt b/Documentation/technical/api-hashmap.txt\nindex b2280f1..42ca234 100644\n--- a/Documentation/technical/api-hashmap.txt\n+++ b/Documentation/technical/api-hashmap.txt\n@@ -80,7 +80,7 @@ prevent expensive resizing. If 0, the table is dynamically resized.\n If `free_entries` is true, each hashmap_entry in the map is freed as well\n (using stdlib's free()).\n \n-`void hashmap_entry_init(void *entry, int hash)`::\n+`void hashmap_entry_init(void *entry, unsigned int hash)`::\n \n \tInitializes a hashmap_entry structure.\n +\ndiff --git a/hashmap.h b/hashmap.h\nindex f5b3b61..a816ad4 100644\n--- a/hashmap.h\n+++ b/hashmap.h\n@@ -43,7 +43,7 @@ extern void hashmap_free(struct hashmap *map, int free_entries);\n \n /* hashmap_entry functions */\n \n-static inline void hashmap_entry_init(void *entry, int hash)\n+static inline void hashmap_entry_init(void *entry, unsigned int hash)\n {\n \tstruct hashmap_entry *e = entry;\n \te->hash = hash;\n-- \n1.8.5.1.276.g562b27a\n"},{"id":"232147","messageId":"52B1AB90.1080800@gmail.com","threadId":"35491","inReplyTo":"52B19EBC.50609@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-18T14:05:04Z","receivedAt":"2013-12-18T14:05:04Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 18.12.2013 14:10, schrieb Karsten Blees:\n> +\t\t\t\tprintf(\"sizeof(pointer+int) (%u) is not a \"\n> +\t\t\t\t       \"multiple of sizeof(pointer) (%u)!\\n\",\n> +\t\t\t\t       sizeof(struct pointer_int),\n> +\t\t\t\t       sizeof(void *));\n\nShould be:\n-\t\t\t\t       sizeof(struct pointer_int),\n-\t\t\t\t       sizeof(void *));\n+\t\t\t\t       (unsigned) sizeof(struct pointer_int),\n+\t\t\t\t       (unsigned) sizeof(void *));\n\n(sizeof() is 'unsigned int' on 32-bit and 'long unsigned int' on 64-bit; without the cast, \"%u\" produces warnings on 64-bit and \"%lu\" on 32-bit...)\n"},{"id":"232149","messageId":"52B1AD66.4000507@gmail.com","threadId":"35491","inReplyTo":"52A5CDB0.2020206@gmail.com","subject":"Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)","fromName":"Karsten Blees","fromEmail":"karsten.blees@gmail.com","sentAt":"2013-12-18T14:12:54Z","receivedAt":"2013-12-18T14:12:54Z","isPatch":false,"sender":{"key":"karsten.blees@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1111200?v=4"},"body":"Am 09.12.2013 15:03, schrieb Karsten Blees:\n> 3.) Inject individual fields via macro\n> \n> Instead of injecting a struct hashmap_entry, which implies alignment to sizeof(struct hashmap_entry), we could inject the individual fields, e.g.\n> \n>  #define HASHMAP_ENTRY_HEADER struct hashmap_entry __next; unsinged int __hash;\n> \n>  struct name_entry {\n>    HASHMAP_ENTRY_HEADER\n>    int namelen;\n>    char *name;\n>  };\n> \n\nI've tried this as well. However, the change is much more intrusive, and produces lots of strict-aliasing warnings in GCC 4.4, probably due to this bug [1]. So I don't think its a good solution. For anyone interested, the patch can be found at [2].\n\n[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032\n[2] https://github.com/kblees/git/commits/kb/hashmap-v5-fixes-macro\n"},{"id":"232175","messageId":"xmqqeh5ajbly.fsf@gitster.dls.corp.google.com","threadId":"35491","inReplyTo":"52B1A607.5000509@gmail.com","subject":"Re: [PATCH] hashmap.h: Use 'unsigned int' for hash-codes everywhere","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-18T17:46:33Z","receivedAt":"2013-12-18T17:46:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karsten Blees <karsten.blees@gmail.com> writes:\n\n> OK, this one's a no-brainer I think. See $gmane/239430 for the\n> latest proposal on the struct packing front.\n\nThanks.\n"}]}