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

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

[Junio C Hamano]

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.

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

[Jeff King]

On Thu, Nov 21, 2013 at 04:19:43PM -0800, Junio C Hamano wrote:

> * 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. :)

> * 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

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

[Thomas Rast]

Jeff King <peff@peff.net> writes:

>> * jk/pack-bitmap (2013-11-18) 22 commits
[...]
>>  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

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

[Jeff King]

On Fri, Nov 22, 2013 at 05:52:37PM +0100, Thomas Rast wrote:

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

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

[Thomas Rast]

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
[...]
>> 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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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?

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

[Vicent Marti]

On Fri, Nov 22, 2013 at 6:26 PM, Jeff King <peff@peff.net> wrote:
>> 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

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

[Vicent Martí]

On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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*

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

[Junio C Hamano]

Vicent Martí <tanoku@gmail.com> writes:

> 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.

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

[Thomas Rast]

Vicent Marti <vicent@github.com> writes:

> 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

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

[Jeff King]

On Fri, Nov 22, 2013 at 12:05:25PM -0800, Junio C Hamano wrote:

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

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

[Jeff King]

On Fri, Nov 22, 2013 at 06:58:55PM +0100, Thomas Rast 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).
> 
> 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

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

[Thomas Rast]

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

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

[Antoine Pelisse]

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.

Cheers,
Antoine

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

[Junio C Hamano]

Antoine Pelisse <apelisse@gmail.com> writes:

> 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.