What's cooking in git.git (Apr 2014, #08; Fri, 25)

What's cooking in git.git (Apr 2014, #08; Fri, 25)

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

The tip of the 'master' branch is at v2.0.0-rc1.  Last minute fixes
to newly added code keep flowing in, which is good.

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

* db/make-with-curl (2014-04-15) 2 commits
  (merged to 'next' on 2014-04-16 at b9c8527)
 + Makefile: allow static linking against libcurl
 + Makefile: use curl-config to determine curl flags

 Ask curl-config how to link with the curl library, instead of
 having only a limited configurability knobs in the Makefile.


* fc/transport-helper-sync-error-fix (2014-04-21) 6 commits
  (merged to 'next' on 2014-04-21 at f53a08a)
 + t5801 (remote-helpers): cleanup environment sets
 + transport-helper: fix sync issue on crashes
 + transport-helper: trivial cleanup
 + transport-helper: propagate recvline() error pushing
 + remote-helpers: make recvline return an error
 + transport-helper: remove barely used xchgline()

 Make sure the marks are not written out when the transport helper
 did not finish happily, to avoid marks file that is out of sync
 with the reality.


* jk/pack-bitmap (2014-04-22) 1 commit
  (merged to 'next' on 2014-04-22 at ba58737)
 + ewah_bitmap.c: do not assume size_t and eword_t are the same size

 A last minute (and hopefully the last) fix to avoid coredumps due
 to an incorrect pointer arithmetic.

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

* ep/shell-command-substitution (2014-04-23) 13 commits
 - p5302-pack-index.sh: use the $( ... ) construct for command substitution
 - lib-gpg.sh: use the $( ... ) construct for command substitution
 - lib-cvs.sh: use the $( ... ) construct for command substitution
 - lib-credential.sh: use the $( ... ) construct for command substitution
 - git-web--browse.sh: use the $( ... ) construct for command substitution
 - git-stash.sh: use the $( ... ) construct for command substitution
 - git-rebase.sh: use the $( ... ) construct for command substitution
 - git-rebase--merge.sh: use the $( ... ) construct for command substitution
 - git-pull.sh: use the $( ... ) construct for command substitution
 - appp.sh: use the $( ... ) construct for command substitution
 - t7900-subtree.sh: use the $( ... ) construct for command substitution
 - test-gitmw-lib.sh: use the $( ... ) construct for command substitution
 - t9365-continuing-queries.sh: use the $( ... ) construct for command substitution

 Adjust shell scripts to use $(cmd) instead of `cmd`.

 Will merge to 'next' and keep it there for the remainder of the cycle.


* ib/test-selectively-run (2014-04-23) 3 commits
 - test-lib: '--run' to run only specific tests
 - test-lib: tests skipped by GIT_SKIP_TESTS say so
 - test-lib: Document short options in t/README

 Allow specifying only certain individual test pieces to be run
 using a range notation (e.g. "t1234-test.sh --run='1-4 6 8 9-'").


* mm/mediawiki-encoding-fix (2014-04-23) 2 commits
 - git-remote-mediawiki: fix encoding issue for UTF-8 media files
 - git-remote-mediawiki: allow stop/start-ing the test server

 Will merge to 'next' and keep it there for the remainder of the cycle.


* mw/symlinks (2014-04-24) 1 commit
  (merged to 'next' on 2014-04-25 at 20b2af6)
 + setup: fix windows path buffer over-stepping

 A finishing touch fix to a new change already in 'master'.

 Will merge to 'master' by -rc2.


* sk/tag-contains-wo-recursion (2014-04-25) 1 commit
  (merged to 'next' on 2014-04-25 at f320750)
 + git tag --contains: avoid stack overflow

 Will keep in 'next' for the remainder of the cycle.

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

* rs/ref-transaction (2014-04-22) 14 commits
 . SQUASH???
 . refs.c: change update_ref to use a transaction
 . walker.c: use ref transaction for ref updates
 . branch.c: use ref transaction for all ref updates
 . fast-import.c: change update_branch to use ref transactions
 . sequencer.c: use ref transactions for all ref updates
 . commit.c: use ref transactions for updates
 . replace.c: use the ref transaction functions for updates
 . tag.c: use ref transactions when doing updates
 . refs.c: ref_transaction_delete to check for error and return status
 . refs.c: change ref_transaction_create to do error checking and return status
 . refs.c: change ref_transaction_update() to do error checking and return status
 . refs.c: use a single exit path from transaction commit and handle onerr
 . refs.c: constify the sha arguments for ref_transaction_create|delete|update
 (this branch uses mh/ref-transaction.)

 Updates most of the callsites to write_sha1_ref(), the low-level
 mechanism to update a ref, to use the ref-transaction API.

 Seems to break the dumb walker test (t5550) when merged to 'pu',
 possibly due to misconversion of walker.c.  Kept out of 'pu' as I
 didn't want to resolve conflicts with the other topics only to get
 a known-broken version.


* tr/merge-recursive-index-only (2014-02-05) 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()
 (this branch is used by tr/remerge-diff.)

 Will hold.


* tr/remerge-diff (2014-02-26) 5 commits
 . log --remerge-diff: show what the conflict resolution changed
 . name-hash: allow dir hashing even when !ignore_case
 . merge-recursive: allow storing conflict hunks in index
 . revision: fold all merge diff variants into an enum merge_diff_mode
 . combine-diff: do not pass revs->dense_combined_merges redundantly
 (this branch uses tr/merge-recursive-index-only.)

 "log -p" output learns a new way to let users inspect a merge
 commit by showing the differences between the automerged result
 with conflicts the person who recorded the merge would have seen
 and the final conflict resolution that was recorded in the merge.

 Needs to be rebased, now kb/fast-hashmap topic is in.


* bc/blame-crlf-test (2014-02-18) 1 commit
 - blame: add a failing test for a CRLF issue.

 I have a feeling that a fix for this should be fairly isolated and
 trivial (it should be just the matter of paying attention to the
 crlf settings when synthesizing the fake commit)---perhaps somebody
 can squash in a fix to this?


* jk/makefile (2014-02-05) 16 commits
 - FIXUP
 - move LESS/LV pager environment to Makefile
 - Makefile: teach scripts to include make variables
 - FIXUP
 - Makefile: auto-build C strings from make variables
 - Makefile: drop *_SQ variables
 - FIXUP
 - Makefile: add c-quote helper function
 - Makefile: introduce sq function for shell-quoting
 - Makefile: always create files via make-var
 - Makefile: store GIT-* sentinel files in MAKE/
 - Makefile: prefer printf to echo for GIT-*
 - Makefile: use tempfile/mv strategy for GIT-*
 - Makefile: introduce make-var helper function
 - Makefile: fix git-instaweb dependency on gitweb
 - Makefile: drop USE_GETTEXT_SCHEME from GIT-CFLAGS

 Simplify the Makefile rules and macros that exist primarily for
 quoting purposes, and make it easier to robustly express the
 dependency rules.

 Expecting a reroll.


* po/everyday-doc (2014-01-27) 1 commit
 - Make 'git help everyday' work

 This may make the said command to emit something, but the source is
 not meant to be formatted into a manual pages to begin with, and
 also its contents are a bit stale.  It may be a good first step in
 the right direction, but needs more work to at least get the
 mark-up right before public consumption.

 Will hold.


* jk/branch-at-publish-rebased (2014-01-17) 5 commits
 . t1507 (rev-parse-upstream): fix typo in test title
 . implement @{publish} shorthand
 . branch_get: provide per-branch pushremote pointers
 . branch_get: return early on error
 . sha1_name: refactor upstream_mark

 Give an easier access to the tracking branches from "other" side in
 a triangular workflow by introducing B@{publish} that works in a
 similar way to how B@{upstream} does.

 Meant to be used as a basis for whatever Ram wants to build on.

 Ejected from 'pu' to make room for fc/publish-vs-upstream topic.


* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits
 - merge: drop unused arg from abort_commit method signature
 - merge: make prepare_to_commit responsible for write_merge_state
 - t7505: ensure cleanup after hook blocks merge
 - t7505: add missing &&

 Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
 run during "git merge".  The log message stresses too much on one
 hook, prepare-commit-msg, but it would equally apply to other hooks
 like post-merge, I think.

 Waiting for a reroll.


* jl/submodule-recursive-checkout (2013-12-26) 5 commits
 - Teach checkout to recursively checkout submodules
 - submodule: teach unpack_trees() to update submodules
 - submodule: teach unpack_trees() to repopulate submodules
 - submodule: teach unpack_trees() to remove submodule contents
 - submodule: prepare for recursive checkout of submodules

 An RFCv2 exists ($gmane/241455) with sizable review comments.
 Expecting a reroll.


* jc/graph-post-root-gap (2013-12-30) 3 commits
 - WIP: document what we want at the end
 - graph: remove unused code a bit
 - graph: stuff the current commit into graph->columns[]

 This was primarily a RFH ($gmane/239580).


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

 Needs to be rebased, now the pack-bitmap series is in.


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

 Will hold.


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


* jc/show-branch (2014-03-24) 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]

* fc/remote-helpers-hg-bzr-graduation (2014-04-21) 3 commits
  (merged to 'next' on 2014-04-22 at fed170a)
 + remote-helpers: move tests out of contrib
 + remote-helpers: move out of contrib
 + remote-helpers: squelch python import exceptions

 Move remote-hg and remote-bzr out of contrib/.

 Will keep in 'next' for the remainder of the cycle.


* fc/remote-helper-refmap (2014-04-21) 8 commits
  (merged to 'next' on 2014-04-22 at fb5a4c2)
 + transport-helper: remove unnecessary strbuf resets
 + 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 to push symbolic refs
 + transport-helper: add support for old:new refspec
 + fast-export: add new --refspec option
 + fast-export: improve argument parsing

 Allow remote-helper/fast-import based transport to rename the refs
 while transferring the history.

 Will keep in 'next' for the remainder of the cycle.


* jk/external-diff-use-argv-array (2014-04-21) 6 commits
  (merged to 'next' on 2014-04-22 at e6d92d7)
 + run_external_diff: refactor cmdline setup logic
 + run_external_diff: hoist common bits out of conditional
 + run_external_diff: drop fflush(NULL)
 + run_external_diff: clean up error handling
 + run_external_diff: use an argv_array for the environment
 + run_external_diff: use an argv_array for the command line

 Code clean-up.

 Will keep in 'next' for the remainder of the cycle.


* jx/blame-align-relative-time (2014-04-23) 2 commits
  (merged to 'next' on 2014-04-23 at 858df39)
 + blame: dynamic blame_date_width for different locales
 + blame: fix broken time_buf paddings in relative timestamp

 "git blame" miscounted number of columns needed to show localized
 timestamps, resulting in jaggy left-side-edge of the source code
 lines in its output.

 Will keep in 'next' for the remainder of the cycle.


* fc/merge-default-to-upstream (2014-04-22) 1 commit
  (merged to 'next' on 2014-04-22 at 4f98483)
 + merge: enable defaulttoupstream by default

 "git merge" without argument, even when there is an upstream
 defined for the current branch, refused to run until
 merge.defaultToUpstream is set to true. Flip the default of that
 configuration variable to true.

 Will keep in 'next' for the remainder of the cycle.


* fc/mergetool-prompt (2014-04-24) 2 commits
 - mergetool: document the default for --[no-]prompt
  (merged to 'next' on 2014-04-22 at dcaec94)
 + mergetool: run prompt only if guessed tool

 mergetool.prompt used to default to 'true', always causing a confirmation
 "do you really want to run the tool on this path" to be shown.

 Among the two purposes the prompt serves, ignore the use case to
 confirm that the user wants to view particular path with the named
 tool, and make the prompt only to confirm the choice of the tool
 made by autodetection and defaulting.  For those who configured the
 tool explicitly, the prompt shown for the latter purpose is simply
 annoying.

 Strictly speaking, this is a backward incompatible change and the
 users need to explicitly set the variable to 'true' if they want to
 resurrect the now-ignored use case.

 Will merge to 'next' and keep it there for the remainder of the cycle.


* fc/mergetools-vimdiff3 (2014-04-22) 1 commit
  (merged to 'next' on 2014-04-22 at d843e75)
 + mergetools: add vimdiff3 mode

 Will keep in 'next' for the remainder of the cycle.


* km/git-svn-workaround-older-getopt-long (2014-04-23) 1 commit
  (merged to 'next' on 2014-04-23 at 3f35586)
 + t9117: use --prefix "" instead of --prefix=""

 Will merge to 'master' by -rc2.


* lr/git-run-setup-gently (2014-04-22) 1 commit
  (merged to 'next' on 2014-04-22 at 5c2523f)
 + git.c: treat RUN_SETUP_GENTLY and RUN_SETUP as mutually exclusive

 Will keep in 'next' for the remainder of the cycle.


* mk/doc-git-gui-display-untracked (2014-04-21) 1 commit
  (merged to 'next' on 2014-04-22 at 385d39a)
 + Documentation: git-gui: describe gui.displayuntracked

 Will merge to 'master' by -rc2.


* rh/prompt-pcmode-avoid-eval-on-refname (2014-04-22) 1 commit
  (merged to 'next' on 2014-04-22 at 3a1506f)
 + git-prompt.sh: don't put unsanitized branch names in $PS1

 Will merge to 'master' by -rc2.


* fc/publish-vs-upstream (2014-04-21) 8 commits
 - sha1_name: add support for @{publish} marks
 - sha1_name: simplify track finding
 - sha1_name: cleanup interpret_branch_name()
 - branch: display publish branch
 - push: add --set-publish option
 - branch: add --set-publish-to option
 - Add concept of 'publish' branch
 - t5516 (fetch-push): fix test restoration

 Add branch@{publish}; it seems that this is somewhat different from
 Ram and Peff started working on.  There were many discussion
 messages going back and forth but it does not appear that the
 design issues have been worked out among participants yet.


* jl/git-gui-show-added-submodule-changes (2014-04-15) 1 commit
 - git-gui: show staged submodules regardless of ignore config

 Tentatively queued what I expect to receive via Pat Thoyts.


* jl/gitk-show-added-submodule-changes (2014-04-15) 3 commits
 - gitk: show staged submodules regardless of ignore config
 - gitk: Merge branch 'new' of https://github.com/vnwildman/gitk
 - l10n: Init Vietnamese translation

 Tentatively queued what I expect to receive via Paul Mackerras.


* bg/rebase-off-of-previous-branch (2014-04-16) 1 commit
 - git-rebase: print name of rev when using shorthand

 Teach "git rebase -" to report the concrete name of the branch
 (i.e. the previous one).

 But it stops short and does not do the same for "git rebase @{-1}".
 Expecting a reroll.


* ef/send-email-absolute-path-to-the-command (2014-04-23) 2 commits
  (merged to 'next' on 2014-04-23 at a657e5e)
 + send-email: windows drive prefix (e.g. C:) appears only at the beginning
  (merged to 'next' on 2014-04-21 at 43bebb5)
 + send-email: recognize absolute path on Windows

 Will keep in 'next' for the remainder of the cycle.


* jh/submodule-tests (2014-04-17) 1 commit
 - t7410: 210 tests for various 'git submodule update' scenarios


* rs/ref-update-check-errors-early (2014-04-17) 2 commits
  (merged to 'next' on 2014-04-21 at acc62aa)
 + commit.c: check for lock error and return early
 + sequencer.c: check for lock failure and bail early in fast_forward_to

 Will keep in 'next' for the remainder of the cycle.


* sk/svn-parse-datestamp (2014-04-17) 1 commit
  (merged to 'next' on 2014-04-21 at 5ff519f)
 + SVN.pm::parse_svn_date: allow timestamps with a single-digit hour

 Will keep in 'next' for the remainder of the cycle.


* nd/index-pack-one-fd-per-thread (2014-04-16) 1 commit
  (merged to 'next' on 2014-04-16 at b38d5a9)
 + index-pack: work around thread-unsafe pread()

 Enable threaded index-pack on platforms without thread-unsafe
 pread() emulation.

 Will keep in 'next' for the remainder of the cycle.


* ym/fix-opportunistic-index-update-race (2014-04-10) 2 commits
  (merged to 'next' on 2014-04-16 at cb92f4f)
 + read-cache.c: verify index file before we opportunistically update it
 + wrapper.c: add xpread() similar to xread()

 Read-only operations such as "git status" that internally refreshes
 the index write out the refreshed index to the disk to optimize
 future accesses to the working tree, but this could race with a
 "read-write" operation that modify the index while it is running.
 Detect such a race and avoid overwriting the index.

 Duy raised a good point that we may need to do the same for the
 normal writeout codepath, not just the "opportunistic" update
 codepath.  While that is true, nobody sane would be running two
 simultaneous operations that are clearly write-oriented competing
 with each other against the same index file.  So in that sense that
 can be done as a less urgent follow-up for this topic.

 Will keep in 'next' for the remainder of the cycle.


* jl/status-added-submodule-is-never-ignored (2014-04-07) 2 commits
 - commit -m: commit staged submodules regardless of ignore config
 - status/commit: show staged submodules regardless of ignore config

 There also are a few patches Ronald Weiss and Jens are working on
 polishing around this topic, and a patch from Jens each for gitk
 and git-gui.

 Waiting for the dust to settle until picking them up all.


* mh/lockfile (2014-04-15) 25 commits
 - trim_last_path_elm(): replace last_path_elm()
 - resolve_symlink(): take a strbuf parameter
 - resolve_symlink(): use a strbuf for internal scratch space
 - change lock_file::filename into a strbuf
 - commit_lock_file(): use a strbuf to manage temporary space
 - try_merge_strategy(): use a statically-allocated lock_file object
 - try_merge_strategy(): remove redundant lock_file allocation
 - struct lock_file: declare some fields volatile
 - lockfile: avoid transitory invalid states
 - commit_lock_file(): die() if called for unlocked lockfile object
 - commit_lock_file(): inline temporary variable
 - remove_lock_file(): call rollback_lock_file()
 - lock_file(): exit early if lockfile cannot be opened
 - write_packed_entry_fn(): convert cb_data into a (const int *)
 - prepare_index(): declare return value to be (const char *)
 - delete_ref_loose(): don't muck around in the lock_file's filename
 - cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN
 - lockfile.c: document the various states of lock_file objects
 - lock_file(): always add lock_file object to lock_file_list
 - hold_lock_file_for_append(): release lock on errors
 - lockfile: unlock file if lockfile permissions cannot be adjusted
 - rollback_lock_file(): set fd to -1
 - rollback_lock_file(): do not clear filename redundantly
 - api-lockfile: expand the documentation
 - unable_to_lock_die(): rename function from unable_to_lock_index_die()

 Refactor and fix corner-case bugs in the lockfile API, all looked
 sensible.

 Expecting a reroll.


* mt/patch-id-stable (2014-03-31) 3 commits
  (merged to 'next' on 2014-04-08 at 0188d44)
 + patch-id-test: test --stable and --unstable flags
 + patch-id: document new behaviour
 + patch-id: make it stable against hunk reordering

 Introduce a new way to compute patch-id for a patch that is not
 affected by the order of the paths that appear in the input.

 This changes the generated patch-id unless the users add an extra
 option to their command lines, but I deliberately queued the series
 to 'next' without reverting that compatibility breakage to see if
 people complain.  It could be that we do not have to worry about
 the default flipping at all.  We'll see.

 Will keep in 'next' for the remainder of the cycle.


* mh/ref-transaction (2014-04-07) 27 commits
  (merged to 'next' on 2014-04-16 at a99f84d)
 + ref_transaction_commit(): work with transaction->updates in place
 + struct ref_update: add a type field
 + struct ref_update: add a lock field
 + ref_transaction_commit(): simplify code using temporary variables
 + struct ref_update: store refname as a FLEX_ARRAY
 + struct ref_update: rename field "ref_name" to "refname"
 + refs: remove API function update_refs()
 + update-ref --stdin: reimplement using reference transactions
 + refs: add a concept of a reference transaction
 + update-ref --stdin: harmonize error messages
 + update-ref --stdin: improve the error message for unexpected EOF
 + t1400: test one mistake at a time
 + update-ref --stdin -z: deprecate interpreting the empty string as zeros
 + update-ref.c: extract a new function, parse_next_sha1()
 + t1400: test that stdin -z update treats empty <newvalue> as zeros
 + update-ref --stdin: simplify error messages for missing oldvalues
 + update-ref --stdin: make error messages more consistent
 + update-ref --stdin: improve error messages for invalid values
 + update-ref.c: extract a new function, parse_refname()
 + parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice
 + update-ref --stdin: read the whole input at once
 + update_refs(): fix constness
 + refs.h: rename the action_on_err constants
 + t1400: add some more tests involving quoted arguments
 + parse_arg(): really test that argument is properly terminated
 + t1400: provide more usual input to the command
 + t1400: fix name and expected result of one test
 (this branch is used by rs/ref-transaction.)

 Update "update-ref --stdin [-z]" and then introduce a transactional
 support for (multi-)reference updates.

 Will keep in 'next' for the remainder of the cycle.


* jc/apply-ignore-whitespace (2014-03-26) 1 commit
  (merged to 'next' on 2014-04-04 at 53779a7)
 + apply --ignore-space-change: lines with and without leading whitespaces do not match

 "--ignore-space-change" option of "git apply" ignored the
 spaces at the beginning of line too aggressively, which is
 inconsistent with the option of the same name "diff" and "git diff"
 have.

 Will keep in 'next' for the remainder of the cycle.


* as/grep-fullname-config (2014-03-20) 1 commit
  (merged to 'next' on 2014-03-28 at 810a076)
 + grep: add grep.fullName config variable

 Add a configuration variable to force --full-name to be default for
 "git grep".

 This may cause regressions on scripted users that do not expect
 this new behaviour.

 Will keep in 'next' for the remainder of the cycle.


* nd/multiple-work-trees (2014-03-25) 28 commits
 - count-objects: report unused files in $GIT_DIR/repos/...
 - gc: support prune --repos
 - gc: style change -- no SP before closing bracket
 - prune: strategies for linked checkouts
 - checkout: detach if the branch is already checked out elsewhere
 - checkout: clean up half-prepared directories in --to mode
 - checkout: support checking out into a new working directory
 - use new wrapper write_file() for simple file writing
 - wrapper.c: wrapper to open a file, fprintf then close
 - setup.c: support multi-checkout repo setup
 - setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
 - setup.c: convert check_repository_format_gently to use strbuf
 - setup.c: detect $GIT_COMMON_DIR in is_git_directory()
 - setup.c: convert is_git_directory() to use strbuf
 - git-stash: avoid hardcoding $GIT_DIR/logs/....
 - *.sh: avoid hardcoding $GIT_DIR/hooks/...
 - git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
 - $GIT_COMMON_DIR: a new environment variable
 - commit: use SEQ_DIR instead of hardcoding "sequencer"
 - fast-import: use git_path() for accessing .git dir instead of get_git_dir()
 - reflog: avoid constructing .lock path with git_path
 - *.sh: respect $GIT_INDEX_FILE
 - git_path(): be aware of file relocation in $GIT_DIR
 - path.c: group git_path(), git_pathdup() and strbuf_git_path() together
 - path.c: rename vsnpath() to do_git_path()
 - git_snpath(): retire and replace with strbuf_git_path()
 - path.c: make get_pathname() call sites return const char *
 - path.c: make get_pathname() return strbuf instead of static buffer

 A replacement for contrib/workdir/git-new-workdir that does not
 rely on symbolic links and make sharing of objects and refs safer
 by making the borrowee and borrowers aware of each other.

 Will hold.


* ks/tree-diff-nway (2014-04-09) 20 commits
  (merged to 'next' on 2014-04-09 at c17228e)
 + mingw: activate alloca
  (merged to 'next' on 2014-04-08 at 6b74773)
 + combine-diff: speed it up, by using multiparent diff tree-walker directly
 + tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
 + Portable alloca for Git
  (merged to 'next' on 2014-03-31 at 16a7bd4)
 + tree-diff: reuse base str(buf) memory on sub-tree recursion
 + tree-diff: no need to call "full" diff_tree_sha1 from show_path()
 + tree-diff: rework diff_tree interface to be sha1 based
 + tree-diff: diff_tree() should now be static
 + tree-diff: remove special-case diff-emitting code for empty-tree cases
  (merged to 'next' on 2014-03-25 at cfcbdac)
 + tree-diff: simplify tree_entry_pathcmp
 + tree-diff: show_path prototype is not needed anymore
 + tree-diff: rename compare_tree_entry -> tree_entry_pathcmp
 + tree-diff: move all action-taking code out of compare_tree_entry()
 + tree-diff: don't assume compare_tree_entry() returns -1,0,1
  (merged to 'next' on 2014-03-21 at d872679)
 + tree-diff: consolidate code for emitting diffs and recursion in one place
 + tree-diff: show_tree() is not needed
 + tree-diff: no need to pass match to skip_uninteresting()
 + tree-diff: no need to manually verify that there is no mode change for a path
 + combine-diff: move changed-paths scanning logic into its own function
 + combine-diff: move show_log_first logic/action out of paths scanning

 Instead of running N pair-wise diff-trees when inspecting a
 N-parent merge, find the set of paths that were touched by walking
 N+1 trees in parallel.  These set of paths can then be turned into
 N pair-wise diff-tree results to be processed through rename
 detections and such.  And N=2 case nicely degenerates to the usual
 2-way diff-tree, which is very nice.

 Will keep in 'next' for the remainder of the cycle.


* cc/interpret-trailers (2014-04-07) 12 commits
 - trailer: add blank line before the trailers if needed
 - Documentation: add documentation for 'git interpret-trailers'
 - trailer: add tests for commands in config file
 - trailer: execute command from 'trailer.<name>.command'
 - trailer: add tests for "git interpret-trailers"
 - trailer: add interpret-trailers command
 - trailer: put all the processing together and print
 - trailer: parse trailers from stdin
 - trailer: process command line trailer arguments
 - trailer: read and process config information
 - trailer: process trailers from stdin and arguments
 - trailer: add data structures and basic functions

 A new filter to programatically edit the tail end of the commit log
 messages.

 I was planning to merge it to 'next' and keep it there for the
 remainder of the cycle, but it appears that there still will be
 another round of reroll, at least for the documentation?

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Jeff King]

On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:

> * jk/external-diff-use-argv-array (2014-04-21) 6 commits
>   (merged to 'next' on 2014-04-22 at e6d92d7)
>  + run_external_diff: refactor cmdline setup logic
>  + run_external_diff: hoist common bits out of conditional
>  + run_external_diff: drop fflush(NULL)
>  + run_external_diff: clean up error handling
>  + run_external_diff: use an argv_array for the environment
>  + run_external_diff: use an argv_array for the command line
> 
>  Code clean-up.
> 
>  Will keep in 'next' for the remainder of the cycle.

The first one does fix a possible stack overflow (albeit of one NULL,
not arbitrary content, so I don't think it's exploitable). We may want
to do:

diff --git a/diff.c b/diff.c
index 54d5308..a03744b 100644
--- a/diff.c
+++ b/diff.c
@@ -2894,7 +2894,7 @@ static void run_external_diff(const char *pgm,
 			      int complete_rewrite,
 			      struct diff_options *o)
 {
-	const char *spawn_arg[10];
+	const char *spawn_arg[11];
 	int retval;
 	const char **arg = &spawn_arg[0];
 	struct diff_queue_struct *q = &diff_queued_diff;

as a fix for maint/2.0.0 in the interim. I can write a commit message
for that if you're interested.

> * fc/publish-vs-upstream (2014-04-21) 8 commits
>  - sha1_name: add support for @{publish} marks
>  - sha1_name: simplify track finding
>  - sha1_name: cleanup interpret_branch_name()
>  - branch: display publish branch
>  - push: add --set-publish option
>  - branch: add --set-publish-to option
>  - Add concept of 'publish' branch
>  - t5516 (fetch-push): fix test restoration
> 
>  Add branch@{publish}; it seems that this is somewhat different from
>  Ram and Peff started working on.  There were many discussion
>  messages going back and forth but it does not appear that the
>  design issues have been worked out among participants yet.

If you are waiting on me, I do not have much else to say on this topic.
@{publish} as specified by Felipe is not useful to me, and I would
continue to pursue @{push} separately as "the remote-tracking branch of
where you would push to". I think there is room for both concepts.

As for the patches themselves, I have not reviewed them carefully, and
would prefer not to. As I mentioned before, though, I would prefer the
short "@{p}" not be taken for @{publish} until it has proven itself.

-Peff

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Felipe Contreras]

Jeff King wrote:
> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:

> > * fc/publish-vs-upstream (2014-04-21) 8 commits
> >  - sha1_name: add support for @{publish} marks
> >  - sha1_name: simplify track finding
> >  - sha1_name: cleanup interpret_branch_name()
> >  - branch: display publish branch
> >  - push: add --set-publish option
> >  - branch: add --set-publish-to option
> >  - Add concept of 'publish' branch
> >  - t5516 (fetch-push): fix test restoration
> > 
> >  Add branch@{publish}; it seems that this is somewhat different from
> >  Ram and Peff started working on.  There were many discussion
> >  messages going back and forth but it does not appear that the
> >  design issues have been worked out among participants yet.
> 
> If you are waiting on me, I do not have much else to say on this topic.
> @{publish} as specified by Felipe is not useful to me, and I would
> continue to pursue @{push} separately as "the remote-tracking branch of
> where you would push to". I think there is room for both concepts.
> 
> As for the patches themselves, I have not reviewed them carefully, and
> would prefer not to. As I mentioned before, though, I would prefer the
> short "@{p}" not be taken for @{publish} until it has proven itself.

Presumably you want to save it for @{push}. While I'm not against to having
just @{publish} for now, I'm farily certain most people would be using
@{publish} and not @{push}, as that's what `git branch -v` would show, and it
would be closely similar to @{upstream}. Therefore it would make sense to use
@{p} for @{publish}

-- 
Felipe Contreras

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Alex Davidson]

On Fri, 2014-04-25 at 20:36 -0500, Felipe Contreras wrote:
> Jeff King wrote:
> > If you are waiting on me, I do not have much else to say on this topic.
> > @{publish} as specified by Felipe is not useful to me, and I would
> > continue to pursue @{push} separately as "the remote-tracking branch of
> > where you would push to". I think there is room for both concepts.
> > 
> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
> 
> Presumably you want to save it for @{push}. While I'm not against to having
> just @{publish} for now, I'm farily certain most people would be using
> @{publish} and not @{push}, as that's what `git branch -v` would show, and it
> would be closely similar to @{upstream}. Therefore it would make sense to use
> @{p} for @{publish}

TL;DR: Presumably you want to grab it for @{publish} without evidence to
support a decision either way. 


The thing with shortened forms and abbreviations is that they assume a
mode of thought. Human communication assumes a lot of shared context,
hence the disconnect between code (explicit) and intent (often dependent
on context of conversation). Abbreviation is a form of compression using
context as an implied key.

Users who do not share your context will not find your abbreviation
intuitive. If a consensus context cannot be identified, abbreviation may
be interpreted as an attempt to impose a context. In other words, 'of
the many valid workflows enabled by git we obviously prefer this one
because we have provided more shortcuts for it'.

Attempts to impose context are not unreasonably perceived as political.

Saying that you are 'fairly certain' that most people would be using A
over B 'and therefore' we should support A smacks of political
manoeuvring rather than scientific experimentation.

The scientific approach is to provide both long options and record how
they are used, rather than gravitating towards an abbreviation of a
preferred option which may receive limited use.

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Felipe Contreras]

Alex Davidson wrote:
> On Fri, 2014-04-25 at 20:36 -0500, Felipe Contreras wrote:
> > Jeff King wrote:
> > > If you are waiting on me, I do not have much else to say on this topic.
> > > @{publish} as specified by Felipe is not useful to me, and I would
> > > continue to pursue @{push} separately as "the remote-tracking branch of
> > > where you would push to". I think there is room for both concepts.
> > > 
> > > As for the patches themselves, I have not reviewed them carefully, and
> > > would prefer not to. As I mentioned before, though, I would prefer the
> > > short "@{p}" not be taken for @{publish} until it has proven itself.
> > 
> > Presumably you want to save it for @{push}. While I'm not against to having
> > just @{publish} for now, I'm farily certain most people would be using
> > @{publish} and not @{push}, as that's what `git branch -v` would show, and it
> > would be closely similar to @{upstream}. Therefore it would make sense to use
> > @{p} for @{publish}
> 
> TL;DR: Presumably you want to grab it for @{publish} without evidence to
> support a decision either way. 

The reasons why @{publish} will be useful have been documented and explained
already multiple times.

> The thing with shortened forms and abbreviations is that they assume a
> mode of thought. Human communication assumes a lot of shared context,
> hence the disconnect between code (explicit) and intent (often dependent
> on context of conversation). Abbreviation is a form of compression using
> context as an implied key.
> 
> Users who do not share your context will not find your abbreviation
> intuitive. If a consensus context cannot be identified, abbreviation may
> be interpreted as an attempt to impose a context. In other words, 'of
> the many valid workflows enabled by git we obviously prefer this one
> because we have provided more shortcuts for it'.
> 
> Attempts to impose context are not unreasonably perceived as political.
> 
> Saying that you are 'fairly certain' that most people would be using A
> over B 'and therefore' we should support A smacks of political
> manoeuvring rather than scientific experimentation.

That is not political. Political would be if I gathered support from other
developers and said "more of us prefer this". This is not what I'm doing.

My conclusion is based on logic and reason, which are the bedstone of science.
You can make sensible decisions based on that alone, and in fact that's how
most good decisions are made.

-- 
Felipe Contreras

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Philip Oakley]

From: "Felipe Contreras" <felipe.contreras@gmail.com>
>
> My conclusion is based on logic and reason,

you forget  "And repeatable measurement / evidence" ....

>                                                                  which 
> are the bedstone of science.
> You can make sensible decisions based on that alone, and in fact 
> that's how
> most good decisions are made.
>
> -- 
> Felipe Contreras
> --

At the moment we are missing the repeatable measurements, which can't 
happened until the @{publish}, and others, have been released and used 
for a while[1], otherwise we [prematurely] are back to one size fits all 
solutions.

I suspect your solution may become the lead candidate for @{p}, but as 
they say, "making predictions is hard, especially about the future".

regards

Philip

[1] we don't have a good measurement technique for existing usage 
frequencies (as typed by real users in real life, weighted by user type, 
...) either! 

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Felipe Contreras]

Philip Oakley wrote:
> From: "Felipe Contreras" <felipe.contreras@gmail.com>
> > are the bedstone of science.  You can make sensible decisions based on that
> > alone, and in fact that's how most good decisions are made.
> 
> At the moment we are missing the repeatable measurements,

Sure, that's part of science, but my point is that most decisions can be made
without those, simply on logic and evidence. If you really want to be certain
we can wait, but you know where my money is.

> I suspect your solution may become the lead candidate for @{p}, but as they
> say, "making predictions is hard, especially about the future".

Making predictions is not hard, it's making predictions that turn out to be
true :) And personally I don't find it that hard; you have to pick your battles
though, and this is an easy one.

-- 
Felipe Contreras

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Jeff King]

On Fri, Apr 25, 2014 at 08:36:55PM -0500, Felipe Contreras wrote:

> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
> 
> Presumably you want to save it for @{push}. While I'm not against to having
> just @{publish} for now, I'm farily certain most people would be using
> @{publish} and not @{push}, as that's what `git branch -v` would show, and it
> would be closely similar to @{upstream}. Therefore it would make sense to use
> @{p} for @{publish}

No, I do not think it would be a good idea for @{push}, either. If we
have two concepts so similarly named (and especially if we add @{pull},
which has also been mentioned), then I think having @{p} just adds to
confusion. So I would much rather wait and see.  It is very easy to add
@{p} later, but it is very hard to take it back once used.

-Peff

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
>
>> * jk/external-diff-use-argv-array (2014-04-21) 6 commits
>>   (merged to 'next' on 2014-04-22 at e6d92d7)
>>  + run_external_diff: refactor cmdline setup logic
>>  + run_external_diff: hoist common bits out of conditional
>>  + run_external_diff: drop fflush(NULL)
>>  + run_external_diff: clean up error handling
>>  + run_external_diff: use an argv_array for the environment
>>  + run_external_diff: use an argv_array for the command line
>> 
>>  Code clean-up.
>> 
>>  Will keep in 'next' for the remainder of the cycle.
>
> The first one does fix a possible stack overflow (albeit of one NULL,
> not arbitrary content, so I don't think it's exploitable). We may want
> to do:
>
> diff --git a/diff.c b/diff.c
> index 54d5308..a03744b 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2894,7 +2894,7 @@ static void run_external_diff(const char *pgm,
>  			      int complete_rewrite,
>  			      struct diff_options *o)
>  {
> -	const char *spawn_arg[10];
> +	const char *spawn_arg[11];
>  	int retval;
>  	const char **arg = &spawn_arg[0];
>  	struct diff_queue_struct *q = &diff_queued_diff;
>
> as a fix for maint/2.0.0 in the interim. I can write a commit message
> for that if you're interested.

I think we should merge the first one (and possibly the second one,
too) as-is for 2.0 instead.  No change can possibly be more
trivially correct than these two ;-)

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Jeff King]

On Mon, Apr 28, 2014 at 10:48:21AM -0700, Junio C Hamano wrote:

> > diff --git a/diff.c b/diff.c
> > index 54d5308..a03744b 100644
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -2894,7 +2894,7 @@ static void run_external_diff(const char *pgm,
> >  			      int complete_rewrite,
> >  			      struct diff_options *o)
> >  {
> > -	const char *spawn_arg[10];
> > +	const char *spawn_arg[11];
> >  	int retval;
> >  	const char **arg = &spawn_arg[0];
> >  	struct diff_queue_struct *q = &diff_queued_diff;
> >
> > as a fix for maint/2.0.0 in the interim. I can write a commit message
> > for that if you're interested.
> 
> I think we should merge the first one (and possibly the second one,
> too) as-is for 2.0 instead.  No change can possibly be more
> trivially correct than these two ;-)

I'm fine with that. The second patch is pure clean-up and doesn't fix
anything (because the "3" in the env array is actually correct), so it
can happily wait for the next cycle.

-Peff

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Michael Haggerty]

On 04/26/2014 01:19 AM, Jeff King wrote:
> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> [...]
>> * fc/publish-vs-upstream (2014-04-21) 8 commits
>>  - sha1_name: add support for @{publish} marks
>>  - sha1_name: simplify track finding
>>  - sha1_name: cleanup interpret_branch_name()
>>  - branch: display publish branch
>>  - push: add --set-publish option
>>  - branch: add --set-publish-to option
>>  - Add concept of 'publish' branch
>>  - t5516 (fetch-push): fix test restoration
>>
>>  Add branch@{publish}; it seems that this is somewhat different from
>>  Ram and Peff started working on.  There were many discussion
>>  messages going back and forth but it does not appear that the
>>  design issues have been worked out among participants yet.
> 
> [...]
> As for the patches themselves, I have not reviewed them carefully, and
> would prefer not to. As I mentioned before, though, I would prefer the
> short "@{p}" not be taken for @{publish} until it has proven itself.

Is it too late and/or impossible to think of a different name for either
"push" or "publish" so that their single-letter abbreviations don't
coincide?

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Felipe Contreras]

Michael Haggerty wrote:
> On 04/26/2014 01:19 AM, Jeff King wrote:
> > On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> > [...]
> >> * fc/publish-vs-upstream (2014-04-21) 8 commits
> >>  - sha1_name: add support for @{publish} marks
> >>  - sha1_name: simplify track finding
> >>  - sha1_name: cleanup interpret_branch_name()
> >>  - branch: display publish branch
> >>  - push: add --set-publish option
> >>  - branch: add --set-publish-to option
> >>  - Add concept of 'publish' branch
> >>  - t5516 (fetch-push): fix test restoration
> >>
> >>  Add branch@{publish}; it seems that this is somewhat different from
> >>  Ram and Peff started working on.  There were many discussion
> >>  messages going back and forth but it does not appear that the
> >>  design issues have been worked out among participants yet.
> > 
> > [...]
> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
> 
> Is it too late and/or impossible to think of a different name for either
> "push" or "publish" so that their single-letter abbreviations don't
> coincide?

I'd say given the fact that this has been in the works for a long long
tie and nobody has proposed a better name. Yes.

One reason I think @{p} makes sense for publish is:

  % git push -u, @{u}, @{upstream}
  % git push -p, @{p}, @{publish}

-- 
Felipe Contreras

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Philip Oakley]

From: "Michael Haggerty" <mhagger@alum.mit.edu>
> On 04/26/2014 01:19 AM, Jeff King wrote:
>> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
>> [...]
>>> * fc/publish-vs-upstream (2014-04-21) 8 commits
>>>  - sha1_name: add support for @{publish} marks
>>>  - sha1_name: simplify track finding
>>>  - sha1_name: cleanup interpret_branch_name()
>>>  - branch: display publish branch
>>>  - push: add --set-publish option
>>>  - branch: add --set-publish-to option
>>>  - Add concept of 'publish' branch
>>>  - t5516 (fetch-push): fix test restoration
>>>
>>>  Add branch@{publish}; it seems that this is somewhat different from
>>>  Ram and Peff started working on.  There were many discussion
>>>  messages going back and forth but it does not appear that the
>>>  design issues have been worked out among participants yet.
>>
>> [...]
>> As for the patches themselves, I have not reviewed them carefully, 
>> and
>> would prefer not to. As I mentioned before, though, I would prefer 
>> the
>> short "@{p}" not be taken for @{publish} until it has proven itself.
>
> Is it too late and/or impossible to think of a different name for 
> either
> "push" or "publish" so that their single-letter abbreviations don't
> coincide?

I'd initially grated against the 'publish' name. I didn't feel as that 
what I'd be pushing would be publish-worthy in the sense that when a 
book is published it's also edited before release, unless 
vanity-published.

For a basic triangular flow where the user is simply using a remote 
server as a sort of backup (e.g. github) then I thought that "self" may 
a suitable name, though it does feel too much of a specific case.

Part of the problem is that the DVCS style is new so there isn't a good 
word for 'the other side of the river', that's neither upstream, nor 
downstream, but a ferry crossing to another safe harbour.

I'm now sort of OK with push and publish being the same thing.

--
Philip
£0.02p 

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Jeff King]

On Fri, May 09, 2014 at 06:53:32PM +0200, Michael Haggerty wrote:

> On 04/26/2014 01:19 AM, Jeff King wrote:
> > On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> > [...]
> >> * fc/publish-vs-upstream (2014-04-21) 8 commits
> >>  - sha1_name: add support for @{publish} marks
> >>  - sha1_name: simplify track finding
> >>  - sha1_name: cleanup interpret_branch_name()
> >>  - branch: display publish branch
> >>  - push: add --set-publish option
> >>  - branch: add --set-publish-to option
> >>  - Add concept of 'publish' branch
> >>  - t5516 (fetch-push): fix test restoration
> >>
> >>  Add branch@{publish}; it seems that this is somewhat different from
> >>  Ram and Peff started working on.  There were many discussion
> >>  messages going back and forth but it does not appear that the
> >>  design issues have been worked out among participants yet.
> > 
> > [...]
> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
> 
> Is it too late and/or impossible to think of a different name for either
> "push" or "publish" so that their single-letter abbreviations don't
> coincide?

I don't think it is too late, as nothing has even made it to "master"
(and even once shipped, we can add an alias with a different name,
advertise that, and use its shorthand).

However, I am not sure if that is a good approach. New terms might not
collide in single-letters, but their full names might also not be as
descriptive. We'd have to judge actual proposals to see.

In addition, there was a discussion about having "pull" as an opposite
of "push" (which would make it an alias for "upstream"), that would also
collide. So there is a potential third name to deal with.

-Peff