[ANNOUNCE] Git v2.8.0-rc2

[ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

A release candidate Git v2.8.0-rc2 is now available for testing
at the usual places.  It is comprised of 459 non-merge commits
since v2.7.0, contributed by 60 people, 19 of which are new faces.

The tarballs are found at:

    https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the
'v2.8.0-rc2' tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.7.0 are as follows.
Welcome to the Git development community!

  마누엘, Andrew Wheeler, Changwoo Ryu, Christoph Egger,
  Dan Aloni, Dave Ware, David A. Wheeler, Dickson Wong, Felipe
  Gonçalves Assis, GyuYong Jung, Jon Griffiths, Kazutoshi Satoda,
  Lars Vogel, Martin Amdisen, Matthew Kraai, Paul Wagland, Rob
  Mayoff, Romain Picard, and Victor Leschuk.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  Alexander Kuleshov, Alex Henrie, brian m. carlson, Christian
  Couder, David A. Greene, David Turner, Dennis Kaarsemaker,
  Edmundo Carmona Antoranz, Elia Pinto, Eric Wong, Jacob Keller,
  Jeff King, Jiang Xin, Johannes Schindelin, Johannes Sixt,
  John Keeping, Jonathan Nieder, Junio C Hamano, Karsten Blees,
  Karthik Nayak, Knut Franke, Lars Schneider, Matthieu Moy, Matt
  McCutchen, Michael J Gruber, Mike Hommey, Nguyễn Thái Ngọc
  Duy, Øyvind A. Holm, Patrick Steinhardt, Pat Thoyts, Sebastian
  Schuberth, Shawn O. Pearce, Stefan Beller, Stephen P. Smith,
  SZEDER Gábor, Thomas Ackermann, Thomas Braun, Thomas Gummerer,
  Tobias Klauser, Torsten Bögershausen, and Will Palmer.

----------------------------------------------------------------

Git 2.8 Release Notes (draft)
=============================

Backward compatibility note
---------------------------

The rsync:// transport has been removed.


Updates since v2.7
------------------

UI, Workflows & Features

 * It turns out "git clone" over rsync transport has been broken when
   the source repository has packed references for a long time, and
   nobody noticed nor complained about it.

 * "branch --delete" has "branch -d" but "push --delete" does not.

 * "git blame" learned to produce the progress eye-candy when it takes
   too much time before emitting the first line of the result.

 * "git grep" can now be configured (or told from the command line)
   how many threads to use when searching in the working tree files.

 * Some "git notes" operations, e.g. "git log --notes=<note>", should
   be able to read notes from any tree-ish that is shaped like a notes
   tree, but the notes infrastructure required that the argument must
   be a ref under refs/notes/.  Loosen it to require a valid ref only
   when the operation would update the notes (in which case we must
   have a place to store the updated notes tree, iow, a ref).

 * "git grep" by default does not fall back to its "--no-index"
   behaviour outside a directory under Git's control (otherwise the
   user may by mistake end up running a huge recursive search); with a
   new configuration (set in $HOME/.gitconfig--by definition this
   cannot be set in the config file per project), this safety can be
   disabled.

 * "git pull --rebase" has been extended to allow invoking
   "rebase -i".

 * "git p4" learned to cope with the type of a file getting changed.

 * "git format-patch" learned to notice format.outputDirectory
   configuration variable.  This allows "-o <dir>" option to be
   omitted on the command line if you always use the same directory in
   your workflow.

 * "interpret-trailers" has been taught to optionally update a file in
   place, instead of always writing the result to the standard output.

 * Many commands that read files that are expected to contain text
   that is generated (or can be edited) by the end user to control
   their behaviour (e.g. "git grep -f <filename>") have been updated
   to be more tolerant to lines that are terminated with CRLF (they
   used to treat such a line to contain payload that ends with CR,
   which is usually not what the users expect).

 * "git notes merge" used to limit the source of the merged notes tree
   to somewhere under refs/notes/ hierarchy, which was too limiting
   when inventing a workflow to exchange notes with remote
   repositories using remote-tracking notes trees (located in e.g.
   refs/remote-notes/ or somesuch).

 * "git ls-files" learned a new "--eol" option to help diagnose
   end-of-line problems.

 * "ls-remote" learned an option to show which branch the remote
   repository advertises as its primary by pointing its HEAD at.

 * New http.proxyAuthMethod configuration variable can be used to
   specify what authentication method to use, as a way to work around
   proxies that do not give error response expected by libcurl when
   CURLAUTH_ANY is used.  Also, the codepath for proxy authentication
   has been taught to use credential API to store the authentication
   material in user's keyrings.

 * Update the untracked cache subsystem and change its primary UI from
   "git update-index" to "git config".

 * There were a few "now I am doing this thing" progress messages in
   the TCP connection code that can be triggered by setting a verbose
   option internally in the code, but "git fetch -v" and friends never
   passed the verbose option down to that codepath.

 * Clean/smudge filters defined in a configuration file of lower
   precedence can now be overridden to be a pass-through no-op by
   setting the variable to an empty string.

 * A new "<branch>^{/!-<pattern>}" notation can be used to name a
   commit that is reachable from <branch> that does not match the
   given <pattern>.

 * The "user.useConfigOnly" configuration variable can be used to
   force the user to always set user.email & user.name configuration
   variables, serving as a reminder for those who work on multiple
   projects and do not want to put these in their $HOME/.gitconfig.

 * "git fetch" and friends that make network connections can now be
   told to only use ipv4 (or ipv6).

 * Some authentication methods do not need username or password, but
   libcurl needs some hint that it needs to perform authentication.
   Supplying an empty username and password string is a valid way to
   do so, but you can set the http.[<url>.]emptyAuth configuration
   variable to achieve the same, if you find it cleaner.

 * You can now set http.[<url>.]pinnedpubkey to specify the pinned
   public key when building with recent enough versions of libcURL.

 * The configuration system has been taught to phrase where it found a
   bad configuration variable in a better way in its error messages.
   "git config" learnt a new "--show-origin" option to indicate where
   the values come from.

 * The "credential-cache" daemon process used to run in whatever
   directory it happened to start in, but this made umount(2)ing the
   filesystem that houses the repository harder; now the process
   chdir()s to the directory that house its own socket on startup.

 * When "git submodule update" did not result in fetching the commit
   object in the submodule that is referenced by the superproject, the
   command learned to retry another fetch, specifically asking for
   that commit that may not be connected to the refs it usually
   fetches.

 * "git merge-recursive" learned "--no-renames" option to disable its
   rename detection logic.

 * Across the transition at around Git version 2.0, the user used to
   get a pretty loud warning when running "git push" without setting
   push.default configuration variable.  We no longer warn, given that
   the transition is over long time ago.

 * README has been renamed to README.md and its contents got tweaked
   slightly to make it easier on the eyes.


Performance, Internal Implementation, Development Support etc.

 * Add a framework to spawn a group of processes in parallel, and use
   it to run "git fetch --recurse-submodules" in parallel.

 * A slight update to the Makefile to mark "phoney" targets
   as such correctly.

 * In-core storage of the reverse index for .pack files (which lets
   you go from a pack offset to an object name) has been streamlined.

 * d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like
   $GIT_DIR, 2015-06-26) attempted to work around a glitch in alias
   handling by overwriting GIT_WORK_TREE environment variable to
   affect subprocesses when set_git_work_tree() gets called, which
   resulted in a rather unpleasant regression to "clone" and "init".
   Try to address the same issue by always restoring the environment
   and respawning the real underlying command when handling alias.

 * The low-level code that is used to create symbolic references has
   been updated to share more code with the code that deals with
   normal references.

 * strbuf_getline() and friends have been redefined to make it easier
   to identify which callsite of (new) strbuf_getline_lf() should
   allow and silently ignore carriage-return at the end of the line to
   help users on DOSsy systems.

 * "git shortlog" used to accumulate various pieces of information
   regardless of what was asked to be shown in the final output.  It
   has been optimized by noticing what need not to be collected
   (e.g. there is no need to collect the log messages when showing
   only the number of changes).

 * "git checkout $branch" (and other operations that share the same
   underlying machinery) has been optimized.

 * Automated tests in Travis CI environment has been optimized by
   persisting runtime statistics of previous "prove" run, executing
   tests that take longer before other ones; this reduces the total
   wallclock time.

 * Test scripts have been updated to remove assumptions that are not
   portable between Git for POSIX and Git for Windows, or to skip ones
   with expectations that are not satisfiable on Git for Windows.

 * Some calls to strcpy(3) triggers a false warning from static
   analysers that are less intelligent than humans, and reducing the
   number of these false hits helps us notice real issues.  A few
   calls to strcpy(3) in test-path-utils that are already safe has
   been rewritten to avoid false wanings.

 * Some calls to strcpy(3) triggers a false warning from static
   analysers that are less intelligent than humans, and reducing the
   number of these false hits helps us notice real issues.  A few
   calls to strcpy(3) in "git rerere" that are already safe has been
   rewritten to avoid false wanings.

 * The "name_path" API was an attempt to reduce the need to construct
   the full path out of a series of path components while walking a
   tree hierarchy, but over time made less efficient because the path
   needs to be flattened, e.g. to be compared with another path that
   is already flat.  The API has been removed and its users have been
   rewritten to simplify the overall code complexity.

 * Help those who debug http(s) part of the system.
   (merge 0054045 sp/remote-curl-ssl-strerror later to maint).

 * The internal API to interact with "remote.*" configuration
   variables has been streamlined.

 * The ref-filter's format-parsing code has been refactored, in
   preparation for "branch --format" and friends.

 * Traditionally, the tests that try commands that work on the
   contents in the working tree were named with "worktree" in their
   filenames, but with the recent addition of "git worktree"
   subcommand, whose tests are also named similarly, it has become
   harder to tell them apart.  The traditional tests have been renamed
   to use "work-tree" instead in an attempt to differentiate them.
   (merge 5549029 mg/work-tree-tests later to maint).

 * Many codepaths forget to check return value from git_config_set();
   the function is made to die() to make sure we do not proceed when
   setting a configuration variable failed.
   (merge 3d18064 ps/config-error later to maint).

 * Handling of errors while writing into our internal asynchronous
   process has been made more robust, which reduces flakiness in our
   tests.
   (merge 43f3afc jk/epipe-in-async later to maint).

 * There is a new DEVELOPER knob that enables many compiler warning
   options in the Makefile.

 * The way the test scripts configure the Apache web server has been
   updated to work also for Apache 2.4 running on RedHat derived
   distros.

 * Out of maintenance gcc on OSX 10.6 fails to compile the code in
   'master'; work it around by using clang by default on the platform.


Also contains various documentation updates and code clean-ups.


Fixes since v2.7
----------------

Unless otherwise noted, all the fixes since v2.7 in the maintenance
track are contained in this release (see the maintenance releases'
notes for details).

 * An earlier change in 2.5.x-era broke users' hooks and aliases by
   exporting GIT_WORK_TREE to point at the root of the working tree,
   interfering when they tried to use a different working tree without
   setting GIT_WORK_TREE environment themselves.

 * The "exclude_list" structure has the usual "alloc, nr" pair of
   fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot
   to reset 'alloc' to 0 when it cleared 'nr' to discard the managed
   array.

 * Paths that have been told the index about with "add -N" are not
   quite yet in the index, but a few commands behaved as if they
   already are in a harmful way.

 * "git send-email" was confused by escaped quotes stored in the alias
   files saved by "mutt", which has been corrected.

 * A few unportable C construct have been spotted by clang compiler
   and have been fixed.

 * The documentation has been updated to hint the connection between
   the '--signoff' option and DCO.

 * "git reflog" incorrectly assumed that all objects that used to be
   at the tip of a ref must be commits, which caused it to segfault.

 * The ignore mechanism saw a few regressions around untracked file
   listing and sparse checkout selection areas in 2.7.0; the change
   that is responsible for the regression has been reverted.

 * Another try to improve the ignore mechanism that lets you say "this
   is excluded" and then later say "oh, no, this part (that is a
   subset of the previous part) is not excluded".  This has still a
   known limitation, though.

 * Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR
   (e.g. COMMIT_EDITMSG) that is meant to be left after the command is
   done.  This however did not work well if the repository is set to
   be shared with core.sharedRepository and the umask of the previous
   user is tighter.  They have been made to work better by calling
   unlink(2) and retrying after fopen(3) fails with EPERM.

 * Asking gitweb for a nonexistent commit left a warning in the server
   log.

   Somebody may want to follow this up with an additional test, perhaps?
   IIRC, we do test that no Perl warnings are given to the server log,
   so this should have been caught if our test coverage were good.

 * "git rebase", unlike all other callers of "gc --auto", did not
   ignore the exit code from "gc --auto".

 * Many codepaths that run "gc --auto" before exiting kept packfiles
   mapped and left the file descriptors to them open, which was not
   friendly to systems that cannot remove files that are open.  They
   now close the packs before doing so.

 * A recent optimization to filter-branch in v2.7.0 introduced a
   regression when --prune-empty filter is used, which has been
   corrected.

 * The description for SANITY prerequisite the test suite uses has
   been clarified both in the comment and in the implementation.

 * "git tag" started listing a tag "foo" as "tags/foo" when a branch
   named "foo" exists in the same repository; remove this unnecessary
   disambiguation, which is a regression introduced in v2.7.0.

 * The way "git svn" uses auth parameter was broken by Subversion
   1.9.0 and later.

 * The "split" subcommand of "git subtree" (in contrib/) incorrectly
   skipped merges when it shouldn't, which was corrected.

 * A few options of "git diff" did not work well when the command was
   run from a subdirectory.

 * The command line completion learned a handful of additional options
   and command specific syntax.

 * dirname() emulation has been added, as Msys2 lacks it.

 * The underlying machinery used by "ls-files -o" and other commands
   have been taught not to create empty submodule ref cache for a
   directory that is not a submodule.  This removes a ton of wasted
   CPU cycles.

 * "git worktree" had a broken code that attempted to auto-fix
   possible inconsistency that results from end-users moving a
   worktree to different places without telling Git (the original
   repository needs to maintain backpointers to its worktrees, but
   "mv" run by end-users who are not familiar with that fact will
   obviously not adjust them), which actually made things worse
   when triggered.

 * The low-level merge machinery has been taught to use CRLF line
   termination when inserting conflict markers to merged contents that
   are themselves CRLF line-terminated.

 * "git push --force-with-lease" has been taught to report if the push
   needed to force (or fast-forwarded).

 * The emulated "yes" command used in our test scripts has been
   tweaked not to spend too much time generating unnecessary output
   that is not used, to help those who test on Windows where it would
   not stop until it fills the pipe buffer due to lack of SIGPIPE.

 * The documentation for "git clean" has been corrected; it mentioned
   that .git/modules/* are removed by giving two "-f", which has never
   been the case.

 * The vimdiff backend for "git mergetool" has been tweaked to arrange
   and number buffers in the order that would match the expectation of
   majority of people who read left to right, then top down and assign
   buffers 1 2 3 4 "mentally" to local base remote merge windows based
   on that order.

 * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
   rev, i.e. the object named by the the pathname with wildcard
   characters in a tree object.
   (merge aac4fac nd/dwim-wildcards-as-pathspecs later to maint).

 * "git rev-parse --git-common-dir" used in the worktree feature
   misbehaved when run from a subdirectory.
   (merge 17f1365 nd/git-common-dir-fix later to maint).

 * "git worktree add -B <branchname>" did not work.

 * The "v(iew)" subcommand of the interactive "git am -i" command was
   broken in 2.6.0 timeframe when the command was rewritten in C.
   (merge 708b8cc jc/am-i-v-fix later to maint).

 * "git merge-tree" used to mishandle "both sides added" conflict with
   its own "create a fake ancestor file that has the common parts of
   what both sides have added and do a 3-way merge" logic; this has
   been updated to use the usual "3-way merge with an empty blob as
   the fake common ancestor file" approach used in the rest of the
   system.
   (merge 907681e jk/no-diff-emit-common later to maint).

 * The memory ownership rule of fill_textconv() API, which was a bit
   tricky, has been documented a bit better.
   (merge a64e6a4 jk/more-comments-on-textconv later to maint).

 * Update various codepaths to avoid manually-counted malloc().
   (merge 08c95df jk/tighten-alloc later to maint).

 * The documentation did not clearly state that the 'simple' mode is
   now the default for "git push" when push.default configuration is
   not set.
   (merge f6b1fb3 mm/push-simple-doc later to maint).

 * Recent versions of GNU grep are pickier when their input contains
   arbitrary binary data, which some of our tests uses.  Rewrite the
   tests to sidestep the problem.
   (merge 3b1442d jk/grep-binary-workaround-in-test later to maint).

 * A helper function "git submodule" uses since v2.7.0 to list the
   modules that match the pathspec argument given to its subcommands
   (e.g. "submodule add <repo> <path>") has been fixed.
   (merge 2b56bb7 sb/submodule-module-list-fix later to maint).

 * "git config section.var value" to set a value in per-repository
   configuration file failed when it was run outside any repository,
   but didn't say the reason correctly.
   (merge 638fa62 js/config-set-in-non-repository later to maint).

 * The code to read the pack data using the offsets stored in the pack
   idx file has been made more carefully check the validity of the
   data in the idx.
   (merge 7465feb jk/pack-idx-corruption-safety later to maint).

 * Other minor clean-ups and documentation updates
   (merge f459823 ak/extract-argv0-last-dir-sep later to maint).
   (merge 63ca1c0 ak/git-strip-extension-from-dashed-command later to maint).
   (merge 4867f11 ps/plug-xdl-merge-leak later to maint).
   (merge 4938686 dt/initial-ref-xn-commit-doc later to maint).
   (merge 9537f21 ma/update-hooks-sample-typofix later to maint).

----------------------------------------------------------------

Changes since v2.7.0 are as follows:

Alex Henrie (1):
      stripspace: call U+0020 a "space" instead of a "blank"

Alexander Kuleshov (3):
      format-patch: introduce format.outputDirectory configuration
      exec_cmd.c: use find_last_dir_sep() for code simplification
      git.c: simplify stripping extension of a file in handle_builtin()

Andrew Wheeler (1):
      push: fix ref status reporting for --force-with-lease

Changwoo Ryu (1):
      l10n: ko.po: Add Korean translation

Christian Couder (11):
      dir: free untracked cache when removing it
      update-index: use enum for untracked cache options
      update-index: add --test-untracked-cache
      update-index: add untracked cache notifications
      update-index: move 'uc' var declaration
      dir: add {new,add}_untracked_cache()
      dir: add remove_untracked_cache()
      dir: simplify untracked cache "ident" field
      config: add core.untrackedCache
      test-dump-untracked-cache: don't modify the untracked cache
      t7063: add tests for core.untrackedCache

Christoph Egger (1):
      http: implement public key pinning

Dan Aloni (1):
      ident: add user.useConfigOnly boolean for when ident shouldn't be guessed

Dave Ware (1):
      contrib/subtree: fix "subtree split" skipped-merge bug

David A. Greene (1):
      contrib/subtree: Make testing easier

David A. Wheeler (1):
      Expand documentation describing --signoff

David Turner (3):
      do_compare_entry: use already-computed path
      unpack-trees: fix accidentally quadratic behavior
      refs: document transaction semantics

Dennis Kaarsemaker (1):
      reflog-walk: don't segfault on non-commit sha1's in the reflog

Dickson Wong (1):
      mergetool: reorder vim/gvim buffers in three-way diffs

Edmundo Carmona Antoranz (1):
      blame: add support for --[no-]progress option

Elia Pinto (92):
      Makefile: add missing phony target
      contrib/examples/git-commit.sh: use the $( ... ) construct for command substitution
      contrib/examples/git-fetch.sh: use the $( ... ) construct for command substitution
      contrib/examples/git-merge.sh: use the $( ... ) construct for command substitution
      contrib/examples/git-repack.sh: use the $( ... ) construct for command substitution
      contrib/examples/git-revert.sh: use the $( ... ) construct for command substitution
      contrib/thunderbird-patch-inline/appp.sh: use the $( ... ) construct for command substitution
      git-gui/po/glossary/txt-to-pot.sh: use the $( ... ) construct for command substitution
      t/lib-httpd.sh: use the $( ... ) construct for command substitution
      test-sha1.sh: use the $( ... ) construct for command substitution
      unimplemented.sh: use the $( ... ) construct for command substitution
      t/t1100-commit-tree-options.sh: use the $( ... ) construct for command substitution
      t/t1401-symbolic-ref.sh: use the $( ... ) construct for command substitution
      t/t1410-reflog.sh: use the $( ... ) construct for command substitution
      t/t1511-rev-parse-caret.sh: use the $( ... ) construct for command substitution
      t/t1512-rev-parse-disambiguation.sh: use the $( ... ) construct for command substitution
      t/t1700-split-index.sh: use the $( ... ) construct for command substitution
      t/t2025-worktree-add.sh: use the $( ... ) construct for command substitution
      t/t2102-update-index-symlinks.sh: use the $( ... ) construct for command substitution
      t/t3030-merge-recursive.sh: use the $( ... ) construct for command substitution
      t/t3100-ls-tree-restrict.sh: use the $( ... ) construct for command substitution
      t/t3101-ls-tree-dirname.sh: use the $( ... ) construct for command substitution
      t/t3210-pack-refs.sh: use the $( ... ) construct for command substitution
      t/t3403-rebase-skip.sh: use the $( ... ) construct for command substitution
      t/t3511-cherry-pick-x.sh: use the $( ... ) construct for command substitution
      t/t3600-rm.sh: use the $( ... ) construct for command substitution
      t/t3700-add.sh: use the $( ... ) construct for command substitution
      t/t5100-mailinfo.sh: use the $( ... ) construct for command substitution
      t/t5300-pack-object.sh: use the $( ... ) construct for command substitution
      t/t5301-sliding-window.sh: use the $( ... ) construct for command substitution
      t/t5302-pack-index.sh: use the $( ... ) construct for command substitution
      t/t5303-pack-corruption-resilience.sh: use the $( ... ) construct for command substitution
      t/t5304-prune.sh: use the $( ... ) construct for command substitution
      t/t5305-include-tag.sh: use the $( ... ) construct for command substitution
      t/t5500-fetch-pack.sh: use the $( ... ) construct for command substitution
      t/t5505-remote.sh: use the $( ... ) construct for command substitution
      t/t5506-remote-groups.sh: use the $( ... ) construct for command substitution
      t/t5510-fetch.sh: use the $( ... ) construct for command substitution
      t/t5515-fetch-merge-logic.sh: use the $( ... ) construct for command substitution
      t/t5516-fetch-push.sh: use the $( ... ) construct for command substitution
      t/t5517-push-mirror.sh: use the $( ... ) construct for command substitution
      t/t5522-pull-symlink.sh: use the $( ... ) construct for command substitution
      t/t5530-upload-pack-error.sh: use the $( ... ) construct for command substitution
      t/t5532-fetch-proxy.sh: use the $( ... ) construct for command substitution
      t/t5537-fetch-shallow.sh: use the $( ... ) construct for command substitution
      t/t5538-push-shallow.sh: use the $( ... ) construct for command substitution
      t/t5550-http-fetch-dumb.sh: use the $( ... ) construct for command substitution
      t/t5570-git-daemon.sh: use the $( ... ) construct for command substitution
      t/t5601-clone.sh: use the $( ... ) construct for command substitution
      t/t5700-clone-reference.sh: use the $( ... ) construct for command substitution
      t/t5710-info-alternate.sh: use the $( ... ) construct for command substitution
      t/t5900-repo-selection.sh: use the $( ... ) construct for command substitution
      t/t6001-rev-list-graft.sh: use the $( ... ) construct for command substitution
      t/t6002-rev-list-bisect.sh: use the $( ... ) construct for command substitution
      t/t6015-rev-list-show-all-parents.sh: use the $( ... ) construct for command substitution
      t/t6032-merge-large-rename.sh: use the $( ... ) construct for command substitution
      t/t6132-pathspec-exclude.sh: use the $( ... ) construct for command substitution
      t/t7001-mv.sh: use the $( ... ) construct for command substitution
      t/t7003-filter-branch.sh: use the $( ... ) construct for command substitution
      t/t7004-tag.sh: use the $( ... ) construct for command substitution
      t/t7006-pager.sh: use the $( ... ) construct for command substitution
      t/t7103-reset-bare.sh: use the $( ... ) construct for command substitution
      t/t7406-submodule-update.sh: use the $( ... ) construct for command substitution
      t/t7408-submodule-reference.sh: use the $( ... ) construct for command substitution
      t/t7504-commit-msg-hook.sh: use the $( ... ) construct for command substitution
      t/t7505-prepare-commit-msg-hook.sh: use the $( ... ) construct for command substitution
      t/t7602-merge-octopus-many.sh: use the $( ... ) construct for command substitution
      t/t7700-repack.sh: use the $( ... ) construct for command substitution
      t/t8003-blame-corner-cases.sh: use the $( ... ) construct for command substitution
      t/t9001-send-email.sh: use the $( ... ) construct for command substitution
      t9100-git-svn-basic.sh: use the $( ... ) construct for command substitution
      t9101-git-svn-props.sh: use the $( ... ) construct for command substitution
      t9104-git-svn-follow-parent.sh: use the $( ... ) construct for command substitution
      t9105-git-svn-commit-diff.sh: use the $( ... ) construct for command substitution
      t9107-git-svn-migrate.sh: use the $( ... ) construct for command substitution
      t9108-git-svn-glob.sh: use the $( ... ) construct for command substitution
      t9109-git-svn-multi-glob.sh: use the $( ... ) construct for command substitution
      t9110-git-svn-use-svm-props.sh: use the $( ... ) construct for command substitution
      t9114-git-svn-dcommit-merge.sh: use the $( ... ) construct for command substitution
      t9118-git-svn-funky-branch-names.sh: use the $( ... ) construct for command substitution
      t9119-git-svn-info.sh: use the $( ... ) construct for command substitution
      t9129-git-svn-i18n-commitencoding.sh: use the $( ... ) construct for command substitution
      t9130-git-svn-authors-file.sh: use the $( ... ) construct for command substitution
      t9132-git-svn-broken-symlink.sh: use the $( ... ) construct for command substitution
      t9137-git-svn-dcommit-clobber-series.sh: use the $( ... ) construct for command substitution
      t9138-git-svn-authors-prog.sh: use the $( ... ) construct for command substitution
      t9145-git-svn-master-branch.sh: use the $( ... ) construct for command substitution
      t9150-svk-mergetickets.sh: use the $( ... ) construct for command substitution
      t9300-fast-import.sh: use the $( ... ) construct for command substitution
      t9350-fast-export.sh: use the $( ... ) construct for command substitution
      t9501-gitweb-standalone-http-status.sh: use the $( ... ) construct for command substitution
      t9901-git-web--browse.sh: use the $( ... ) construct for command substitution

Eric Wong (8):
      git-send-email: do not double-escape quotes from mutt
      for-each-ref: document `creatordate` and `creator` fields
      git-svn: fix auth parameter handling on SVN 1.9.0+
      pass transport verbosity down to git_connect
      connect & http: support -4 and -6 switches for remote operations
      t5570: add tests for "git {clone,fetch,pull} -v"
      git-svn: hoist out utf8 prep from t9129 to lib-git-svn
      tests: remove no-op full-svn-test target

Felipe Gonçalves Assis (7):
      merge-recursive: option to disable renames
      merge-recursive: more consistent interface
      merge-strategies.txt: fix typo
      merge-recursive: find-renames resets threshold
      t3034: add rename threshold tests
      t3034: test option to disable renames
      t3034: test deprecated interface

GyuYong Jung (1):
      git-cvsserver.perl: fix typo

Jacob Keller (1):
      notes: allow merging from arbitrary references

Jeff King (79):
      pack-revindex: drop hash table
      pack-revindex: store entries directly in packed_git
      create_symref: modernize variable names
      create_symref: use existing ref-lock code
      create_symref: write reflog while holding lock
      run-command: don't warn on SIGPIPE deaths
      avoid shifting signed integers 31 bits
      bswap: add NO_UNALIGNED_LOADS define
      checkout,clone: check return value of create_symref
      lock_ref_sha1_basic: always fill old_oid while holding lock
      lock_ref_sha1_basic: handle REF_NODEREF with invalid refs
      rebase: ignore failures from "gc --auto"
      shortlog: match both "Author:" and "author" on stdin
      shortlog: use strbufs to read from stdin
      shortlog: replace hand-parsing of author with pretty-printer
      shortlog: optimize "--summary" mode
      shortlog: optimize out useless "<none>" normalization
      shortlog: optimize out useless string list
      shortlog: don't warn on empty author
      filter-branch: resolve $commit^{tree} in no-index case
      clean: make is_git_repository a public function
      resolve_gitlink_ref: ignore non-repository paths
      t6300: use test_atom for some un-modern tests
      tag: do not show ambiguous tag names as "tags/foo"
      transport: drop support for git-over-rsync
      give "nbuf" strbuf a more meaningful name
      checkout-index: simplify "-z" option parsing
      checkout-index: handle "--no-prefix" option
      checkout-index: handle "--no-index" option
      checkout-index: disallow "--no-stage" option
      apply, ls-files: simplify "-z" parsing
      fmt_ident: refactor strictness checks
      test-path-utils: use xsnprintf in favor of strcpy
      rerere: replace strcpy with xsnprintf
      checkout: reorder check_filename conditional
      check_filename: tighten dwim-wildcard ambiguity
      get_sha1: don't die() on bogus search strings
      http-push: stop using name_path
      show_object_with_name: simplify by using path_name()
      list-objects: convert name_path to a strbuf
      list-objects: drop name_path entirely
      list-objects: pass full pathname to callbacks
      git-config: better document default behavior for `--include`
      ref-filter: use string_list_split over strbuf_split
      reflog_expire_cfg: NUL-terminate pattern field
      add helpers for detecting size_t overflow
      tree-diff: catch integer overflow in combine_diff_path allocation
      diff: clarify textconv interface
      harden REALLOC_ARRAY and xcalloc against size_t overflow
      add helpers for allocating flex-array structs
      argv-array: add detach function
      convert manual allocations to argv_array
      convert trivial cases to ALLOC_ARRAY
      use xmallocz to avoid size arithmetic
      convert trivial cases to FLEX_ARRAY macros
      use st_add and st_mult for allocation size computation
      prepare_{git,shell}_cmd: use argv_array
      write_untracked_extension: use FLEX_ALLOC helper
      fast-import: simplify allocation in start_packfile
      fetch-pack: simplify add_sought_entry
      test-path-utils: fix normalize_path_copy output buffer size
      sequencer: simplify memory allocation of get_message
      git-compat-util: drop mempcpy compat code
      transport_anonymize_url: use xstrfmt
      diff_populate_gitlink: use a strbuf
      convert ewah/bitmap code to use xmalloc
      ewah: convert to REALLOC_ARRAY, etc
      merge-one-file: use empty blob for add/add base
      merge-tree: drop generate_common strategy
      xdiff: drop XDL_EMIT_COMMON
      t5313: test bounds-checks of corrupted/malicious pack/idx files
      nth_packed_object_offset: bounds-check extended offset
      use_pack: handle signed off_t overflow
      write_or_die: handle EPIPE in async threads
      fetch-pack: ignore SIGPIPE in sideband demuxer
      test_must_fail: report number of unexpected signal
      t5504: handle expected output from SIGPIPE death
      compat/mingw: brown paper bag fix for 50a6c8e
      t9700: fix test for perl older than 5.14

Jiang Xin (1):
      http: honor no_http env variable to bypass proxy

Johannes Schindelin (47):
      commit: allow editing the commit message even in shared repos
      Handle more file writes correctly in shared repos
      Refactor skipping DOS drive prefixes
      compat/basename: make basename() conform to POSIX
      compat/basename.c: provide a dirname() compatibility function
      t0060: verify that basename() and dirname() work as expected
      config.mak.uname: support MSys2
      config.mak.uname: supporting 64-bit MSys2
      fetch: release pack files before garbage-collecting
      am: release pack files before garbage-collecting
      merge: release pack files before garbage-collecting
      receive-pack: release pack files before garbage-collecting
      pull: allow interactive rebase with --rebase=interactive
      remote: handle the config setting branch.*.rebase=interactive
      completion: add missing branch.*.rebase values
      nedmalloc: allow compiling with MSys2's compiler
      compat/mingw: support MSys2-based MinGW build
      compat/winansi: support compiling with MSys2
      t0060: loosen overly strict expectations
      mingw: avoid redefining S_* constants
      mingw: avoid warnings when casting HANDLEs to int
      mingw: squash another warning about a cast
      mingw: uglify (a, 0) definitions to shut up warnings
      mingw: let's use gettext with MSYS2
      mingw: do not trust MSYS2's MinGW gettext.sh
      Git.pm: stop assuming that absolute paths start with a slash
      mingw: prepare the TMPDIR environment variable for shell scripts
      mingw: let lstat() fail with errno == ENOTDIR when appropriate
      merge-file: let conflict markers match end-of-line style of the context
      merge-file: ensure that conflict sections match eol style
      mingw: fix t5601-clone.sh
      mingw: accomodate t0060-path-utils for MSYS2
      mingw: disable mkfifo-based tests
      tests: turn off git-daemon tests if FIFOs are not available
      mingw: skip test in t1508 that fails due to path conversion
      mingw: fix t9700's assumption about directory separators
      mingw: work around pwd issues in the tests
      mingw: mark t9100's test cases with appropriate prereqs
      mingw: avoid illegal filename in t9118
      mingw: handle the missing POSIXPERM prereq in t9124
      mingw: skip a test in t9130 that cannot pass on Windows
      mingw: do not bother to test funny file names
      test-lib: limit the output of the yes utility
      gitignore: ignore generated test-fake-ssh executable
      t5505: 'remote add x y' should work when url.y.insteadOf = x
      git config: report when trying to modify a non-existing repo config
      Mark win32's pthread_exit() as NORETURN

Johannes Sixt (3):
      t/t5100: no need to use 'echo' command substitutions for globbing
      mingw: avoid linking to the C library's isalpha()
      t0001: fix GIT_* environment variable check under --valgrind

John Keeping (3):
      completion: add missing git-rebase options
      t8005: avoid grep on non-ASCII data
      t9200: avoid grep on non-ASCII data

Jon Griffiths (3):
      credential-cache--daemon: refactor check_socket_directory
      credential-cache--daemon: disallow relative socket path
      credential-cache--daemon: change to the socket dir on startup

Jonathan Nieder (1):
      submodule.c: write "Fetching submodule <foo>" to stderr

Junio C Hamano (46):
      First batch for post 2.7 cycle
      strbuf: miniscule style fix
      strbuf: make strbuf_getline_crlf() global
      strbuf: introduce strbuf_getline_{lf,nul}()
      mktree: there are only two possible line terminations
      check-attr: there are only two possible line terminations
      check-ignore: there are only two possible line terminations
      update-index: there are only two possible line terminations
      checkout-index: there are only two possible line terminations
      strbuf: give strbuf_getline() to the "most text friendly" variant
      hash-object: read --stdin-paths with strbuf_getline()
      revision: read --stdin with strbuf_getline()
      rev-parse: read parseopt spec with strbuf_getline()
      ident.c: read /etc/mailname with strbuf_getline()
      remote.c: read $GIT_DIR/remotes/* with strbuf_getline()
      clone/sha1_file: read info/alternates with strbuf_getline()
      transport-helper: read helper response with strbuf_getline()
      cat-file: read batch stream with strbuf_getline()
      column: read lines with strbuf_getline()
      send-pack: read list of refs with strbuf_getline()
      grep: read -f file with strbuf_getline()
      test-sha1-array: read command stream with strbuf_getline()
      test-lib: clarify and tighten SANITY
      Second batch for 2.8 cycle
      Third batch for 2.8 cycle
      git: remove an early return from save_env_before_alias()
      git: protect against unbalanced calls to {save,restore}_env()
      git: simplify environment save/restore logic
      Fourth batch for 2.8.cycle
      Getting closer to 2.7.1
      restore_env(): free the saved environment variable once we are done
      Fifth batch for 2.8 cycle
      Git 2.7.1
      Sixth batch for the 2.8 cycle
      pager: lose a separate argv[]
      pager: factor out a helper to prepare a child process to run the pager
      am -i: fix "v"iew
      Start preparing for 2.7.2
      Seventh batch for the 2.8 cycle
      Git 2.7.2
      Eighth batch for 2.8
      Git 2.8-rc0
      Git 2.8-rc1
      gitignore: document that unignoring a directory unignores everything in it
      Git 2.7.3
      Git 2.8-rc2

Karsten Blees (1):
      mingw: factor out Windows specific environment setup

Karthik Nayak (10):
      ref-filter: bump 'used_atom' and related code to the top
      ref-filter: introduce struct used_atom
      ref-filter: introduce parsing functions for each valid atom
      ref-filter: introduce color_atom_parser()
      ref-filter: introduce parse_align_position()
      ref-filter: introduce align_atom_parser()
      ref-filter: align: introduce long-form syntax
      ref-filter: introduce remote_ref_atom_parser()
      ref-filter: introduce contents_atom_parser()
      ref-filter: introduce objectname_atom_parser()

Kazutoshi Satoda (2):
      git-svn: enable "svn.pathnameencoding" on dcommit
      git-svn: apply "svn.pathnameencoding" before URL encoding

Knut Franke (2):
      http: allow selection of proxy authentication method
      http: use credential API to handle proxy authentication

Lars Schneider (8):
      travis-ci: run previously failed tests first, then slowest to fastest
      travis-ci: explicity use container-based infrastructure
      convert: treat an empty string for clean/smudge filters as "cat"
      t: do not hide Git's exit code in tests using 'nul_to_q'
      rename git_config_from_buf to git_config_from_mem
      config: add 'origin_type' to config_source struct
      config: add '--show-origin' option to print the origin of a config value
      add DEVELOPER makefile knob to check for acknowledged warnings

Lars Vogel (1):
      git-add doc: do not say working directory when you mean working tree

Martin Amdisen (1):
      templates/hooks: fix minor typo in the sample update-hook

Matt McCutchen (1):
      Documentation/git-clean.txt: don't mention deletion of .git/modules/*

Matthew Kraai (1):
      Documentation: remove unnecessary backslashes

Matthieu Moy (7):
      Documentation/git-push: document that 'simple' is the default
      README: use markdown syntax
      README.md: add hyperlinks on filenames
      README.md: move the link to git-scm.com up
      README.md: don't call git stupid in the title
      README.md: move down historical explanation about the name
      push: remove "push.default is unset" warning message

Michael J Gruber (4):
      t9100: fix breakage when SHELL_PATH is not /bin/sh
      tests: rename work-tree tests to *work-tree*
      t/lib-httpd: load mod_unixd
      t5510: do not leave changed cwd

Mike Hommey (1):
      notes: allow treeish expressions as notes ref

Nguyễn Thái Ngọc Duy (25):
      blame: remove obsolete comment
      add and use a convenience macro ce_intent_to_add()
      Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
      git.c: make it clear save_env() is for alias handling only
      setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..
      git.c: make sure we do not leak GIT_* to alias scripts
      grep: make it clear i-t-a entries are ignored
      dir.c: clean the entire struct in clear_exclude_list()
      Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
      worktree.c: fix indentation
      diff-no-index: do not take a redundant prefix argument
      diff: make -O and --output work in subdirectory
      worktree: stop supporting moving worktrees manually
      rev-parse: take prefix into account in --git-common-dir
      dir.c: fix match_pathname()
      dir.c: support tracing exclude
      dir.c: support marking some patterns already matched
      dir.c: don't exclude whole dir prematurely
      worktree: fix "add -B"
      worktree add -B: do the checkout test before update branch
      sha1_file.c: mark strings for translation
      builtin/checkout.c: mark strings for translation
      builtin/clone.c: mark strings for translation
      ref-filter.c: mark strings for translation
      trailer.c: mark strings for translation

Pat Thoyts (1):
      t0008: avoid absolute path

Patrick Steinhardt (18):
      push: add '--delete' flag to synopsis
      push: add '-d' as shorthand for '--delete'
      config: introduce set_or_die wrappers
      branch: report errors in tracking branch setup
      branch: die on config error when unsetting upstream
      branch: die on config error when editing branch description
      submodule: die on config error when linking modules
      submodule--helper: die on config error when cloning module
      remote: die on config error when setting URL
      remote: die on config error when setting/adding branches
      remote: die on config error when manipulating remotes
      clone: die on config error in cmd_clone
      init-db: die on config errors when initializing empty repo
      sequencer: die on config error when saving replay opts
      compat: die when unable to set core.precomposeunicode
      config: rename git_config_set to git_config_set_gently
      config: rename git_config_set_or_die to git_config_set
      xdiff/xmerge: fix memory leak in xdl_merge

Paul Wagland (2):
      completion: complete show-branch "--date-order"
      completion: update completion arguments for stash

Rob Mayoff (1):
      contrib/subtree: unwrap tag refs

Romain Picard (1):
      git-p4.py: add support for filetype change

SZEDER Gábor (2):
      t6050-replace: make failing editor test more robust
      completion: fix mis-indentation in _git_stash()

Sebastian Schuberth (3):
      docs: clarify that passing --depth to git-clone implies --single-branch
      docs: say "commits" in the --depth option wording for git-clone
      docs: clarify that --depth for git-fetch works with newly initialized repos

Shawn O. Pearce (1):
      remote-curl: include curl_errorstr on SSL setup failures

Stefan Beller (10):
      xread: poll on non blocking fds
      strbuf: add strbuf_read_once to read without blocking
      sigchain: add command to pop all common signals
      run-command: add an asynchronous parallel child processor
      fetch_populated_submodules: use new parallel job processing
      submodules: allow parallel fetching, add tests and documentation
      submodule helper list: respect correct path prefix
      submodule: try harder to fetch needed sha1 by direct fetching sha1
      run-command: do not pass child process data into callbacks
      Documentation: reword rebase summary

Stephen P. Smith (4):
      user-manual: remove temporary branch entry from todo list
      glossary: define the term shallow clone
      user-manual: add section documenting shallow clones
      user-manual: add addition gitweb information

Thomas Ackermann (1):
      documentation: fix some typos

Thomas Braun (1):
      completion: complete "diff --word-diff-regex="

Thomas Gummerer (11):
      t7810: correct --no-index test
      builtin/grep: add grep.fallbackToNoIndex config
      ls-remote: document --quiet option
      ls-remote: document --refs option
      ls-remote: fix synopsis
      ls-remote: use parse-options api
      ls-remote: add support for showing symrefs
      remote: use parse_config_key
      remote: simplify remote_is_configured()
      remote: actually check if remote exits
      remote: use remote_is_configured() for add and rename

Tobias Klauser (2):
      trailer: allow to write to files other than stdout
      interpret-trailers: add option for in-place editing

Torsten Bögershausen (9):
      ls-files: add eol diagnostics
      t0027: add tests for get_stream_filter()
      convert.c: remove unused parameter 'path'
      convert.c: remove input_crlf_action()
      convert.c: use text_eol_is_crlf()
      convert.c: refactor crlf_action
      convert.c: simplify text_stat
      convert.c: correct attr_action()
      config.mak.uname: use clang for Mac OS X 10.6

Victor Leschuk (3):
      grep: allow threading even on a single-core machine
      grep: slight refactoring to the code that disables threading
      grep: add --threads=<num> option and grep.threads configuration

Will Palmer (2):
      test for '!' handling in rev-parse's named commits
      object name: introduce '^{/!-<negative pattern>}' notation

brian m. carlson (1):
      http: add option to try authentication without username

Øyvind A. Holm (1):
      gitweb: squelch "uninitialized value" warning

마누엘 (1):
      mingw: try to delete target directory before renaming

Re: [ANNOUNCE] Git v2.8.0-rc2

[Max Horn]

> On 11 Mar 2016, at 00:04, Junio C Hamano <gitster@pobox.com> wrote:
> 
> A release candidate Git v2.8.0-rc2 is now available for testing
> at the usual places.  It is comprised of 459 non-merge commits
> since v2.7.0, contributed by 60 people, 19 of which are new faces.
> 
[...]

> Updates since v2.7
> ------------------
> 
> UI, Workflows & Features
> 
> * It turns out "git clone" over rsync transport has been broken when
>   the source repository has packed references for a long time, and
>   nobody noticed nor complained about it.
> 
> * "branch --delete" has "branch -d" but "push --delete" does not.

This states a problem, but not whether (and how) it was resolved?

[...]

> * Across the transition at around Git version 2.0, the user used to
>   get a pretty loud warning when running "git push" without setting
>   push.default configuration variable.  We no longer warn, given that
>   the transition is over long time ago.

That last sentence sounds weird... perhaps "the transition was completed a long time ago" ? Or "the transition ended a long time ago" ?

> 
> * README has been renamed to README.md and its contents got tweaked
>   slightly to make it easier on the eyes.
> 
> 
> Performance, Internal Implementation, Development Support etc.
> 
> * Add a framework to spawn a group of processes in parallel, and use
>   it to run "git fetch --recurse-submodules" in parallel.
> 
> * A slight update to the Makefile to mark "phoney" targets
>   as such correctly.

phoney -> phony ? (it seems in british english you can write "phoney", but according to a quickly Google search this is rarely used in relation to Makefiles; no surprise, given that the corresponding syntax element is ".PHONY" and you are not allowed to spell it differently ;-)

[...]

> 
> * Some calls to strcpy(3) triggers a false warning from static
>   analysers that are less intelligent than humans, and reducing the
>   number of these false hits helps us notice real issues.  A few
>   calls to strcpy(3) in test-path-utils that are already safe has
>   been rewritten to avoid false wanings.
> 
> * Some calls to strcpy(3) triggers a false warning from static
>   analysers that are less intelligent than humans, and reducing the
>   number of these false hits helps us notice real issues.  A few
>   calls to strcpy(3) in "git rerere" that are already safe has been
>   rewritten to avoid false wanings.

The above two messages are very similar, only the end differs a bit. Perhaps
merge them into one? I.e.. "A few calls to strcpy(3) in test-path-utils and "git rerere" that [...]"

Also: wanings -> warnings

[...]

> 
> * Asking gitweb for a nonexistent commit left a warning in the server
>   log.
> 
>   Somebody may want to follow this up with an additional test, perhaps?
>   IIRC, we do test that no Perl warnings are given to the server log,
>   so this should have been caught if our test coverage were good.

That last paragraph seems odd for a changelog?

[...]

> * The underlying machinery used by "ls-files -o" and other commands
>   have been taught not to create empty submodule ref cache for a

have -> has (the machinery is singular)





Cheers,
Max

Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber]

Hi Junio,

Have you pulled git.pot for 2.8.0 already? [1]

Maybe I'm not up-to-date on the release cycle timing regarding l10n, but
I was trying to fix a mixed translation/non-translation issue, and it
turned out the reason is probably that it is not in "git.pot":

"behind " is in git.pot
"ahead " is not in git.pot

Now, I can recreate git.pot locally, of course, but localisations such
as de.po seem to have those translation commented out because they're
missing from git.pot.

Basically, translations don't get proper testing at this point in the
release cycle.

In fact, there seems to be another weird problem around that string.
I'll follow up with a patch in a minute.

Michael

[1] http://permalink.gmane.org/gmane.comp.version-control.git/287774

[PATCH] wt-status: allow "ahead " to be picked up by l10n

[Michael J Gruber]

The extra pair of parentheses keeps the l10n engine from picking up the
string. Remove them so that "ahead " ends up in git.pot.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 wt-status.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index ab4f80d..ef74864 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1677,10 +1677,10 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
 		color_fprintf(s->fp, header_color, LABEL(N_("behind ")));
 		color_fprintf(s->fp, branch_color_remote, "%d", num_theirs);
 	} else if (!num_theirs) {
-		color_fprintf(s->fp, header_color, LABEL(N_(("ahead "))));
+		color_fprintf(s->fp, header_color, LABEL(N_("ahead ")));
 		color_fprintf(s->fp, branch_color_local, "%d", num_ours);
 	} else {
-		color_fprintf(s->fp, header_color, LABEL(N_(("ahead "))));
+		color_fprintf(s->fp, header_color, LABEL(N_("ahead ")));
 		color_fprintf(s->fp, branch_color_local, "%d", num_ours);
 		color_fprintf(s->fp, header_color, ", %s", LABEL(N_("behind ")));
 		color_fprintf(s->fp, branch_color_remote, "%d", num_theirs);
-- 
2.8.0.rc2.197.g3b88641.dirty

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Have you pulled git.pot for 2.8.0 already? [1]

Thanks for bringing this up.

No, I never pull the "git.pot round N for release" myself, as I am
not working on any translations, and I expect that translation teams
work off of i18n coordinator's tree (i.e. Jiang's tree), not from
mine.  The updated git.pot would come to me along with the new
translations via his tree.

But if it makes it easier for translations teams and the i18n
coordinator to work together if I also pulled the git.pot update
myself, I'll do so.  I just didn't know (and still don't know) if
that makes things easier for you guys, or if that risks making
things more confusing, having to or being able to pull from two
trees that are not necessarily in sync down to the minute.

> [1] http://permalink.gmane.org/gmane.comp.version-control.git/287774

Re: [PATCH] wt-status: allow "ahead " to be picked up by l10n

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> The extra pair of parentheses keeps the l10n engine from picking up the
> string. Remove them so that "ahead " ends up in git.pot.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---

Thanks, will apply.

>  wt-status.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index ab4f80d..ef74864 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1677,10 +1677,10 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
>  		color_fprintf(s->fp, header_color, LABEL(N_("behind ")));
>  		color_fprintf(s->fp, branch_color_remote, "%d", num_theirs);
>  	} else if (!num_theirs) {
> -		color_fprintf(s->fp, header_color, LABEL(N_(("ahead "))));
> +		color_fprintf(s->fp, header_color, LABEL(N_("ahead ")));
>  		color_fprintf(s->fp, branch_color_local, "%d", num_ours);
>  	} else {
> -		color_fprintf(s->fp, header_color, LABEL(N_(("ahead "))));
> +		color_fprintf(s->fp, header_color, LABEL(N_("ahead ")));
>  		color_fprintf(s->fp, branch_color_local, "%d", num_ours);
>  		color_fprintf(s->fp, header_color, ", %s", LABEL(N_("behind ")));
>  		color_fprintf(s->fp, branch_color_remote, "%d", num_theirs);

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> But if it makes it easier for translations teams and the i18n
> coordinator to work together if I also pulled the git.pot update
> myself, I'll do so.  I just didn't know (and still don't know) if
> that makes things easier for you guys, or if that risks making
> things more confusing, having to or being able to pull from two
> trees that are not necessarily in sync down to the minute.

So, please just tell me to pull it myself too, if it makes the life
of i18n team and the coordinator easier.

Thanks.

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Max Horn <max@quendi.de> writes:

>> On 11 Mar 2016, at 00:04, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> * "branch --delete" has "branch -d" but "push --delete" does not.
>
> This states a problem, but not whether (and how) it was resolved?

Thanks; how about

 * "push" learned that its "--delete" option can be shortened to
   "-d", just like "branch --delete" and "branch -d" are the same
   thing.

>> * Across the transition at around Git version 2.0, the user used to
>>   get a pretty loud warning when running "git push" without setting
>>   push.default configuration variable.  We no longer warn, given that
>>   the transition is over long time ago.
>
> That last sentence sounds weird... perhaps "the transition was
> completed a long time ago" ? Or "the transition ended a long time
> ago" ?

 * ... We no longer warn because the transition was completed a long
   time ago.

>> * A slight update to the Makefile to mark "phoney" targets
>>   as such correctly.
>
> phoney -> phony?

Thanks for sharp eyes.

>> * Some calls to strcpy(3) triggers a false warning from static
>>   analysers that are less intelligent than humans, and reducing the
>>   number of these false hits helps us notice real issues.  A few
>>   calls to strcpy(3) in test-path-utils that are already safe has
>>   been rewritten to avoid false wanings.
>> 
>> * Some calls to strcpy(3) triggers a false warning from static
>>   analysers that are less intelligent than humans, and reducing the
>>   number of these false hits helps us notice real issues.  A few
>>   calls to strcpy(3) in "git rerere" that are already safe has been
>>   rewritten to avoid false wanings.
>
> The above two messages are very similar, only the end differs a bit.

That's deliberate as they are two different fixes to a similar
problems.  We can just omit the names of the components to make them
into one entry if we really wanted to.

>> * Asking gitweb for a nonexistent commit left a warning in the server
>>   log.
>> 
>>   Somebody may want to follow this up with an additional test, perhaps?
>>   IIRC, we do test that no Perl warnings are given to the server log,
>>   so this should have been caught if our test coverage were good.
>
> That last paragraph seems odd for a changelog?

I do not think it is wrong to leave a reminder to ourselves that
there are yet more work need to be done.

>> * The underlying machinery used by "ls-files -o" and other commands
>>   have been taught not to create empty submodule ref cache for a
>
> have -> has (the machinery is singular)

Again, thanks for sharp eyes.

Re: [ANNOUNCE] Git v2.8.0-rc2

[Jiang Xin]

2016-03-14 23:29 GMT+08:00 Michael J Gruber <git@drmicha.warpmail.net>:
> Hi Junio,
>
> Have you pulled git.pot for 2.8.0 already? [1]
>
> Maybe I'm not up-to-date on the release cycle timing regarding l10n, but
> I was trying to fix a mixed translation/non-translation issue, and it
> turned out the reason is probably that it is not in "git.pot":
>
> "behind " is in git.pot
> "ahead " is not in git.pot

Yes, I find your commit has just been merged in the master branch, and
it brings one extra message to be translated in Git v2.8.0 l10n.

So let's start round #3 of l10n for Git 2.8.0 to make it perfect.

> Now, I can recreate git.pot locally, of course, but localisations such
> as de.po seem to have those translation commented out because they're
> missing from git.pot.
>
> Basically, translations don't get proper testing at this point in the
> release cycle.

I will send a pull request to Junio right now, and you can test it on
a updated git.pot.


-- 
Jiang Xin

Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 14.03.2016 18:47:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> But if it makes it easier for translations teams and the i18n
>> coordinator to work together if I also pulled the git.pot update
>> myself, I'll do so.  I just didn't know (and still don't know) if
>> that makes things easier for you guys, or if that risks making
>> things more confusing, having to or being able to pull from two
>> trees that are not necessarily in sync down to the minute.
> 
> So, please just tell me to pull it myself too, if it makes the life
> of i18n team and the coordinator easier.
> 
> Thanks.
> 

I don't know about the workflow in general. I'll write up what triggered
my question: I was looking at the FAQ "how do I display the current
branch in git" and into ways to provide some ui (think "git status -sb",
the "+"-line in "git branch"), when I found the problematic output. The
multiple parentheses looked suspicious to me, but given the many levels
of macro expansion I wasn't sure, and simply patching the parentheses
didn't help either. It needed a combination of "make pot" and "msgmerge
...", and the fact that the last merge of git.pot was from 2.7.0-rc
triggered my request to merge what we have.

In hindsight, what happened must have been like this:

"ahead " was marked properly for l10n and translated in the past.

7a76c28 (status: disable translation when --porcelain is used,
2014-03-20) introduced those extra parentheses. Matthieu probably didn't
rerun "make pot" and "msgmerge" so that he didn't notice the consequences.

When Jian ran "make pot" the "ahead "-entry got removed from git.pot:
5e078fc (l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed), 2014-04-19)

When translators ran "msgmerge" with the new git.pot the existing "ahead
"-entry got commented out, for example here for de.po:
74c17bb (l10n: de.po: translate 45 new messages, 2014-04-01)

I'm actually wondering why I didn't notice this much earlier. I don't
know which workflow would have prevented this either. Maybe, since we
have "make pot", we should also have "make l10n" or something to make it
(even) easier for non-l10n-experts to check whether they introduced any
problems.

Strictly speaking, every source file with i18n markup should trigger a
"make pot" (and make l10n) when changed, but there's probably a good
reason why we don't do that.

Michael

Re: [ANNOUNCE] Git v2.8.0-rc2

[Duy Nguyen]

On Wed, Mar 16, 2016 at 8:33 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> In hindsight, what happened must have been like this:
>
> "ahead " was marked properly for l10n and translated in the past.
>
> 7a76c28 (status: disable translation when --porcelain is used,
> 2014-03-20) introduced those extra parentheses. Matthieu probably didn't
> rerun "make pot" and "msgmerge" so that he didn't notice the consequences.

.po(t) files are _very_ noisy because they record line numbers and
that pretty much guarantees huge diffs. Even I as a former translator
do not want to "make pot" and see the differences. If only msgmerge
supports an output without line numbers...
-- 
Duy

Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber]

Duy Nguyen venit, vidit, dixit 16.03.2016 14:40:
> On Wed, Mar 16, 2016 at 8:33 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> In hindsight, what happened must have been like this:
>>
>> "ahead " was marked properly for l10n and translated in the past.
>>
>> 7a76c28 (status: disable translation when --porcelain is used,
>> 2014-03-20) introduced those extra parentheses. Matthieu probably didn't
>> rerun "make pot" and "msgmerge" so that he didn't notice the consequences.
> 
> .po(t) files are _very_ noisy because they record line numbers and
> that pretty much guarantees huge diffs. Even I as a former translator
> do not want to "make pot" and see the differences. If only msgmerge
> supports an output without line numbers...
> 

echo '*.po diff=po' >>.gitattributes
echo '*.pot diff=po' >>.gitattributes
git config diff.po.textconv "msgcat --indent --no-location"

With or without the indent, that gives a pretty clean diff. [It's
unfortunate that one half of that config is in-tree, one-half is not.]

The way it currently is, "non-l10n" coders don't even notice when their
changes affect the set of marked strings. But I guess ususally that's
not a problem.

For our l10n coordinator it is impossible to decide whether a "git.pot"
diff between two runs looks the way it is supposed to look - he would
have to be aware of all code changes that intentionally change the
marked strings. (Likewise, for the translators.)

So, really, the "actual coders" know best whether their changes should
affect l10n or not, so they should be made more aware of it. Forcing
"make pot" (and maybe more) on everyone sounds a bit harsh, but what
else can we do?

Michael

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> echo '*.po diff=po' >>.gitattributes
> echo '*.pot diff=po' >>.gitattributes
> git config diff.po.textconv "msgcat --indent --no-location"
>
> With or without the indent, that gives a pretty clean diff. [It's
> unfortunate that one half of that config is in-tree, one-half is not.]

That's a good tip. [By the way, it is not unfortunate that these are
separated to two places, but quite the opposite.  Attributes define
"what kind of things" they are, and configuration defines "how" each
kind of things are handled.  "msgcat" may have to be invoked
differently from yours on other people's systems, and one level of
indirection is a reasonable way to allow customizing "how" part
without forcing people to rewrite all of THIS in "for *.po do THIS,
for *.pot do THIS too".  You should be thankful for this separation.]

> So, really, the "actual coders" know best whether their changes should
> affect l10n or not, so they should be made more aware of it. Forcing
> "make pot" (and maybe more) on everyone sounds a bit harsh, but what
> else can we do?

I am not sure what problem you are trying to solve.  Do you want to
make sure mismarking such as N_(("foo")) is caught by the person who
changes "foo" into N_(("foo"))?

"make pot" alone would obviously not help, and you would definitely
need "maybe more" but I'd imagine that would involve checking the
diff in the code part i.e. "we have a new N_(...)" against the
differences in git.pot files you would obtain by running "make pot"
before the code change and after the code change, i.e. "there is no
new mention of "foo"".

I do not think you are suggesting to commit the result of "make pot"
along with code changes, but if you are, please don't ;-)

Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 16.03.2016 17:30:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> echo '*.po diff=po' >>.gitattributes
>> echo '*.pot diff=po' >>.gitattributes
>> git config diff.po.textconv "msgcat --indent --no-location"
>>
>> With or without the indent, that gives a pretty clean diff. [It's
>> unfortunate that one half of that config is in-tree, one-half is not.]
> 
> That's a good tip. [By the way, it is not unfortunate that these are
> separated to two places, but quite the opposite.  Attributes define
> "what kind of things" they are, and configuration defines "how" each
> kind of things are handled.  "msgcat" may have to be invoked
> differently from yours on other people's systems, and one level of
> indirection is a reasonable way to allow customizing "how" part
> without forcing people to rewrite all of THIS in "for *.po do THIS,
> for *.pot do THIS too".  You should be thankful for this separation.]

I know why we have that. It's just unfortunate that we can't even
provide a default textconfig config easily - I know very well we can't
have that securely.

"Unfortunate" is meant in this context in the sense: I want to make it
easy and convenient for non-l10n-people to watch out for l10-affecting
changes.

>> So, really, the "actual coders" know best whether their changes should
>> affect l10n or not, so they should be made more aware of it. Forcing
>> "make pot" (and maybe more) on everyone sounds a bit harsh, but what
>> else can we do?
> 
> I am not sure what problem you are trying to solve.  Do you want to
> make sure mismarking such as N_(("foo")) is caught by the person who
> changes "foo" into N_(("foo"))?

Yes. That and similar ones.

> "make pot" alone would obviously not help, and you would definitely
> need "maybe more" but I'd imagine that would involve checking the
> diff in the code part i.e. "we have a new N_(...)" against the
> differences in git.pot files you would obtain by running "make pot"
> before the code change and after the code change, i.e. "there is no
> new mention of "foo"".
> 
> I do not think you are suggesting to commit the result of "make pot"
> along with code changes, but if you are, please don't ;-)

As I said: I assume there's a good reason we don't do that, and that's
why I'm not suggesting it.

On the other hand, it means that the in-tree git.pot does not correlate
with the in-tree source code at all, which feels really weird[*]. And it
makes it difficult to check the impact of your code changes: You can't
simply run "make pot" and check the diff - because the in-tree git.pot
does not reflect the state before your changes at all.

[*] It just feels wrong to me that a "make pot" in a clean checkout
leads to dirty index.

So, in short, I do believe there is a good reason for the "out of sync"
git.pot. That doesn't make the negative side effect that I describe any
less true, and I'm looking for ways to ammeliorate that. Something as
easy as "make check" or "make test-lint".

Michael

[RFC/PATCH] Makefile: allow po generation through po target

[Michael J Gruber]

The main Makefile has a "pot" target that recreates the git.pot file of
strings which are marked for translation.

Add a "po" target that recreates the $(LANGUAGE).po files which contain
the translations (or stubs).

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---

Notes:
    This makes it easier to recreate po (and mo) without reading po/README.
    Alternatively, one may think about a Makefile in po/ which does both pot
    and po updates, just like we have makefiles in t/ and Ducumentation/.
    
    This doesn't give you proper before-after diffs yet, but at least the after
    state.

 Makefile | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Makefile b/Makefile
index 24bef8d..bb60a34 100644
--- a/Makefile
+++ b/Makefile
@@ -445,6 +445,7 @@ TCL_PATH = tclsh
 TCLTK_PATH = wish
 XGETTEXT = xgettext
 MSGFMT = msgfmt
+MSGMERGE = msgmerge
 CURL_CONFIG = curl-config
 PTHREAD_LIBS = -lpthread
 PTHREAD_CFLAGS =
@@ -1514,6 +1515,7 @@ ifndef V
 	QUIET_LNCP     = @echo '   ' LN/CP $@;
 	QUIET_XGETTEXT = @echo '   ' XGETTEXT $@;
 	QUIET_MSGFMT   = @echo '   ' MSGFMT $@;
+	QUIET_MSGMERGE = @echo '   ' MSGMERGE $@;
 	QUIET_GCOV     = @echo '   ' GCOV $@;
 	QUIET_SP       = @echo '   ' SP $<;
 	QUIET_RC       = @echo '   ' RC $@;
@@ -2088,6 +2090,9 @@ pot: po/git.pot
 POFILES := $(wildcard po/*.po)
 MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES))
 
+.PHONY: po
+po: $(POFILES)
+
 ifndef NO_GETTEXT
 all:: $(MOFILES)
 endif
@@ -2095,6 +2100,9 @@ endif
 po/build/locale/%/LC_MESSAGES/git.mo: po/%.po
 	$(QUIET_MSGFMT)mkdir -p $(dir $@) && $(MSGFMT) -o $@ $<
 
+po/%.po: po/git.pot
+	$(QUIET_MSGMERGE)$(MSGMERGE) --add-location --backup=off -q -U $@ $<
+
 FIND_SOURCE_FILES = ( git ls-files '*.[hcS]' 2>/dev/null || \
 			$(FIND) . \( -name .git -type d -prune \) \
 				-o \( -name '*.[hcS]' -type f -print \) )
-- 
2.8.0.rc2.197.g3b88641.dirty

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> So, in short, I do believe there is a good reason for the "out of sync"
> git.pot. That doesn't make the negative side effect that I describe any
> less true, and I'm looking for ways to ammeliorate that. Something as
> easy as "make check" or "make test-lint".

Yes, I agree fully with the last sentence.  I think the task
probably needs two building blocks:

 - A tool to generate up-to-date git.pot contents and store into a
   given filename.

 - A tool that can be used to compare two versions of a .pot file,
   stored as two separate files in the filesystem, without the noise
   that comes from auto-generator (e.g. line numbers, the difference
   of line-wrapping the same messge).

With that, a user can (1) run the former and save the result in
git.pot-before-change before making any change (2) do her work, (3)
run the former again and save the result in git.pot-after-change,
and (4) run the latter between these two.

This is a bit hard to drive from the Makefile, though, as our
Makefile cannot assume people are using Git (they may be working off
of a tarball extract to produce a one-liner patch), and there is the
issue of "then how do we ensure that the user runs the former first
on prestine before starting to hack so that later the result can be
compared?"

But just like the version number generation, it is OK for some
targets to be optional, so perhaps it is OK for this "view pot
changes" task is limited to those who work on their own clone of
Git.  If we add that assumption, then the Makefile target for
"view-pot-changes" would

 - see if untracked file git.pot-$(git rev-parse HEAD) exists (treat
   this as a build artifact, like *.o files).  If it does not exist:

  - check out HEAD to a temporary location elsewhere on the
    filesystem;

  - run the first tool and store the result in the above file.

 - run the first tool in the working tree and store the result in
   another file git.pot-now (treat this file as a build artifact,
   too).

 - run the second tool on these two git.pot files.

Add "git.pot-*" to our .gitignore file, and make sure "make clean"
removes them.

Re: [RFC/PATCH] Makefile: allow po generation through po target

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> The main Makefile has a "pot" target that recreates the git.pot file of
> strings which are marked for translation.
>
> Add a "po" target that recreates the $(LANGUAGE).po files which contain
> the translations (or stubs).
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>
> Notes:
>     This makes it easier to recreate po (and mo) without reading po/README.
>     Alternatively, one may think about a Makefile in po/ which does both pot
>     and po updates, just like we have makefiles in t/ and Ducumentation/.
>     
>     This doesn't give you proper before-after diffs yet, but at least the after
>     state.

More seriously, the "before state" does not exist anywhere, because
*.po and *.pot are expected not to be in sync with the source, and
after a code developer runs "make po", because she does not know all
the languages we have *.po for, she has to "git checkout" to erase
the changes made by "make po".

So while your starting discussion (i.e. RFC-ness of this patch) is
very much appreciated, I do not think this is a good change we would
want to base further work on top.  For "before-after-diff" purposes,
the targets for before and after should drop their output in an
untracked build artifact, instead of overwriting tracked files, I
would think.

Re: [ANNOUNCE] Git v2.8.0-rc2

[Jiang Xin]

2016-03-16 21:33 GMT+08:00 Michael J Gruber <git@drmicha.warpmail.net>:
> Junio C Hamano venit, vidit, dixit 14.03.2016 18:47:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> But if it makes it easier for translations teams and the i18n
>>> coordinator to work together if I also pulled the git.pot update
>>> myself, I'll do so.  I just didn't know (and still don't know) if
>>> that makes things easier for you guys, or if that risks making
>>> things more confusing, having to or being able to pull from two
>>> trees that are not necessarily in sync down to the minute.
>>
>> So, please just tell me to pull it myself too, if it makes the life
>> of i18n team and the coordinator easier.
>>
>> Thanks.
>>
>
> I don't know about the workflow in general. I'll write up what triggered
> my question: I was looking at the FAQ "how do I display the current
> branch in git" and into ways to provide some ui (think "git status -sb",
> the "+"-line in "git branch"), when I found the problematic output. The
> multiple parentheses looked suspicious to me, but given the many levels
> of macro expansion I wasn't sure, and simply patching the parentheses
> didn't help either. It needed a combination of "make pot" and "msgmerge
> ...", and the fact that the last merge of git.pot was from 2.7.0-rc
> triggered my request to merge what we have.
>
> In hindsight, what happened must have been like this:
>
> "ahead " was marked properly for l10n and translated in the past.
>
> 7a76c28 (status: disable translation when --porcelain is used,
> 2014-03-20) introduced those extra parentheses. Matthieu probably didn't
> rerun "make pot" and "msgmerge" so that he didn't notice the consequences.
>
> When Jian ran "make pot" the "ahead "-entry got removed from git.pot:
> 5e078fc (l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed), 2014-04-19)
>
> When translators ran "msgmerge" with the new git.pot the existing "ahead
> "-entry got commented out, for example here for de.po:
> 74c17bb (l10n: de.po: translate 45 new messages, 2014-04-01)
>
> I'm actually wondering why I didn't notice this much earlier. I don't
> know which workflow would have prevented this either. Maybe, since we
> have "make pot", we should also have "make l10n" or something to make it
> (even) easier for non-l10n-experts to check whether they introduced any
> problems.
>
> Strictly speaking, every source file with i18n markup should trigger a
> "make pot" (and make l10n) when changed, but there's probably a good
> reason why we don't do that.

How about this?  We can make a website (host on github) to show i18n
changes. Homepage is just a markdown page, list no-merge commits
which introduced i18n changes. So we don't have to change the workflow.

1. A local git clone, keep update with upstream.
2. Give a starting point, and generate a no-merge commit list.
3. Scan through local git clone and generate a pot file for each
    commit and its parent commit, and save them in cache (by hard
    link to save disk space).
4. Generate diffs for each commit.
5. Generate the MarkDown web page through a template.
6. Commit the changes of the markdown page, and push to github.

-- 
Jiang Xin

Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber]

2016-03-20 10:45 GMT+01:00 Jiang Xin <worldhello.net@gmail.com>:
> 2016-03-16 21:33 GMT+08:00 Michael J Gruber <git@drmicha.warpmail.net>:
>> Junio C Hamano venit, vidit, dixit 14.03.2016 18:47:
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> But if it makes it easier for translations teams and the i18n
>>>> coordinator to work together if I also pulled the git.pot update
>>>> myself, I'll do so.  I just didn't know (and still don't know) if
>>>> that makes things easier for you guys, or if that risks making
>>>> things more confusing, having to or being able to pull from two
>>>> trees that are not necessarily in sync down to the minute.
>>>
>>> So, please just tell me to pull it myself too, if it makes the life
>>> of i18n team and the coordinator easier.
>>>
>>> Thanks.
>>>
>>
>> I don't know about the workflow in general. I'll write up what triggered
>> my question: I was looking at the FAQ "how do I display the current
>> branch in git" and into ways to provide some ui (think "git status -sb",
>> the "+"-line in "git branch"), when I found the problematic output. The
>> multiple parentheses looked suspicious to me, but given the many levels
>> of macro expansion I wasn't sure, and simply patching the parentheses
>> didn't help either. It needed a combination of "make pot" and "msgmerge
>> ...", and the fact that the last merge of git.pot was from 2.7.0-rc
>> triggered my request to merge what we have.
>>
>> In hindsight, what happened must have been like this:
>>
>> "ahead " was marked properly for l10n and translated in the past.
>>
>> 7a76c28 (status: disable translation when --porcelain is used,
>> 2014-03-20) introduced those extra parentheses. Matthieu probably didn't
>> rerun "make pot" and "msgmerge" so that he didn't notice the consequences.
>>
>> When Jian ran "make pot" the "ahead "-entry got removed from git.pot:
>> 5e078fc (l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed), 2014-04-19)
>>
>> When translators ran "msgmerge" with the new git.pot the existing "ahead
>> "-entry got commented out, for example here for de.po:
>> 74c17bb (l10n: de.po: translate 45 new messages, 2014-04-01)
>>
>> I'm actually wondering why I didn't notice this much earlier. I don't
>> know which workflow would have prevented this either. Maybe, since we
>> have "make pot", we should also have "make l10n" or something to make it
>> (even) easier for non-l10n-experts to check whether they introduced any
>> problems.
>>
>> Strictly speaking, every source file with i18n markup should trigger a
>> "make pot" (and make l10n) when changed, but there's probably a good
>> reason why we don't do that.
>
> How about this?  We can make a website (host on github) to show i18n
> changes. Homepage is just a markdown page, list no-merge commits
> which introduced i18n changes. So we don't have to change the workflow.
>
> 1. A local git clone, keep update with upstream.
> 2. Give a starting point, and generate a no-merge commit list.
> 3. Scan through local git clone and generate a pot file for each
>     commit and its parent commit, and save them in cache (by hard
>     link to save disk space).
> 4. Generate diffs for each commit.
> 5. Generate the MarkDown web page through a template.
> 6. Commit the changes of the markdown page, and push to github.
>
> --
> Jiang Xin

I think this is a general question about how to track build products.
The proper place may be in a tree that is referenced from a note or
so.
Maybe I shouldn't consider git.pot a build product - I don't know, as
I honestly don't know why we treat it the way we do.
I could understand if we don't track it all, or if we regnerate it
from "make all" and track the result. We do track it but let it go
stale. There must be a good reason for that, it's just that I don't
know it.

Maybe the problem that I'm trying to solve appears rare enough to not
warrant a solution...

The question of how to track build products (such as pdf compiled from
LaTeX) properly may be a more general one, more deserving a solution.

Michael

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> I think this is a general question about how to track build
> products.  The proper place may be in a tree that is referenced
> from a note or so.

> Maybe I shouldn't consider git.pot a build product - I don't know,
> as I honestly don't know why we treat it the way we do.

I think your LaTeX output analogy is interesting.  When working with
other people editing a single document, each person may update the
build product (.dvi or .pdf or whatever) in his branch and when you
merge other people's work, this would create an unresolvable mess
but that is perfectly fine, because you wouldn't even attempt to
merge the build product.  Instead, you would merge the source
material, run the formatter, and pretend as if its output is the
result of the merging of .dvi or .pdf or whatever.

But then we need to step back and consider the reason why we keep
the build product in the first place.  Presumably that is to help
those who want to consume the build product without having the
toolchain to build from the source.  If that is the case, perhaps it
is also a valid workflow for these collaborating authors of a single
document not to update the build product, if they know that nobody
cares about how the final output looks like on their individual
fork, until their work is merged to some "mainline".

The primary consumers of git.pot build product are the l10n teams,
and I do not think that they want to (or it is practical to ask them
to) work on translating new messages on individual topics code-side
people work on.  So perhaps it is a valid workflow to leave git.pot
behind until i18n coordinator declares "it is time to catch up" and
regenerates it at some "snapshot" time in the development cycle.

Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 21.03.2016 21:01:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> I think this is a general question about how to track build
>> products.  The proper place may be in a tree that is referenced
>> from a note or so.
> 
>> Maybe I shouldn't consider git.pot a build product - I don't know,
>> as I honestly don't know why we treat it the way we do.
> 
> I think your LaTeX output analogy is interesting.  When working with
> other people editing a single document, each person may update the
> build product (.dvi or .pdf or whatever) in his branch and when you
> merge other people's work, this would create an unresolvable mess
> but that is perfectly fine, because you wouldn't even attempt to
> merge the build product.  Instead, you would merge the source
> material, run the formatter, and pretend as if its output is the
> result of the merging of .dvi or .pdf or whatever.

I have to confess that that is actually my main use of git outside of
git.git, and that my "solution" is tracking .pdf etc. and using a
pre-commit (and pre-merge) hook that prevents me from commiting a state
where "make -q" is not successful. Still not perfect, partly due to the
fact that make is timestamp based, not checksum based. ("Use scons", I
know...)

> But then we need to step back and consider the reason why we keep
> the build product in the first place.  Presumably that is to help
> those who want to consume the build product without having the
> toolchain to build from the source. 

That is certainly a good use case - see, e.g., our documentation. On the
other hand, "make pot" has very light toolchain requirements compared to
"make doc".

Another use case is a "poor man's release accountability" - a build
result depends on the actual toolchain version also, not just the
source, and tracking a build stores a copy of a build result that you
handed out in class, deployed somewhere, ...

> If that is the case, perhaps it
> is also a valid workflow for these collaborating authors of a single
> document not to update the build product, if they know that nobody
> cares about how the final output looks like on their individual
> fork, until their work is merged to some "mainline".

Wouldn't that reasoning imply that there's no point in tracking at all?
That is, in tracking in the main tree.

> The primary consumers of git.pot build product are the l10n teams,
> and I do not think that they want to (or it is practical to ask them
> to) work on translating new messages on individual topics code-side
> people work on.  So perhaps it is a valid workflow to leave git.pot
> behind until i18n coordinator declares "it is time to catch up" and
> regenerates it at some "snapshot" time in the development cycle.

Yes, I just think that "git.pot" in the main tree sends a wrong signal
because it is out of sync in the sense that it is not "make pot"-clean.
The main tree is the place for snapshots (especially not non-rolling
ones). Possible alternatives:

- Do not track git.pot at all.
It can be recreated easily, and (unless I'm horribly mistaken) only l10n
people need it ; everyone else needs the .po files, or rather .mo.

- Make po/ a submodule.
Submodules are exactly our way of stating "this depends on a tree with a
separate history and/or different release cycle; commit bar in the super
project is 'based' on commit foo in the submodule (but not the other way
round!)

- Do it like the extra prebuild doc-branches.

- Snapshot with tags (similar to github releases).

With current master at 047057b, the contained git.pot is actually not
(guaranteed to be) the one containing the translatable strings from that
tree. If you want to find out which one, you'd have to "git log -1
po/git.pot" and rely on the fact that Jiang's tree actually does keep
git.pot in-sync.

Somehow, submodules seem to best represent that one-way dependency. (I'm
not a submodule user at all.)

Michael

P.S.: git.pot is both a build product as well as a build/install
requirement, so my tex/pdf analogy does not apply fully.

Re: [ANNOUNCE] Git v2.8.0-rc2

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Junio C Hamano venit, vidit, dixit 21.03.2016 21:01:
>
>> If that is the case, perhaps it
>> is also a valid workflow for these collaborating authors of a single
>> document not to update the build product, if they know that nobody
>> cares about how the final output looks like on their individual
>> fork, until their work is merged to some "mainline".
>
> Wouldn't that reasoning imply that there's no point in tracking at all?
> That is, in tracking in the main tree.

Not really.

    >> ... this would create an unresolvable mess
    >> but that is perfectly fine, because you wouldn't even attempt to
    >> merge the build product.  Instead, you would merge the source
    >> material, run the formatter, and pretend as if its output is the
    >> result of the merging of .dvi or .pdf or whatever.

declares "there is no point in tracking at all" for them while
working on their document.  These authors may realize that there is
no point in tracking the build product in order for them to work
together.  And that may lead them to adopt a workflow where they
leave the build product stale on their individual fork.

It is perfectly fine for them to have a (different) reason why they
may still want to keep the build product tracked and kept up-to-date
on the mainline (e.g. they want to give an easy access to non
authors the final document), even after they realize that tracking
build product would not help _their_ work.