threads / discuss / 35389

What's cooking in git.git (Nov 2013, #05; Thu, 21)

Subject: What's cooking in git.git (Nov 2013, #05; Thu, 21)

## tl;dr

15 messages between Nov 22, 2013 and Nov 25, 2013.

replies: 14people: 6as markdown or json

Junio C Hamano· Nov 22, 2013, 00:19 UTC · lore

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.

Hopefully 1.8.5-rc3 that was tagged on Wednesday will be the final release candidate for this cycle.

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"]

* nd/liteal-pathspecs (2013-10-28) 1 commit
  (merged to 'next' on 2013-11-01 at 1a91775)
 + pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses
 Fixes a regression on 'master' since v1.8.4.

-------------------------------------------------- [New Topics]

* jj/doc-markup-hints-in-coding-guidelines (2013-11-18) 1 commit
  (merged to 'next' on 2013-11-21 at 9c638a6)
 + State correct usage of literal examples in man pages in the coding standards
 Can wait in 'next'.
* jn/perl-lib-extra (2013-11-18) 2 commits
  (merged to 'next' on 2013-11-20 at 8c90afae)
 + Makefile: add PERLLIB_EXTRA variable that adds to default perl path
 + Makefile: rebuild perl scripts when perl paths change
* jj/doc-markup-gitcli (2013-11-20) 1 commit
  (merged to 'next' on 2013-11-21 at 5e49fa8)
 + Documentation/gitcli.txt: fix double quotes
 Can wait in 'next'.
* jk/remove-experimental-loose-object-support (2013-11-21) 1 commit
  (merged to 'next' on 2013-11-21 at d37bab7)
 + drop support for "experimental" loose objects
 Can wait in 'next'.
* jl/commit-v-strip-marker (2013-11-19) 1 commit
 - commit -v: strip diffs and submodule shortlogs from the commit message
 Perhaps another reroll for core.commentChar coming?
* nd/glossary-content-pathspec-markup (2013-11-21) 1 commit
  (merged to 'next' on 2013-11-21 at 6072636)
 + glossary-content.txt: fix documentation of "**" patterns
 Can wait in 'next'.
* nd/magic-pathspec (2013-11-20) 1 commit
  (merged to 'next' on 2013-11-21 at f914a30)
 + diff: restrict pathspec limitations to diff b/f case only
 Can wait in 'next'.

-------------------------------------------------- [Stalled]

* fc/transport-helper-fixes (2013-11-13) 12 commits
 - remote-bzr: support the new 'force' option
 - transport-helper: add support to delete branches
 - fast-export: add support to delete refs
 - fast-import: add support to delete refs
 - transport-helper: add support for old:new refspec
 - fast-export: add new --refspec option
 - fast-export: improve argument parsing
 - test-hg.sh: tests are now expected to pass
 - transport-helper: check for 'forced update' message
 - transport-helper: add 'force' to 'export' helpers
 - transport-helper: don't update refs in dry-run
 - transport-helper: mismerge fix
 Updates transport-helper, fast-import and fast-export to allow the
 ref mapping and ref deletion in a way similar to the natively
 supported transports.
 The option name "--refspec" needs to be rethought. It does not mean
 what refspec usually means, even though it shares the same syntax
 with refspec; calling it --refspec only because it shares the same
 syntax is like calling it --asciistring and does not make sense.
* nv/commit-gpgsign-config (2013-11-06) 1 commit
 - Add the commit.gpgsign option to sign all commits
 Introduce commit.gpgsign configuration variable to force every
 commit to be GPG signed.
 Needs tests, perhaps?
* tb/clone-ssh-with-colon-for-port (2013-11-04) 1 commit
 . git clone: is an URL local or ssh
 Still being reworked.
* cn/thin-push-capability (2013-11-06) 2 commits
 - send-pack: only send a thin pack if the server supports it
 - receive-pack: advertise thin-pack
 Peff had a good suggestion to control this by expressing what the
 receiving end wants in a more direct way, namely to advertise a
 'no-thin' trait in the capability list, which seems to be favored
 by Shawn, too.
* jt/commit-fixes-footer (2013-10-30) 1 commit
 - commit: Add -f, --fixes <commit> option to add Fixes: line
 There is an ongoing discussion around this topic; in general I am
 fairly negative on a new feature that is too narrow and prefer a
 more generic solution that can be tailored for specific needs, as
 many people stated in the thread.
 It appears that the discussion stalled.
* np/pack-v4 (2013-09-18) 90 commits
 . packv4-parse.c: add tree offset caching
 . t1050: replace one instance of show-index with verify-pack
 . index-pack, pack-objects: allow creating .idx v2 with .pack v4
 . unpack-objects: decode v4 trees
 . unpack-objects: allow to save processed bytes to a buffer
 - ...
 Nico and Duy advancing the eternal vaporware pack-v4.  This is here
 primarily for wider distribution of the preview edition.
 Temporarily ejected from 'pu', to try out jk/pack-bitmap, which
 this topic conflicts with.
* jk/pack-bitmap (2013-11-18) 22 commits
 - compat/mingw.h: Fix the MinGW and msvc builds
 - pack-bitmap: implement optional name_hash cache
 - t/perf: add tests for pack bitmaps
 - t: add basic bitmap functionality tests
 - count-objects: recognize .bitmap in garbage-checking
 - repack: consider bitmaps when performing repacks
 - repack: handle optional files created by pack-objects
 - repack: turn exts array into array-of-struct
 - repack: stop using magic number for ARRAY_SIZE(exts)
 - pack-objects: implement bitmap writing
 - rev-list: add bitmap mode to speed up object lists
 - pack-objects: use bitmaps when packing objects
 - pack-bitmap: add support for bitmap indexes
 - documentation: add documentation for the bitmap format
 - ewah: compressed bitmap implementation
 - compat: add endianness helpers
 - sha1_file: export `git_open_noatime`
 - revision: allow setting custom limiter function
 - pack-objects: factor out name_hash
 - pack-objects: refactor the packing list
 - revindex: export new APIs
 - sha1write: make buffer const-correct
 Borrows the bitmap index into packfiles from JGit to speed up
 enumeration of objects involved in a commit range without having to
 fully traverse the history.
* mf/graph-show-root (2013-10-25) 1 commit
 . graph.c: mark root commit differently
 In a repository with multiple-roots, "log --graph", especially with
 "--oneline", does not give the reader enough visual cue to see
 where one line of history ended and a separate history began.
 This is the version that marks the roots 'x' when they would have
 been marked as '*'; Keshav Kini suggested an alternative of giving
 an extra blank line after every root, which I tend to think is a
 better approach to the problem.
* tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits
 - perf-lib: add test_perf_cleanup target
 - perf-lib: split starting the test from the execution
 Add test_perf_cleanup shell function to the perf suite, that allows
 the script writers to define a test with a clean-up action.
 Holding until needed.
* yt/shortened-rename (2013-10-18) 2 commits
 - SQUASH??? style fixes and s/omit/shorten/ where appropriate
 - diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible
 Attempts to give more weight on the fact that a filepair represents
 a rename than showing substring of the actual path when diffstat
 lines are not wide enough.
 I am not sure if that is solving a right problem, though.
* rv/send-email-cache-generated-mid (2013-08-21) 2 commits
 - git-send-email: Cache generated message-ids, use them when prompting
 - git-send-email: add optional 'choices' parameter to the ask sub
* 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
* jc/format-patch (2013-04-22) 2 commits
 - format-patch: --inline-single
 - format-patch: rename "no_inline" field
 A new option to send a single patch to the standard output to be
 appended at the bottom of a message.  I personally have no need for
 this, but it was easy enough to cobble together.  Tests, docs and
 stripping out more MIMEy stuff are left as exercises to interested
 parties.
* jk/gitweb-utf8 (2013-04-08) 4 commits
 - gitweb: Fix broken blob action parameters on blob/commitdiff pages
 - gitweb: Don't append ';js=(0|1)' to external links
 - gitweb: Make feed title valid utf8
 - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch
 Various fixes to gitweb.
 Drew Northup volunteered to take a look into this.
 $gmane/226216
* jc/show-branch (2013-06-07) 5 commits
 - show-branch: use commit slab to represent bitflags of arbitrary width
 - show-branch.c: remove "all_mask"
 - show-branch.c: abstract out "flags" operation
 - show-branch.c: lift all_mask/all_revs to a global static
 - show-branch.c: update comment style
 Waiting for the final step to lift the hard-limit before sending it out.

-------------------------------------------------- [Cooking]

* jj/log-doc (2013-11-13) 2 commits
  (merged to 'next' on 2013-11-21 at cb0ddd2)
 + Documentation/git-log.txt: mark-up fix and minor rephasing
 + Documentation/git-log: update "--log-size" description
 Mark-up fixes.
 Can wait in 'next'.
* jc/bundle (2013-11-12) 1 commit
  (merged to 'next' on 2013-11-21 at 535b046)
 + bundle: use argv-array
 Code clean-up.
 Can wait in 'next'.
* jj/rev-list-options-doc (2013-11-18) 2 commits
  (merged to 'next' on 2013-11-20 at db975de)
 + Documentation/rev-list-options.txt: fix some grammatical issues and typos
 + Documentation/rev-list-options.txt: fix mark-up
 Mark-up and grammo fixes.
 Can wait in 'next'.
* jk/remove-deprecated (2013-11-12) 4 commits
  (merged to 'next' on 2013-11-13 at c324792)
 + peek-remote: remove deprecated alias of ls-remote
 + lost-found: remove deprecated command
 + tar-tree: remove deprecated command
 + repo-config: remove deprecated alias for "git config"
 Will cook in 'next' until a distant future.
* mi/typofixes (2013-11-12) 3 commits
  (merged to 'next' on 2013-11-13 at bb7c2eb)
 + contrib: typofixes
 + Documentation/technical/http-protocol.txt: typofixes
 + typofixes: fix misspelt comments
 Can wait in 'next'.
* rh/remote-hg-bzr-updates (2013-11-18) 9 commits
  (merged to 'next' on 2013-11-20 at a36f3c4)
 + remote-bzr, remote-hg: fix email address regular expression
 + test-hg.sh: help user correlate verbose output with email test
 + test-hg.sh: fix duplicate content strings in author tests
 + test-hg.sh: avoid obsolete 'test' syntax
 + test-hg.sh: eliminate 'local' bashism
 + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple
 + test-bzr.sh, test-hg.sh: allow running from any dir
 + test-lib.sh: convert $TEST_DIRECTORY to an absolute path
 + remote-hg: don't decode UTF-8 paths into Unicode objects
 Can wait in 'next'.
* tr/config-multivalue-lift-max (2013-11-13) 1 commit
  (merged to 'next' on 2013-11-20 at d18aac9)
 + config: arbitrary number of matches for --unset and --replace-all
 Can wait in 'next'.
* kb/doc-exclude-directory-semantics (2013-11-07) 1 commit
  (merged to 'next' on 2013-11-13 at 06e5645)
 + gitignore.txt: clarify recursive nature of excluded directories
 Can wait in 'next'.
* jc/create-directories-microopt (2013-11-11) 1 commit
 - checkout: most of the time we have good leading directories
 Of unknown value until tested on non-Linux platforms (especially
 Windows).
 Will hold.
* jl/submodule-update-retire-orig-flags (2013-11-11) 1 commit
  (merged to 'next' on 2013-11-13 at 4b70d15)
 + submodule update: remove unnecessary orig_flags variable
 Code clean-up.
 Can wait in 'next'.
* jn/mediawiki-makefile-updates (2013-11-11) 4 commits
  (merged to 'next' on 2013-11-13 at 71c8d20)
 + git-remote-mediawiki build: handle DESTDIR/INSTLIBDIR with whitespace
 + git-remote-mediawiki build: make 'install' command configurable
 + git-remote-mediawiki: honor DESTDIR in "make install"
 + git-remote-mediawiki: do not remove installed files in "clean" target
 Build and Installation procedure clean-up.
 Can wait in 'next'.
* tb/doc-fetch-pack-url (2013-11-11) 1 commit
  (merged to 'next' on 2013-11-13 at 90d6832)
 + git-fetch-pack uses URLs like git-fetch
 Can wait in 'next'.
* cc/remote-remove-redundant-postfixcmp (2013-11-06) 2 commits
  (merged to 'next' on 2013-11-06 at 7b45219)
 + Rename suffixcmp() to has_suffix() and invert its result
  (merged to 'next' on 2013-11-04 at 6408502)
 + builtin/remote: remove postfixcmp() and use suffixcmp() instead
 Minor code clean-up.
 Can wait in 'next'.
* nd/wt-status-align-i18n (2013-11-06) 1 commit
  (merged to 'next' on 2013-11-13 at b033aa0)
 + wt-status: take the alignment burden off translators
 An attempt to automatically align the names in the "git status"
 output, taking the display width of (translated) section labels
 into account.
 Can wait in 'next'.
* sb/sha1-loose-object-info-check-existence (2013-11-06) 1 commit
  (merged to 'next' on 2013-11-06 at 1ea5b18)
 + sha1_loose_object_info(): do not return success on missing object
 "git cat-file --batch-check=ok" did not check the existence of the
 named object.
 Will cook in 'next'.
* gj/push-more-verbose-advice (2013-11-13) 2 commits
  (merged to 'next' on 2013-11-21 at df10213)
 + push: switch default from "matching" to "simple"
  (merged to 'next' on 2013-11-21 at 4ee3d4a)
 + push: enhance unspecified push default warning
 Explain 'simple' and 'matching' in "git push" advice message; the
 topmost patch is a rebase of jc/push-2.0-default-to-simple on top
 of it.
 Will cook in 'next'.
 The first one should be merged to 'master' soon after the next
 cycle opens; the other to replace jc/push-2.0-default-to-simple.
* rr/for-each-ref-decoration (2013-11-19) 6 commits
  (merged to 'next' on 2013-11-21 at ee7b0ed)
 + for-each-ref: avoid color leakage
 + for-each-ref: introduce %(color:...) for color
 + for-each-ref: introduce %(upstream:track[short])
 + for-each-ref: introduce %(HEAD) asterisk marker
 + t6300 (for-each-ref): don't hardcode SHA-1 hexes
 + t6300 (for-each-ref): clearly demarcate setup
 Can wait in 'next'.
* jk/two-way-merge-corner-case-fix (2013-11-04) 3 commits
  (merged to 'next' on 2013-11-04 at 79f4fb0)
 + t1005: add test for "read-tree --reset -u A B"
 + t1005: reindent
 + unpack-trees: fix "read-tree -u --reset A B" with conflicted index
 Fix a rather longstanding corner-case bug in twoway "reset to
 there" merge, which is most often seen in "git am --abort".
 Will cook in 'next'.
* jc/ref-excludes (2013-11-01) 5 commits
  (merged to 'next' on 2013-11-04 at fac1ed0)
 + rev-parse: introduce --exclude=<glob> to tame wildcards
 + rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API
 + rev-list --exclude: tests
 + document --exclude option
 + revision: introduce --exclude=<glob> to tame wildcards
 People often wished a way to tell "git log --branches" (and "git
 log --remotes --not --branches") to exclude some local branches
 from the expansion of "--branches" (similarly for "--tags", "--all"
 and "--glob=<pattern>").  Now they have one.
 Can wait in 'next'.
* jk/replace-perl-in-built-scripts (2013-10-29) 1 commit
  (merged to 'next' on 2013-11-01 at 2384e29)
 + use @@PERL@@ in built scripts
 Can wait in 'next'.
* jh/loose-object-dirs-creation-race (2013-10-28) 1 commit
  (merged to 'next' on 2013-11-01 at 3169b0f)
 + sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
 Will cook in 'next'.
* th/reflog-annotated-tag (2013-10-28) 1 commit
  (merged to 'next' on 2013-11-01 at 8b154cc)
 + reflog: handle lightweight and annotated tags equally
 "git log -g $annotated_tag", when there is no reflog history, should
 have produced a single output entry (i.e. the ref creation event),
 but instead showed the history leading to the tag.
 Broken at the design level.  Any reflog entry that points at a non
 commit needs to be handled with new code that does not exist yet,
 and lifting the "this code handles only commits" without adding
 such code does not solve anything.
 Will discard.
* tr/merge-recursive-index-only (2013-10-28) 3 commits
 - merge-recursive: -Xindex-only to leave worktree unchanged
 - merge-recursive: internal flag to avoid touching the worktree
 - merge-recursive: remove dead conditional in update_stages()
 Will hold until using script appears.
* bc/http-100-continue (2013-10-31) 3 commits
  (merged to 'next' on 2013-11-01 at e12ae23)
 + remote-curl: fix large pushes with GSSAPI
 + remote-curl: pass curl slot_results back through run_slot
 + http: return curl's AUTHAVAIL via slot_results
 Issue "100 Continue" responses to help use of GSS-Negotiate
 authentication scheme over HTTP transport when needed.
 Will cook in 'next'.
* jc/merge-base-reflog (2013-10-29) 2 commits
  (merged to 'next' on 2013-11-01 at 6114764)
 + merge-base: teach "--fork-point" mode
 + merge-base: use OPT_CMDMODE and clarify the command line parsing
 Code the logic in "pull --rebase" that figures out a fork point
 from reflog entries in C.
 Will cook in 'next'.
* jk/robustify-parse-commit (2013-10-24) 6 commits
  (merged to 'next' on 2013-11-01 at 2bfbaab)
 + checkout: do not die when leaving broken detached HEAD
 + use parse_commit_or_die instead of custom message
 + use parse_commit_or_die instead of segfaulting
 + assume parse_commit checks for NULL commit
 + assume parse_commit checks commit->object.parsed
 + log_tree_diff: die when we fail to parse a commit
 Will cook in 'next'.
* mh/fetch-tags-in-addition-to-normal-refs (2013-10-30) 23 commits
  (merged to 'next' on 2013-11-06 at 6932893)
 + fetch: improve the error messages emitted for conflicting refspecs
 + handle_duplicate(): mark error message for translation
 + ref_remote_duplicates(): extract a function handle_duplicate()
 + ref_remove_duplicates(): simplify loop logic
 + t5536: new test of refspec conflicts when fetching
 + ref_remove_duplicates(): avoid redundant bisection
 + git-fetch.txt: improve description of tag auto-following
 + fetch-options.txt: simplify ifdef/ifndef/endif usage
 + fetch, remote: properly convey --no-prune options to subprocesses
 + builtin/remote.c:update(): use struct argv_array
 + builtin/remote.c: reorder function definitions
 + query_refspecs(): move some constants out of the loop
 + fetch --prune: prune only based on explicit refspecs
 + fetch --tags: fetch tags *in addition to* other stuff
 + fetch: only opportunistically update references based on command line
 + get_expanded_map(): avoid memory leak
 + get_expanded_map(): add docstring
 + builtin/fetch.c: reorder function definitions
 + get_ref_map(): rename local variables
 + api-remote.txt: correct section "struct refspec"
 + t5510: check that "git fetch --prune --tags" does not prune branches
 + t5510: prepare test refs more straightforwardly
 + t5510: use the correct tag name in test
 The "-tags" option to "git fetch" used to be literally a synonym to
 a "refs/tags/*:refs/tags/*" refspec, which meant that (1) as an
 explicit refspec given from the command line, it silenced the lazy
 "git fetch" default that is configured, and (2) also as an explicit
 refspec given from the command line, it interacted with "--prune"
 to remove any tag that the remote we are fetching from does not
 have.
 This demotes it to an option; with it, we fetch all tags in
 addition to what would be fetched without the option, and it does
 not interact with the decision "--prune" makes to see what
 remote-tracking refs the local has are missing the remote
 counterpart.
 Will cook in 'next'.
* nv/parseopt-opt-arg (2013-10-31) 2 commits
  (merged to 'next' on 2013-11-01 at cd2afd9)
 + rev-parse --parseopt: add the --stuck-long mode
 + Use the word 'stuck' instead of 'sticked'
 Enhance "rev-parse --parseopt" mode to help parsing options with
 an optional parameter.
 Will cook in 'next'.
* ak/submodule-foreach-quoting (2013-09-27) 1 commit
  (merged to 'next' on 2013-10-14 at d77c5f1)
 + submodule foreach: skip eval for more than one argument
 A behavior change, but a worthwhile one: "git submodule foreach"
 was treating its arguments as part of a single command to be
 concatenated and passed to a shell, making writing buggy
 scripts too easy.
 This patch preserves the old "just pass it to the shell" behavior
 when a single argument is passed to 'git submodule foreach' and
 moves to a new "skip the shell and use the arguments passed
 unmolested" behavior when more than one argument is passed.
 The old behavior (always concatenating and passing to the shell)
 was similar to the 'ssh' command, while the new behavior (switching
 on the number of arguments) is what 'xterm -e' does.
 May need more thought to make sure this change is advertised well
 so that scripts that used multiple arguments but added their own
 extra layer of quoting are not broken.
 Will cook in 'next'.
* kb/fast-hashmap (2013-11-18) 14 commits
 - read-cache.c: fix memory leaks caused by removed cache entries
 - builtin/update-index.c: cleanup update_one
 - fix 'git update-index --verbose --again' output
 - remove old hash.[ch] implementation
 - name-hash.c: remove cache entries instead of marking them CE_UNHASHED
 - name-hash.c: use new hash map implementation for cache entries
 - name-hash.c: remove unreferenced directory entries
 - name-hash.c: use new hash map implementation for directories
 - diffcore-rename.c: use new hash map implementation
 - diffcore-rename.c: simplify finding exact renames
 - diffcore-rename.c: move code around to prepare for the next patch
 - buitin/describe.c: use new hash map implementation
 - add a hashtable implementation that supports O(1) removal
 - submodule: don't access the .gitmodules cache entry after removing it
 Improvements to our hash table to get it to meet the needs of the
 msysgit fscache project, with some nice performance improvements.
 The preparatory clean-up to submodule from Jens is at the bottom. I
 also squashed in a fix-up by Karsten found at $gmane/236468 (please
 double-check the result).
* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit
  (merged to 'next' on 2013-10-28 at d8cdf30)
 + git add: -u/-A now affects the entire working tree
 Will cook in 'next' until Git 2.0.
* jc/core-checkstat-2.0 (2013-05-06) 1 commit
  (merged to 'next' on 2013-10-28 at f1bec96)
 + core.statinfo: remove as promised in Git 2.0
 Will cook in 'next' until Git 2.0.
* jc/push-2.0-default-to-simple (2013-06-18) 1 commit
  (merged to 'next' on 2013-10-28 at 3153a9e)
 + push: switch default from "matching" to "simple"
 Will cook in 'next' until Git 2.0.
* jc/add-2.0-ignore-removal (2013-04-22) 1 commit
  (merged to 'next' on 2013-10-28 at 5fd76ec)
 + git add <pathspec>... defaults to "-A"
 Updated endgame for "git add <pathspec>" that defaults to "--all"
 aka "--no-ignore-removal".
 Will cook in 'next' until Git 2.0.
* jc/hold-diff-remove-q-synonym-for-no-deletion (2013-07-19) 1 commit
  (merged to 'next' on 2013-11-01 at 5fc26e4)
 + diff: remove "diff-files -q" in a version of Git in a distant future
 Will cook in 'next' until a distant future.
Jeff King· Nov 22, 2013, 10:23 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Thu, Nov 21, 2013 at 04:19:43PM -0800, Junio C Hamano wrote:
Show 13 quoted lines
> * np/pack-v4 (2013-09-18) 90 commits
>  . packv4-parse.c: add tree offset caching
>  . t1050: replace one instance of show-index with verify-pack
>  . index-pack, pack-objects: allow creating .idx v2 with .pack v4
>  . unpack-objects: decode v4 trees
>  . unpack-objects: allow to save processed bytes to a buffer
>  - ...
> 
>  Nico and Duy advancing the eternal vaporware pack-v4.  This is here
>  primarily for wider distribution of the preview edition.
> 
>  Temporarily ejected from 'pu', to try out jk/pack-bitmap, which
>  this topic conflicts with.

I had a look at the conflicts. Textually, I do not think it is anything too serious; it is mostly a case of adding unrelated lines in the same spot. I am happy to help with resolving that if there is a need.

However, there may be semantic conflicts. The big one I can think of is how packfile reuse interacts with various versions. We only do pack reuse during a --stdout pack to a client. At this point, that means we must be outputting packv2. If we have packv2 on disk, we are fine. If we have packv4 on disk, I guess we simply need to disable reuse, which should not be hard.

Once we start sending packv4 to clients, we'll have to reevaluate. Probably we can just get away with turning off reuse when there is a mismatch, though if my understanding of packv4 is correct, we could still reuse packv2 entries. We can put that off until somebody works on packv4-on-the-wire, though. :)

Show 27 quoted lines
> * jk/pack-bitmap (2013-11-18) 22 commits
>  - compat/mingw.h: Fix the MinGW and msvc builds
>  - pack-bitmap: implement optional name_hash cache
>  - t/perf: add tests for pack bitmaps
>  - t: add basic bitmap functionality tests
>  - count-objects: recognize .bitmap in garbage-checking
>  - repack: consider bitmaps when performing repacks
>  - repack: handle optional files created by pack-objects
>  - repack: turn exts array into array-of-struct
>  - repack: stop using magic number for ARRAY_SIZE(exts)
>  - pack-objects: implement bitmap writing
>  - rev-list: add bitmap mode to speed up object lists
>  - pack-objects: use bitmaps when packing objects
>  - pack-bitmap: add support for bitmap indexes
>  - documentation: add documentation for the bitmap format
>  - ewah: compressed bitmap implementation
>  - compat: add endianness helpers
>  - sha1_file: export `git_open_noatime`
>  - revision: allow setting custom limiter function
>  - pack-objects: factor out name_hash
>  - pack-objects: refactor the packing list
>  - revindex: export new APIs
>  - sha1write: make buffer const-correct
> 
>  Borrows the bitmap index into packfiles from JGit to speed up
>  enumeration of objects involved in a commit range without having to
>  fully traverse the history.

Looks like you picked up my latest re-roll with Ramsay's fix on top. There wasn't a lot of review on this past round (I'm not surprised; it's a dauntingly large chunk to review). I outlined a few possible open issues in the cover letter, but I'd be happy to build those on top, which I think will make review of them a lot easier.

Do we want to try this in 'next' post-1.8.5, or should I try to prod an area expert like Shawn into doing another round of review?

-Peff
Thomas Rast· Nov 22, 2013, 16:52 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Jeff King <peff@peff.net> writes:
>> * jk/pack-bitmap (2013-11-18) 22 commits
[...]
Show 12 quoted lines
>>  Borrows the bitmap index into packfiles from JGit to speed up
>>  enumeration of objects involved in a commit range without having to
>>  fully traverse the history.
>
> Looks like you picked up my latest re-roll with Ramsay's fix on top.
> There wasn't a lot of review on this past round (I'm not surprised; it's
> a dauntingly large chunk to review).  I outlined a few possible open
> issues in the cover letter, but I'd be happy to build those on top,
> which I think will make review of them a lot easier.
>
> Do we want to try this in 'next' post-1.8.5, or should I try to prod an
> area expert like Shawn into doing another round of review?

Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on or responded to my June reviews in this thread:

  http://thread.gmane.org/gmane.comp.version-control.git/228918
and again mentioned here, though I didn't point out all of them:
  http://thread.gmane.org/gmane.comp.version-control.git/236587/focus=236740

Granted, the way I verified this was checking whether you renamed rlw_xor_run_bit() to something more fitting, so perhaps you just forgot that one thing but did all the rest.

-- 
Thomas Rast
tr@thomasrast.ch
Jeff King· Nov 22, 2013, 17:26 UTC · re: Thomas Rast · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Fri, Nov 22, 2013 at 05:52:37PM +0100, Thomas Rast wrote:
Show 17 quoted lines
> > Looks like you picked up my latest re-roll with Ramsay's fix on top.
> > There wasn't a lot of review on this past round (I'm not surprised; it's
> > a dauntingly large chunk to review).  I outlined a few possible open
> > issues in the cover letter, but I'd be happy to build those on top,
> > which I think will make review of them a lot easier.
> >
> > Do we want to try this in 'next' post-1.8.5, or should I try to prod an
> > area expert like Shawn into doing another round of review?
> 
> Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on
> or responded to my June reviews in this thread:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/228918
> 
> and again mentioned here, though I didn't point out all of them:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/236587/focus=236740

Sorry, I didn't respond directly to the email. Vicent did a pass for style and documentation shortly after the initial series, and then I did another pass in the most recent re-roll, adding a C fallback for the gcc builtin. I thought that covered it, but:

> Granted, the way I verified this was checking whether you renamed
> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot
> that one thing but did all the rest.

I didn't touch that. Vicent, did you have a comment on the name (it really does look like it is a negation, and the only caller is ewah_not).

-Peff
Thomas Rast· Nov 22, 2013, 17:58 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Jeff King <peff@peff.net> writes:
>> Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on
>> or responded to my June reviews in this thread:
>> 
>>   http://thread.gmane.org/gmane.comp.version-control.git/228918
[...]
Show 7 quoted lines
>> Granted, the way I verified this was checking whether you renamed
>> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot
>> that one thing but did all the rest.
>
> I didn't touch that. Vicent, did you have a comment on the name (it
> really does look like it is a negation, and the only caller is
> ewah_not).
Hmm, so it really was that one unlucky thing :-)

I don't have much to say on the area, but if you think it helps you I can set aside some time RSN to review the second half of the series, too. Back in June I only looked at the first half.

-- 
Thomas Rast
tr@thomasrast.ch
Jeff King· Nov 22, 2013, 22:36 UTC · re: Thomas Rast · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Fri, Nov 22, 2013 at 06:58:55PM +0100, Thomas Rast wrote:
Show 5 quoted lines
> > I didn't touch that. Vicent, did you have a comment on the name (it
> > really does look like it is a negation, and the only caller is
> > ewah_not).
> 
> Hmm, so it really was that one unlucky thing :-)

I don't promise there is only one unlucky thing. :) Only that we made a good faith effort to address the comments. There were a lot of comments and a lot of re-rolls, and I would not be surprised if something else was missed (I am not thinking of anything in particular, but just preparing you mentally).

> I don't have much to say on the area, but if you think it helps you I
> can set aside some time RSN to review the second half of the series,
> too.  Back in June I only looked at the first half.

I would love that. My comments to Junio were not to rush the topic, but mainly to keep it progressing.

Re-rolling such a big chunk of code _is_ a pain for both me and for reviewers, so I wouldn't mind switching to "fixes on top" instead of re-rolling at some point. But we can do another round or two of re-roll first.

-Peff
Thomas Rast· Nov 22, 2013, 23:04 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Jeff King <peff@peff.net> writes:
> Re-rolling such a big chunk of code _is_ a pain for both me and for
> reviewers, so I wouldn't mind switching to "fixes on top" instead of
> re-rolling at some point. But we can do another round or two of re-roll
> first.

No, actually I think the plan that you sketched in the other side thread sounded nice: give it some exposure in next. I'll still try and read the rest, but that way it hopefully gets (much) more testing.

-- 
Thomas Rast
tr@thomasrast.ch
Vicent Marti· Nov 22, 2013, 19:40 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Fri, Nov 22, 2013 at 6:26 PM, Jeff King <peff@peff.net> wrote:
Show 7 quoted lines
>> Granted, the way I verified this was checking whether you renamed
>> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot
>> that one thing but did all the rest.
>
> I didn't touch that. Vicent, did you have a comment on the name (it
> really does look like it is a negation, and the only caller is
> ewah_not).

Yes, the name was ported straight from the original library and kept as-is to make the translation more straightforward. These sources are --again-- a translation, so I tried to remain as close to the original Java implementation as possible.

I agree the name is not ideal, but it does make quite a bit of sense. It effectively inverts the word based on the run bit, which is the equivalent of xoring it with the bit if it's one.

Love, vmg

Thomas Rast· Nov 22, 2013, 20:16 UTC · re: Vicent Marti · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Vicent Marti <vicent@github.com> writes:
Show 13 quoted lines
> On Fri, Nov 22, 2013 at 6:26 PM, Jeff King <peff@peff.net> wrote:
>> I didn't touch that. Vicent, did you have a comment on the name (it
>> really does look like it is a negation, and the only caller is
>> ewah_not).
>
> Yes, the name was ported straight from the original library and kept
> as-is to make the translation more straightforward. These sources are
> --again-- a translation, so I tried to remain as close to the original
> Java implementation as possible.
>
> I agree the name is not ideal, but it does make quite a bit of sense.
> It effectively inverts the word based on the run bit, which is the
> equivalent of xoring it with the bit if it's one.
It's a funny xor that doesn't take a second argument ;-)

Anyway, let's not argue forever about the choice of this name. It's just the first thing that came to my mind from the original review, so I used it as an indicator to see if you had done something about it. It seems I picked an indicator that is not significant for the overall state.

-- 
Thomas Rast
tr@thomasrast.ch
Junio C Hamano· Nov 22, 2013, 19:36 UTC · re: Jeff King · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> Looks like you picked up my latest re-roll with Ramsay's fix on top.
> There wasn't a lot of review on this past round (I'm not surprised; it's
> a dauntingly large chunk to review).  I outlined a few possible open
> issues in the cover letter, but I'd be happy to build those on top,
> which I think will make review of them a lot easier.
>
> Do we want to try this in 'next' post-1.8.5, or should I try to prod an
> area expert like Shawn into doing another round of review?
Yes ;-).

I recall starting to read the series over and then got sidetracked in the middle and never finishing. I'll try to make time sometime this weekend (we are still buried in boxes after the move, though, so no promises) myself.

How close is this what you guys are running in production these days, by the way?

Vicent Martí· Nov 22, 2013, 19:47 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
>> Do we want to try this in 'next' post-1.8.5, or should I try to prod an
>> area expert like Shawn into doing another round of review?
>
> Yes ;-).
>
> I recall starting to read the series over and then got sidetracked
> in the middle and never finishing.  I'll try to make time sometime
> this weekend (we are still buried in boxes after the move, though,
> so no promises) myself.
>
> How close is this what you guys are running in production these
> days, by the way?

We are running a slightly older version of the patchset, because we're still on 1.8.4 and the current reroll doesn't apply cleanly there.

If this could make it to `next` some time next week, that would work out great for us, because we may start considering using `next` as a partial or full deployment on our production machines

This also means that we could exercise the patchset and everything else that is queued up in next release... You must remember all the corner cases and bugs peff brings to the list every time we deploy a new Git to production. Wouldn't it be nice to have a thorough checking of the current iteration *before* the release, and not after? :)

*hint hint*
Junio C Hamano· Nov 22, 2013, 20:05 UTC · re: Vicent Martí · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Vicent Martí <tanoku@gmail.com> writes:
Show 8 quoted lines
> On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> We are running a slightly older version of the patchset, because we're
> still on 1.8.4 and the current reroll doesn't apply cleanly there.
>
> If this could make it to `next` some time next week, that would work
> out great for us, because we may start considering using `next` as a
> partial or full deployment on our production machines

I do not think potentially incompatible stuff that are slated for 2.0 that have been cooking in 'next' affects the server side, so that may be a good and safe move.

> This also means that we could exercise the patchset and everything
> else that is queued up in next release...

There is no 'next release' though; there is no guarantee what is cooking in 'next' will be in any future release ;-).

In any case, it is nice to see that people from a large hosting site finally taking a hint from my occasional light complaints that come after "thanks for reporting" whenever I see regression and breakage report soon after a topic graduates to 'master' ;-). It is good to see that more people starting to adopt the 'next' branch early for wider testing.

Thanks.
Jeff King· Nov 22, 2013, 22:32 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Fri, Nov 22, 2013 at 12:05:25PM -0800, Junio C Hamano wrote:
Show 7 quoted lines
> > If this could make it to `next` some time next week, that would work
> > out great for us, because we may start considering using `next` as a
> > partial or full deployment on our production machines
> 
> I do not think potentially incompatible stuff that are slated for
> 2.0 that have been cooking in 'next' affects the server side, so
> that may be a good and safe move.

I do not think we will literally run `next` in this case, but probably v1.8.5 + selected topics (like this one :) ).

We do not need to base ourselves on a release, of course, and we may start using a rolling version of master, but choose quiescent points in the cycle (like starting with a release, and then rolling forward around -rc time). I started trying that with this cycle, which is how I found the --literal-pathspec regression in mid-cycle, and then found out the fix hadn't graduated during -rc. :)

If that proves stable, then I will consider bumping up our frequency of following `master`, and then eventually following `next` (possibly with some lag). As a large site, we get to expose the code to a lot of new people; but we also need to be mindful that we are exposing a lot of people to new bugs.

-Peff
Antoine Pelisse· Nov 23, 2013, 11:25 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> * rh/remote-hg-bzr-updates (2013-11-18) 9 commits
>   (merged to 'next' on 2013-11-20 at a36f3c4)
>  + remote-bzr, remote-hg: fix email address regular expression
>  + test-hg.sh: help user correlate verbose output with email test
>  + test-hg.sh: fix duplicate content strings in author tests
>  + test-hg.sh: avoid obsolete 'test' syntax
>  + test-hg.sh: eliminate 'local' bashism
>  + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple
>  + test-bzr.sh, test-hg.sh: allow running from any dir
>  + test-lib.sh: convert $TEST_DIRECTORY to an absolute path
>  + remote-hg: don't decode UTF-8 paths into Unicode objects
>
>  Can wait in 'next'.

Would it be possible to merge the first commit of this series in master (and eventually in maint) ? My commit (11362653: remote-hg: unquote C-style paths when exporting) breaks the remote-hg tests since v1.8.4.3 (sorry about that), and is fixed by this commit. It would be nice to deliver 1.8.5 with working remote-helpers tests.

Cheers, Antoine

Junio C Hamano· Nov 25, 2013, 16:17 UTC · re: Antoine Pelisse · lore

Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)

Antoine Pelisse <apelisse@gmail.com> writes:
Show 21 quoted lines
> On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * rh/remote-hg-bzr-updates (2013-11-18) 9 commits
>>   (merged to 'next' on 2013-11-20 at a36f3c4)
>>  + remote-bzr, remote-hg: fix email address regular expression
>>  + test-hg.sh: help user correlate verbose output with email test
>>  + test-hg.sh: fix duplicate content strings in author tests
>>  + test-hg.sh: avoid obsolete 'test' syntax
>>  + test-hg.sh: eliminate 'local' bashism
>>  + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple
>>  + test-bzr.sh, test-hg.sh: allow running from any dir
>>  + test-lib.sh: convert $TEST_DIRECTORY to an absolute path
>>  + remote-hg: don't decode UTF-8 paths into Unicode objects
>>
>>  Can wait in 'next'.
>
> Would it be possible to merge the first commit of this series in
> master (and eventually in maint) ?
> My commit (11362653: remote-hg: unquote C-style paths when exporting)
> breaks the remote-hg tests since v1.8.4.3 (sorry about that), and is
> fixed by this commit. It would be nice to deliver 1.8.5 with working
> remote-helpers tests.
Surely.  Let's do that.

← back to recent threads