What's cooking in git.git (Oct 2010, #01; Wed, 13)

What's cooking in git.git (Oct 2010, #01; Wed, 13)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.

--------------------------------------------------
[Graduated to "master"]

* ab/makefile-track-cc (2010-09-12) 1 commit
  (merged to 'next' on 2010-09-27 at 51daee0)
 + Makefile: add CC to TRACK_CFLAGS

* bc/fix-cherry-pick-root (2010-09-27) 1 commit
  (merged to 'next' on 2010-09-27 at e27f4c9)
 + builtin/revert.c: don't dereference a NULL pointer

* cw/gitweb-hilite-config (2010-09-21) 1 commit
  (merged to 'next' on 2010-09-27 at dd234ba)
 + Enable highlight executable path as a configuration option

* jk/repack-reuse-object (2010-09-27) 2 commits
  (merged to 'next' on 2010-09-27 at 5719f72)
 + Documentation: pack.compression: explain how to recompress
 + repack: add -F flag to let user choose between --no-reuse-delta/object

* mg/reset-doc (2010-09-15) 6 commits
  (merged to 'next' on 2010-09-22 at 2a10b71)
 + git-reset.txt: make modes description more consistent
 + git-reset.txt: point to git-checkout
 + git-reset.txt: use "working tree" consistently
 + git-reset.txt: reset --soft is not a no-op
 + git-reset.txt: reset does not change files in target
 + git-reset.txt: clarify branch vs. branch head

* uk/fix-author-ident-sed-script (2010-09-23) 1 commit
  (merged to 'next' on 2010-09-27 at 5ad7d90)
 + get_author_ident_from_commit(): remove useless quoting

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

* ab/send-email-perl (2010-09-30) 16 commits
  (merged to 'next' on 2010-09-30 at cf8e58e)
 + send-email: extract_valid_address use qr// regexes
 + send-email: is_rfc2047_quoted use qr// regexes
 + send-email: use Perl idioms in while loop
 + send-email: make_message_id use "require" instead of "use"
 + send-email: send_message die on $!, not $?
 + send-email: use (?:) instead of () if no match variables are needed
 + send-email: sanitize_address use qq["foo"], not "\"foo\""
 + send-email: sanitize_address use $foo, not "$foo"
 + send-email: use \E***\Q instead of \*\*\*
 + send-email: cleanup_compose_files doesn't need a prototype
 + send-email: unique_email_list doesn't need a prototype
 + send-email: file_declares_8bit_cte doesn't need a prototype
 + send-email: get_patch_subject doesn't need a prototype
 + send-email: use lexical filehandles during sending
 + send-email: use lexical filehandles for $compose
 + send-email: use lexical filehandle for opendir

* cb/diff-fname-optim (2010-09-26) 3 commits
 - diff: avoid repeated scanning while looking for funcname
 - do not search functions for patch ID
 - add rebase patch id tests

* en/merge-recursive (2010-09-20) 38 commits
 - merge-recursive: Remove redundant path clearing for D/F conflicts
 - merge-recursive: Make room for directories in D/F conflicts
 - handle_delete_modify(): Check whether D/F conflicts are still present
 - merge_content(): Check whether D/F conflicts are still present
 - conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts
 - conflict_rename_delete(): Check whether D/F conflicts are still present
 - merge-recursive: Delay modify/delete conflicts if D/F conflict present
 - merge-recursive: Delay content merging for renames
 - merge-recursive: Delay handling of rename/delete conflicts
 - merge-recursive: Move handling of double rename of one file to other file
 - merge-recursive: Move handling of double rename of one file to two
 - merge-recursive: Avoid doubly merging rename/add conflict contents
 - merge-recursive: Update merge_content() call signature
 - merge-recursive: Update conflict_rename_rename_1to2() call signature
 - merge-recursive: Structure process_df_entry() to handle more cases
 - merge-recursive: Have process_entry() skip D/F or rename entries
 - merge-recursive: New function to assist resolving renames in-core only
 - merge-recursive: New data structures for deferring of D/F conflicts
 - merge-recursive: Move process_entry's content merging into a function
 - merge-recursive: Move delete/modify handling into dedicated function
 - merge-recursive: Move rename/delete handling into dedicated function
 - merge-recursive: Nuke rename/directory conflict detection
 - merge-recursive: Rename conflict_rename_rename*() for clarity
 - merge-recursive: Small code clarification -- variable name and comments
 - t6036: Add testcase for undetected conflict
 - t6036: Add a second testcase similar to the first but with content changes
 - t6036: Test index and worktree state, not just that merge fails
 - t6020: Add a testcase for modify/delete + directory/file conflict
 - t6020: Modernize style a bit
 - t6022: Add tests for rename/rename combined with D/F conflicts
 - t6022: Add paired rename+D/F conflict: (two/file, one/file) -> (one, two)
 - t6022: Add tests with both rename source & dest involved in D/F conflicts
 - t6022: Add tests for reversing order of merges when D/F conflicts present
 - t6022: Add test combinations of {content conflict?, D/F conflict remains?}
 - t6032: Add a test checking for excessive output from merge
 - merge-recursive: Restructure showing how to chain more process_* functions
 - t3030: Add a testcase for resolvable rename/add conflict with symlinks
 - Merge branch 'en/rename-d-f' into en/merge-recursive
 (this branch uses en/rename-d-f.)

* il/remote-fd-ext (2010-10-12) 3 commits
 - git-remote-ext
 - git-remote-fd
 - Add bidirectional_transfer_loop()

* jn/gitweb-test (2010-09-26) 4 commits
 - gitweb/Makefile: Include gitweb/config.mak
 - gitweb/Makefile: Add 'test' and 'test-installed' targets
 - t/gitweb-lib.sh: Add support for GITWEB_TEST_INSTALLED
 - gitweb: Move call to evaluate_git_version after evaluate_gitweb_config

* ak/apply-non-git-epoch (2010-09-29) 1 commit
 - apply: Recognize epoch timestamps with : in the timezone

* ak/submodule-sync (2010-10-08) 1 commit
 - submodule sync: Update "submodule.<name>.url" for empty directories

* cb/leading-path-removal (2010-10-09) 5 commits
 - do not overwrite files in leading path
 - lstat_cache: optionally return match_len
 - add function check_ok_to_remove()
 - t7607: add leading-path tests
 - t7607: use test-lib functions and check MERGE_HEAD

* jh/notes-merge (2010-10-09) 21 commits
 - Provide 'git notes get-ref' to easily retrieve current notes ref
 - git notes merge: Add testcases for merging notes trees at different fanouts
 - git notes merge: Add another auto-resolving strategy: "cat_sort_uniq"
 - git notes merge: --commit should fail if underlying notes ref has moved
 - git notes merge: List conflicting notes in notes merge commit message
 - git notes merge: Manual conflict resolution, part 2/2
 - git notes merge: Manual conflict resolution, part 1/2
 - Documentation: Preliminary docs on 'git notes merge'
 - git notes merge: Add automatic conflict resolvers (ours, theirs, union)
 - git notes merge: Handle real, non-conflicting notes merges
 - builtin/notes.c: Refactor creation of notes commits.
 - git notes merge: Initial implementation handling trivial merges only
 - builtin/notes.c: Split notes ref DWIMmery into a separate function
 - notes.c: Use two newlines (instead of one) when concatenating notes
 - (trivial) t3303: Indent with tabs instead of spaces for consistency
 - notes.h/c: Propagate combine_notes_fn return value to add_note() and beyond
 - notes.h/c: Clarify the handling of notes objects that are == null_sha1
 - notes.c: Reorder functions in preparation for next commit
 - notes.h: Make default_notes_ref() available in notes API
 - (trivial) notes.h: Minor documentation fixes to copy_notes()
 - notes.c: Hexify SHA1 in die() message from init_notes()

Breaks build with arithmetic on (void *).

* jk/maint-rev-list-nul (2010-10-07) 1 commit
 - rev-list: handle %x00 NUL in user format

* jk/push-progress (2010-10-14) 2 commits
 - push: pass --progress down to git-pack-objects
 - t5523-push-upstream: test progress messages

* jm/mailmap (2010-10-11) 1 commit
 - mailmap: fix use of freed memory

The new test seems to make t4203 break intermittently.

* jn/send-pack-error (2010-10-12) 1 commit
 - send-pack: avoid redundant "pack-objects died with strange error"

* kb/completion-checkout (2010-10-12) 1 commit
 - completion: Support the DWIM mode for git checkout

* pn/commit-autosquash (2010-10-07) 8 commits
 - add tests of commit --squash
 - commit: --squash option for use with rebase --autosquash
 - add tests of commit --fixup
 - commit: --fixup option for use with rebase --autosquash
 - pretty.c: teach format_commit_message() to reencode the output
 - pretty.c: helper methods for getting output encodings
 - commit.c: new function for looking up a comit by name
 - commit.c: prefer get_header() to manual searching

* sg/bisect (2010-10-10) 3 commits
 - bisect: check for mandatory argument of 'bisect replay'
 - bisect: improve error msg of 'bisect reset' when original HEAD is deleted
 - bisect: improve error message of 'bisect log' while not bisecting

* sg/completion (2010-10-11) 4 commits
 - bash: support pretty format aliases
 - bash: support more 'git notes' subcommands and their options
 - bash: not all 'git bisect' subcommands make sense when not bisecting
 - bash: offer refs for 'git bisect start'

* sn/doc-opt-notation (2010-10-08) 6 commits
  (merged to 'next' on 2010-10-13 at 53ea256)
 + Fix {update,checkout}-index usage strings
 + Put a space between `<' and argument in pack-objects usage string
 + Remove stray quotes in --pretty and --format documentation
 + Use parentheses and `...' where appropriate
 + Fix odd markup in --diff-filter documentation
 + Use angles for placeholders consistently

* yd/dir-rename (2010-10-10) 5 commits
 - diff --check: correct line numbers of new blank lines at EOF
 - Transfer special display of toplevel dir to display-time.
 - Only show bulkmoves in output.
 - Add testcases for the --detect-bulk-moves diffcore flag.
 - Introduce bulk-move detection in diffcore.

This seems to break the build with decl-after-stmt.

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

* nd/index-doc (2010-09-06) 1 commit
 - doc: technical details about the index file format

Half-written but it is a good start.  I may need to give some help in
describing more recent index extensions.

* by/line-log (2010-09-11) 18 commits
 . log -L: do not free parents lists we might need again
 . Document line history browser
 . Add tests for line history browser
 . Add --full-line-diff option
 . Add --graph prefix before line history output
 . Add parent rewriting to line history browser
 . Make graph_next_line external to other part of git
 . Make rewrite_parents public to other part of git
 . Hook line history into cmd_log, ensuring a topo-ordered walk
 . Print the line log
 . map/take range to the parent of commits
 . Add range clone functions
 . Export three functions from diff.c
 . Parse the -L options
 . Refactor parse_loc
 . Add the basic data structure for line level history
 . parse-options: add two helper functions
 . parse-options: enhance STOP_AT_NON_OPTION

Temporarily ejected to give room to nd/struct-pathspec topic as this
conflicts with it.

* cb/ignored-paths-are-precious (2010-08-21) 1 commit
 - checkout/merge: optionally fail operation when ignored files need to be overwritten

This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.

It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.

* jk/tag-contains (2010-07-05) 4 commits
 - Why is "git tag --contains" so slow?
 - default core.clockskew variable to one day
 - limit "contains" traversals based on commit timestamp
 - tag: speed up --contains calculation

The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.

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

* jj/icase-directory (2010-10-03) 8 commits
 - Support case folding in git fast-import when core.ignorecase=true
 - Support case folding for git add when core.ignorecase=true
 - Add case insensitivity support when using git ls-files
 - Add case insensitivity support for directories when using git status
 - Case insensitivity support for .gitignore via core.ignorecase
 - Add string comparison functions that respect the ignore_case variable.
 - Makefile & configure: add a NO_FNMATCH_CASEFOLD flag
 - Makefile & configure: add a NO_FNMATCH flag

* ab/require-perl-5.8 (2010-09-24) 2 commits
  (merged to 'next' on 2010-09-27 at 1fcdd3c)
 + perl: use "use warnings" instead of -w
 + perl: bump the required Perl version to 5.8 from 5.6.[21]

* en/and-cascade-tests (2010-10-03) 13 commits
 - Introduce sane_unset and use it to ensure proper && chaining
 - t7800 (difftool): add missing &&
 - t7601 (merge-pull-config): add missing &&
 - t7001 (mv): add missing &&
 - t6016 (rev-list-graph-simplify-history): add missing &&
 - t5602 (clone-remote-exec): add missing &&
 - t4026 (color): remove unneeded and unchained command
 - t4019 (diff-wserror): add lots of missing &&
 - t4202 (log): Replace '<git-command> || :' with test_might_fail
 - t4002 (diff-basic): use test_might_fail for commands that might fail
 - t100[12] (read-tree-m-2way, read_tree_m_u_2way): add missing &&
 - t4017 (diff-retval): replace manual exit code check with test_expect_code
 - test-lib: make test_expect_code a test command

Somewhat rerolled, but the largest one among the series was Nacked by a
few people and needs to be rerolled again.

* jk/no-textconv-symlink (2010-09-21) 1 commit
 - diff: don't use pathname-based diff drivers for symlinks
 (this branch is used by ks/no-textconv-symlink.)

* ks/no-textconv-symlink (2010-09-29) 3 commits
 - blame,cat-file --textconv: Don't assume mode is ``S_IFREF | 0664''
 - blame,cat-file: Demonstrate --textconv is wrongly running converter on symlinks
 - blame,cat-file: Prepare --textconv tests for correctly-failing conversion program
 (this branch uses jk/no-textconv-symlink.)

* jp/send-email-to-cmd (2010-09-24) 1 commit
  (merged to 'next' on 2010-09-30 at 4284ddb)
 + git-send-email.perl: Add --to-cmd

* kb/merge-recursive-rename-threshold (2010-09-27) 2 commits
  (merged to 'next' on 2010-09-30 at 4f33817)
 + diff: add synonyms for -M, -C, -B
 + merge-recursive: option to specify rename threshold
 (this branch uses jf/merge-ignore-ws.)

* mg/fix-build-remote-helpers (2010-09-17) 1 commit
  (merged to 'next' on 2010-09-30 at 0583d5f)
 + remote-helpers: build in platform independent directory

* nd/struct-pathspec (2010-09-20) 5 commits
 - ce_path_match: drop prefix matching in favor of match_pathspec
 - Convert ce_path_match() to use struct pathspec
 - tree_entry_interesting: turn to match_pathspec if wildcard is present
 - pathspec: add tree_recursive_diff parameter
 - pathspec: mark wildcard pathspecs from the beginning
 (this branch uses en/object-list-with-pathspec.)

* en/object-list-with-pathspec (2010-09-20) 8 commits
 - Add testcases showing how pathspecs are handled with rev-list --objects
 - Make rev-list --objects work together with pathspecs
 - Move tree_entry_interesting() to tree-walk.c and export it
 - tree_entry_interesting(): remove dependency on struct diff_options
 - Convert struct diff_options to use struct pathspec
 - pathspec: cache string length when initializing pathspec
 - diff-no-index: use diff_tree_setup_paths()
 - Add struct pathspec
 (this branch is used by nd/struct-pathspec.)

* sb/send-email-use-to-from-input (2010-10-04) 2 commits
  (merged to 'next' on 2010-10-06 at 5e9cb61)
 + send-email: Don't leak To: headers between patches
  (merged to 'next' on 2010-09-30 at 513b6f1)
 + send-email: Use To: headers in patch files

* tc/smart-http-post-redirect (2010-09-25) 1 commit
 - smart-http: Don't change POST to GET when following redirect

* as/daemon-multi-listen (2010-08-30) 2 commits
  (merged to 'next' on 2010-09-30 at 8083bf4)
 + daemon: allow more than one host address given via --listen
 + daemon: add helper function named_sock_setup

* dm/mergetool-vimdiff (2010-09-27) 3 commits
  (merged to 'next' on 2010-09-29 at c8e22ea)
 + mergetool-lib: make the three-way diff the default for vim/gvim
  (merged to 'next' on 2010-09-22 at 12f7559)
 + mergetool-lib: add a three-way diff view for vim/gvim
 + mergetool-lib: combine vimdiff and gvimdiff run blocks

* en/rename-d-f (2010-09-08) 2 commits
 - merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir
 - t3509: Add rename + D/F conflict testcase that recursive strategy fails
 (this branch is used by en/merge-recursive.)

* kf/post-receive-sample-hook (2010-09-10) 1 commit
  (merged to 'next' on 2010-09-22 at db674a3)
 + post-receive-email: ensure sent messages are not empty

I notice that it uses "PAGER= generate_email" where generate_email is a
shell function, which may break in some implementations of POSIX /bin/sh.
This is not a regression (the original also had the same issue), but
somebody who cares enough might want to look into it.

* ml/completion-zsh (2010-09-06) 1 commit
  (merged to 'next' on 2010-09-22 at d62d10e)
 + completion: make compatible with zsh

Reported as breaking people with "set -u".

* po/sendemail (2010-09-06) 3 commits
  (merged to 'next' on 2010-09-22 at 1105f62)
 + New send-email option smtpserveroption.
 + Remove @smtp_host_parts variable as not used.
 + Minor indentation fix.

Will merge to 'master' shortly.

* jl/fetch-submodule-recursive (2010-09-19) 4 commits
 - fetch: Get submodule paths from index and not from .gitmodules
 - fetch: Fix a bug swallowing the output of recursive submodule fetching
 - Submodules: Add the new "fetch" config option for fetch and pull
 - fetch/pull: Recursively fetch populated submodules

I haven't picked up the rerolled one yet.

* jf/merge-ignore-ws (2010-08-26) 4 commits
  (merged to 'next' on 2010-09-22 at 5161fb8)
 + merge-recursive: options to ignore whitespace changes
 + merge-recursive --patience
 + ll-merge: replace flag argument with options struct
 + merge-recursive: expose merge options for builtin merge
 (this branch is used by kb/merge-recursive-rename-threshold.)

Possibly one of the star features of the coming release.

* tr/merge-unborn-clobber (2010-08-22) 1 commit
 - Exhibit merge bug that clobbers index&WT

* en/tree-walk-optim (2010-08-26) 4 commits
  (merged to 'next' on 2010-09-22 at 0601f1b)
 + diff_tree(): Skip skip_uninteresting() when all remaining paths interesting
 + tree_entry_interesting(): Make return value more specific
 + tree-walk: Correct bitrotted comment about tree_entry()
 + Document pre-condition for tree_entry_interesting

Will merge to 'master' shortly.

* ab/i18n (2010-09-12) 159 commits
 - po/sv.po: add Swedish translation
 - gettextize: git-bisect bisect_next_check "You need to" message
 - gettextize: git-bisect [Y/n] messages
 - gettextize: git-bisect bisect_replay + $1 messages
 - gettextize: git-bisect bisect_reset + $1 messages
 - gettextize: git-bisect bisect_run + $@ messages
 - gettextize: git-bisect die + eval_gettext messages
 - gettextize: git-bisect die + gettext messages
 - gettextize: git-bisect echo + eval_gettext message
 - gettextize: git-bisect echo + gettext messages
 - gettextize: git-bisect gettext + echo message
 - gettextize: git-bisect add git-sh-i18n
 - gettextize: git-stash drop_stash say/die messages
 - gettextize: git-stash "unknown option" message
 - gettextize: git-stash die + eval_gettext $1 messages
 - gettextize: git-stash die + eval_gettext $* messages
 - gettextize: git-stash die + eval_gettext messages
 - gettextize: git-stash die + gettext messages
 - gettextize: git-stash say + gettext messages
 - gettextize: git-stash echo + gettext message
 - gettextize: git-stash add git-sh-i18n
 - gettextize: git-submodule "blob" and "submodule" messages
 - gettextize: git-submodule "path not initialized" message
 - gettextize: git-submodule "[...] path is ignored" message
 - gettextize: git-submodule "Entering [...]" message
 - gettextize: git-submodule $errmsg messages
 - gettextize: git-submodule "Submodule change[...]" messages
 - gettextize: git-submodule "cached cannot be used" message
 - gettextize: git-submodule $update_module say + die messages
 - gettextize: git-submodule die + eval_gettext messages
 - gettextize: git-submodule say + eval_gettext messages
 - gettextize: git-submodule echo + eval_gettext messages
 - gettextize: git-submodule add git-sh-i18n
 - gettextize: git-pull "rebase against" / "merge with" messages
 - gettextize: git-pull "[...] not currently on a branch" message
 - gettextize: git-pull "You asked to pull" message
 - gettextize: git-pull split up "no candidate" message
 - gettextize: git-pull eval_gettext + warning message
 - gettextize: git-pull eval_gettext + die message
 - gettextize: git-pull die messages
 - gettextize: git-pull add git-sh-i18n
 - gettext docs: add "Testing marked strings" section to po/README
 - gettext docs: the Git::I18N Perl interface
 - gettext docs: the git-sh-i18n.sh Shell interface
 - gettext docs: the gettext.h C interface
 - gettext docs: add "Marking strings for translation" section in po/README
 - gettext docs: add a "Testing your changes" section to po/README
 - po/pl.po: add Polish translation
 - po/hi.po: add Hindi Translation
 - po/en_GB.po: add British English translation
 - po/de.po: add German translation
 - Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
 - gettext docs: add po/README file documenting Git's gettext
 - gettextize: git-am printf(1) message to eval_gettext
 - gettextize: git-am core say messages
 - gettextize: git-am "Apply?" message
 - gettextize: git-am clean_abort messages
 - gettextize: git-am cannot_fallback messages
 - gettextize: git-am die messages
 - gettextize: git-am eval_gettext messages
 - gettextize: git-am multi-line getttext $msg; echo
 - gettextize: git-am one-line gettext $msg; echo
 - gettextize: git-am add git-sh-i18n
 - gettext tests: add GETTEXT_POISON tests for shell scripts
 - gettext tests: add GETTEXT_POISON support for shell scripts
 - Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
 - Makefile: add GNU_GETTEXT, set when we expect GNU gettext
 - gettextize: git-shortlog basic messages
 - gettextize: git-revert split up "could not revert/apply" message
 - gettextize: git-revert literal "me" messages
 - gettextize: git-revert "Your local changes" message
 - gettextize: git-revert basic messages
 - gettextize: git-notes "Refusing to %s notes in %s" message
 - gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
 - gettextize: git-notes basic commands
 - gettextize: git-gc "Auto packing the repository" message
 - gettextize: git-gc basic messages
 - gettextize: git-describe basic messages
 - gettextize: git-clean clean.requireForce messages
 - gettextize: git-clean basic messages
 - gettextize: git-bundle basic messages
 - gettextize: git-archive basic messages
 - gettextize: git-status "renamed: " message
 - gettextize: git-status "Initial commit" message
 - gettextize: git-status "Changes to be committed" message
 - gettextize: git-status shortstatus messages
 - gettextize: git-status "nothing to commit" messages
 - gettextize: git-status basic messages
 - gettextize: git-push "prevent you from losing" message
 - gettextize: git-push basic messages
 - gettextize: git-tag tag_template message
 - gettextize: git-tag basic messages
 - gettextize: git-reset "Unstaged changes after reset" message
 - gettextize: git-reset reset_type_names messages
 - gettextize: git-reset basic messages
 - gettextize: git-rm basic messages
 - gettextize: git-mv "bad" messages
 - gettextize: git-mv basic messages
 - gettextize: git-merge "Wonderful" message
 - gettextize: git-merge "You have not concluded your merge" messages
 - gettextize: git-merge "Updating %s..%s" message
 - gettextize: git-merge basic messages
 - gettextize: git-log "--OPT does not make sense" messages
 - gettextize: git-log basic messages
 - gettextize: git-grep "--open-files-in-pager" message
 - gettextize: git-grep basic messages
 - gettextize: git-fetch split up "(non-fast-forward)" message
 - gettextize: git-fetch update_local_ref messages
 - gettextize: git-fetch formatting messages
 - gettextize: git-fetch basic messages
 - gettextize: git-diff basic messages
 - gettextize: git-commit advice messages
 - gettextize: git-commit "enter the commit message" message
 - gettextize: git-commit print_summary messages
 - gettextize: git-commit formatting messages
 - gettextize: git-commit "middle of a merge" message
 - gettextize: git-commit basic messages
 - gettextize: git-checkout "Switched to a .. branch" message
 - gettextize: git-checkout "HEAD is now at" message
 - gettextize: git-checkout describe_detached_head messages
 - gettextize: git-checkout: our/their version message
 - gettextize: git-checkout basic messages
 - gettextize: git-branch "(no branch)" message
 - gettextize: git-branch "git branch -v" messages
 - gettextize: git-branch "Deleted branch [...]" message
 - gettextize: git-branch "remote branch '%s' not found" message
 - gettextize: git-branch basic messages
 - gettextize: git-add refresh_index message
 - gettextize: git-add "remove '%s'" message
 - gettextize: git-add "pathspec [...] did not match" message
 - gettextize: git-add "Use -f if you really want" message
 - gettextize: git-add "no files added" message
 - gettextize: git-add basic messages
 - gettextize: git-clone "Cloning into" message
 - gettextize: git-clone basic messages
 - gettext tests: test message re-encoding under C
 - po/is.po: add Icelandic translation
 - gettext tests: mark a test message as not needing translation
 - gettext tests: test re-encoding with a UTF-8 msgid under Shell
 - gettext tests: test message re-encoding under Shell
 - gettext tests: add detection for is_IS.ISO-8859-1 locale
 - gettext tests: test if $VERSION exists before using it
 - gettextize: git-init "Initialized [...] repository" message
 - gettextize: git-init basic messages
 - gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
 - gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
 - gettext.c: work around us not using setlocale(LC_CTYPE, "")
 - builtin.h: Include gettext.h
 - Makefile: use variables and shorter lines for xgettext
 - Makefile: tell xgettext(1) that our source is in UTF-8
 - Makefile: provide a --msgid-bugs-address to xgettext(1)
 - Makefile: A variable for options used by xgettext(1) calls
 - gettext tests: locate i18n lib&data correctly under --valgrind
 - gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
 - gettext tests: rename test to work around GNU gettext bug
 - gettext: add infrastructure for translating Git with gettext
 - builtin: use builtin.h for all builtin commands
 - tests: use test_cmp instead of piping to diff(1)
 - t7004-tag.sh: re-arrange git tag comment for clarity

Re: What's cooking in git.git (Oct 2010, #01; Wed, 13)

[Nazri Ramliy]

On Thu, Oct 14, 2010 at 12:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> --------------------------------------------------
> [New Topics]
>
> * ab/send-email-perl (2010-09-30) 16 commits
>  (merged to 'next' on 2010-09-30 at cf8e58e)
>  + send-email: extract_valid_address use qr// regexes
>  + send-email: is_rfc2047_quoted use qr// regexes
>  + send-email: use Perl idioms in while loop

A few of the Signed-off-by and Reviewed-by stanzas in this series are messed up.

Have a look at

    $ git log 9855b0..41ae8f1

Copy and paste error?

nazri

Re: What's cooking in git.git (Oct 2010, #01; Wed, 13)

[Ævar Arnfjörð Bjarmason]

On Thu, Oct 14, 2010 at 04:46, Junio C Hamano <gitster@pobox.com> wrote:

>  - test-lib: make test_expect_code a test command
>
> Somewhat rerolled, but the largest one among the series was Nacked by a
> few people and needs to be rerolled again.

Why did you amend this to use this sed trick:

    +sed -e 's/Z$//' >expect <<\EOF &&
    +not ok - 1 tests clean up even after a failure
    +#      Z
    +#          touch clean-after-failure &&
    +#          test_when_finished rm clean-after-failure &&
    +#          (exit 1)
    +#      Z
    +not ok - 2 failure to clean up causes the test to fail
    +#      Z
    +#          test_when_finished \"(exit 2)\"
    +#      Z

Is it just to keep it diff --check clean?

Anyway if we munge the output like this the output of test_cmp will be
more confusing when it fails, because it'll be diff(1)-ing something
that the test-lib would never emit.

> * ab/i18n (2010-09-12) 159 commits

Could you please pick up the 160 commit version of this at:

    git://github.com/avar/git.git ab/i18n

It has the new "gettext.c: use libcharset.h instead of langinfo.h when
available" patch by Erik Faye-Lund and me, which would be nice to have
tested in pu.

Stable ab/i18n branch

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> Could you please pick up the 160 commit version of this at:
> 
>     git://github.com/avar/git.git ab/i18n

This is a "give an inch and they'll ask for a mile" sort of thing, but
would it be possible to maintain a stable branch with the i18n
infrastructure that only gets rebased when there is reorganization
going on?

The gettextization and translations are rebased for other reasons (to
avoid going crazy), I know.  But with the infrastructure it is starting
to be hard to track what changes over time.

Re: Stable ab/i18n branch

[Ævar Arnfjörð Bjarmason]

On Thu, Oct 14, 2010 at 20:00, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> Could you please pick up the 160 commit version of this at:
>>
>>     git://github.com/avar/git.git ab/i18n
>
> This is a "give an inch and they'll ask for a mile" sort of thing, but
> would it be possible to maintain a stable branch with the i18n
> infrastructure that only gets rebased when there is reorganization
> going on?
>
> The gettextization and translations are rebased for other reasons (to
> avoid going crazy), I know.  But with the infrastructure it is starting
> to be hard to track what changes over time.

I could do that, but I've been hoping that it just gets picked up for
the `next -> master` process of git.git itself and *that* becomes the
stable target.

But I have no idea what's going on at the other end, i.e. there's no
comments about it in the "What's cooking in git.git" posts or
elsewhere. So it's hard to know whether something like this is needed.

It's been about as ready as it's ever going to get for about a month
now. The libcharset.h change that was added to it a week or so ago
could have come on top of the series. But since it hadn't been merged
anywhere I rebased and inserted that earlier in the series for the
relatively obscure case of helping bisectability on Windows.

I'm starting to get the feeling that there isn't much interest in i18n
support at all. It didn't show up highly in the wanted features in the
Git survey, and most of the translations have been contributed by
people I've poked directly.

So maybe I should just get the hint and drop it *shrug*. I don't have
much time to spend on this these days since I've been moving /
starting a new job. So if it's not going to get merged into core I
might as well do something else.

(I'm not being bitter, really. Just practical)

Re: Stable ab/i18n branch

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> I could do that, but I've been hoping that it just gets picked up for
> the `next -> master` process of git.git itself and *that* becomes the
> stable target.
> 
> But I have no idea what's going on at the other end, i.e. there's no
> comments about it in the "What's cooking in git.git" posts or
> elsewhere. So it's hard to know whether something like this is needed.

Probably it is a difference in culture between e.g. the Linux kernel
and other projects.  In the world I'll stereotype as the Linux kernel
world, forks are considered good!  Developments everyone agrees is
good in the long run (like the Linux realtime tree) are not
necessarily merged, for years even, the justification being that
until the _immediate_ benefits for Linus outweigh the risks for Linus,
it just doesn't make sense to merge.

This avoids bloat and bugs from code that is not being used by anyone,
while allowing development to continue to happen.

Now git.git is not the Linux kernel.  In particular, Junio provides
the extra service of a working "proposed updates" branch, including
changes that are not necessarily to be part of the next release.  But
the underlying principle is the same: until there is an _immediate_
benefit to including a feature in releases that does not outweigh
the downsides, it just does not happen.

What that means: interested parties need to start testing the l10n
code.  There should be a reliable upstream for users of this
feature and ideally that should not be Junio unless he wants to (and
Ævar, I think you have been doing a good job of that, just saying it's
valuable).  The code's not going to get into shape otherwise.

> It's been about as ready as it's ever going to get for about a month
> now.

I hope not!  e.g. the LC_CTYPE problems have not been resolved (and yes,
that would be a regression for people using the it_IT.UTF-8 locale).

> I'm starting to get the feeling that there isn't much interest in i18n
> support at all.

I'm interested in it, at least.

Re: Stable ab/i18n branch

[Ævar Arnfjörð Bjarmason]

On Thu, Oct 14, 2010 at 20:54, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> I could do that, but I've been hoping that it just gets picked up for
>> the `next -> master` process of git.git itself and *that* becomes the
>> stable target.
>>
>> But I have no idea what's going on at the other end, i.e. there's no
>> comments about it in the "What's cooking in git.git" posts or
>> elsewhere. So it's hard to know whether something like this is needed.
>
> Probably it is a difference in culture between e.g. the Linux kernel
> and other projects.  In the world I'll stereotype as the Linux kernel
> world, forks are considered good!  Developments everyone agrees is
> good in the long run (like the Linux realtime tree) are not
> necessarily merged, for years even, the justification being that
> until the _immediate_ benefits for Linus outweigh the risks for Linus,
> it just doesn't make sense to merge.
>
> This avoids bloat and bugs from code that is not being used by anyone,
> while allowing development to continue to happen.
>
> Now git.git is not the Linux kernel.  In particular, Junio provides
> the extra service of a working "proposed updates" branch, including
> changes that are not necessarily to be part of the next release.  But
> the underlying principle is the same: until there is an _immediate_
> benefit to including a feature in releases that does not outweigh
> the downsides, it just does not happen.
>
> What that means: interested parties need to start testing the l10n
> code.  There should be a reliable upstream for users of this
> feature and ideally that should not be Junio unless he wants to (and
> Ævar, I think you have been doing a good job of that, just saying it's
> valuable).  The code's not going to get into shape otherwise.

There's definitely a chicken & egg problem here. Unlike what you'd get
in the case of Linux this isn't an unstable device driver that
somebody needs. It's just something that optionally makes life easier
for people that pretty much by definition don't follow this mailing
list.

So it's hard to build an upstream of users. With all other free
software programs that happens by the canonical upstream version of
the program being internationalized. The distros then picking up that
version and give it to end users.

So what I've tried to do to make this acceptable for inclusion in core
is to make this whole thing a no-op unless it's explicitly
requested.

You can skip it altogether with NO_GETTEXT=YesPlease, and even with
NO_GETTEXT= it won't get used unless you've explicitly set LANGUAGE=,
or LC_*= variables accordingly.

Maybe I could do something to make it even less intrusive, e.g. have a
core.i18n=yes config variable. But I haven't gotten any feedback on
that so I've kept the current scheme of making it behave like pretty
much every other internationalized program out there.

>> It's been about as ready as it's ever going to get for about a month
>> now.
>
> I hope not!  e.g. the LC_CTYPE problems have not been resolved (and yes,
> that would be a regression for people using the it_IT.UTF-8 locale).

The LC_CTYPE problems I'm aware of were worked around in this patch:

    gettext.c: work around us not using setlocale(LC_CTYPE, "")

While that's not a perfect solution I think it's the best we're going
to get for the time being. I'm pretty convinced that if I tried to
make git itself LC_CTYPE-safe as part of this already huge series it'd
never get merged. Having messages with question marks from strerror()
on certain platforms is an OK compromise in my opinion.

Are there any other LC_CTYPE related issues I'm overlooking?

>> I'm starting to get the feeling that there isn't much interest in i18n
>> support at all.
>
> I'm interested in it, at least.

That's good to hear.

Re: Stable ab/i18n branch

[Sverre Rabbelier]

Heya,

On Thu, Oct 14, 2010 at 23:18, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Thu, Oct 14, 2010 at 20:54, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> I'm interested in it, at least.
>
> That's good to hear.

Ditto, especially since i18n, once the groundwork has been done,
requires very little work to support (as long as someone keeps an eye
out for people forgetting to _("") a string).

-- 
Cheers,

Sverre Rabbelier

Re: Stable ab/i18n branch

[Jon Seymour]

On Fri, Oct 15, 2010 at 8:18 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Thu, Oct 14, 2010 at 20:54, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Ævar Arnfjörð Bjarmason wrote:
> So what I've tried to do to make this acceptable for inclusion in core
> is to make this whole thing a no-op unless it's explicitly
> requested.
>

I agree with Jonathan that there might be some value to clearly
delineating the i18n infrastructure from the application of it to the
rest of the code base.The i18n infrastructure should be, relatively
speaking, less invasive than the application of it throughout the code
base.

It would be good for Junio (I presume) to have the option to integrate
the infrastructure in one hit, but allow the application of it to be
deferred, perhaps on a subject-area by subject-area basis.

jon.

Re: Stable ab/i18n branch

[Jonathan Nieder]

Hi again,

Ævar Arnfjörð Bjarmason wrote:

> While that's not a perfect solution I think it's the best we're going
> to get for the time being. I'm pretty convinced that if I tried to
> make git itself LC_CTYPE-safe as part of this already huge series it'd
> never get merged. Having messages with question marks from strerror()
> on certain platforms is an OK compromise in my opinion.

The question marks[1] are what I was referring to.  Consider this from
the point of view of someone working on the Debian package: would
users consider that an appropriate or positive change for squeeze+1?
(Hint: not if it doesn't come with some benefit in their locale, no.)

I suspect making git work with other LC_CTYPE would not actually be
too hard[2].  Such fixes are useful for futureproofing and increased
sanity anyway --- they do not have to be part of the l10n branch imho.

[1] fatal: unable to stat 'foo.c': Op?ration non permise
[2] except that annoying printf bug.

Re: Stable ab/i18n branch

[Ævar Arnfjörð Bjarmason]

On Thu, Oct 14, 2010 at 21:50, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Fri, Oct 15, 2010 at 8:18 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Thu, Oct 14, 2010 at 20:54, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Ævar Arnfjörð Bjarmason wrote:
>> So what I've tried to do to make this acceptable for inclusion in core
>> is to make this whole thing a no-op unless it's explicitly
>> requested.
>>
> I agree with Jonathan that there might be some value to clearly
> delineating the i18n infrastructure from the application of it to the
> rest of the code base.The i18n infrastructure should be, relatively
> speaking, less invasive than the application of it throughout the code
> base.
>
> It would be good for Junio (I presume) to have the option to integrate
> the infrastructure in one hit, but allow the application of it to be
> deferred, perhaps on a subject-area by subject-area basis.

It already is pretty much separate internally. To get only the
infrastructure you pull the series and omit the "gettextize"
patches. There is some slight tangling up e.g. here:

    6da9243 gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
    234ddee gettextize: git-init basic messages
    b161357 gettextize: git-init "Initialized [...] repository" message
    3ad3f9f gettext tests: test if $VERSION exists before using it
    1f56190 gettext tests: add detection for is_IS.ISO-8859-1 locale
    5f24f25 gettext tests: test message re-encoding under Shell
    ec31cc6 gettext tests: test re-encoding with a UTF-8 msgid under Shell
    45e8a56 gettext tests: mark a test message as not needing translation
    c9db9aa po/is.po: add Icelandic translation
    83beb97 gettext tests: test message re-encoding under C

Where the tests I'm adding depend on an earlier "gettextize"
patch. That can easily be split up if there's demand for it. But so
far nobody has asked so I haven't done it.

Re: Stable ab/i18n branch

[Ævar Arnfjörð Bjarmason]

On Fri, Oct 15, 2010 at 00:07, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> While that's not a perfect solution I think it's the best we're going
>> to get for the time being. I'm pretty convinced that if I tried to
>> make git itself LC_CTYPE-safe as part of this already huge series it'd
>> never get merged. Having messages with question marks from strerror()
>> on certain platforms is an OK compromise in my opinion.
>
> The question marks[1] are what I was referring to.  Consider this from
> the point of view of someone working on the Debian package: would
> users consider that an appropriate or positive change for squeeze+1?
> (Hint: not if it doesn't come with some benefit in their locale, no.)

No benefit? The benefit is that the program they previously either
didn't understand or understood poorly is now talking to them in their
native language. That's a pretty big benefit.

The tradeoff is that a small subset of the messages which include
strerror() output will show non-ASCII characters as question marks on
GNU systems.

Don't get me wrong. I think it's a bug that we need to fix. I just
think it's a relatively minor annoyance, not a showstopper. With it
the feature *mostly* just works, and the things that don't can be
documented by the Debian maintainer and others as a known bug.

> I suspect making git work with other LC_CTYPE would not actually be
> too hard[2].  Such fixes are useful for futureproofing and increased
> sanity anyway --- they do not have to be part of the l10n branch imho.

It's something we want yes, but not something I have time for these
days. So unless someone else is interested in helping audit all that
code, providing a printf() fallback on glibc etc. it'll block the i18n
series.

For something I at least think is a relatively minor issue that
doesn't warrant throwing the baby out with the bathwater.

Re: Stable ab/i18n branch

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> No benefit? The benefit is that the program they previously either
> didn't understand or understood poorly is now talking to them in their
> native language. That's a pretty big benefit.

And for the languages that are not translated yet?

Don't get me wrong --- I'm only trying to give a sense of what it is
like for a user to experience a regression.  It is generally little
solace that someone else's use case is supported better.

>       So unless someone else is interested in helping audit all that
> code, providing a printf() fallback on glibc etc. it'll block the i18n
> series.

Oh, I never meant to say that this should be a blocker.  Only that
there really are costs and benefits to weigh.

Much more important than the known bugs are the unknown bugs ---
you've heard this before, I think.  The way to get rid of unknown bugs
(aside from inspecting code) is to get users.

For example, if Gerrit doesn't mind, I would like to apply your
patches to experimental once the version being staged for squeeze
clears from there.

Other interested people can attract users in other ways --- by
providing documentation, tarballs, ...

Re: Stable ab/i18n branch

[Ævar Arnfjörð Bjarmason]

On Fri, Oct 15, 2010 at 05:28, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> No benefit? The benefit is that the program they previously either
>> didn't understand or understood poorly is now talking to them in their
>> native language. That's a pretty big benefit.
>
> And for the languages that are not translated yet?

Yeah those would get odd regressions with no benefit, unfortunately.

> Don't get me wrong --- I'm only trying to give a sense of what it is
> like for a user to experience a regression.  It is generally little
> solace that someone else's use case is supported better.

Understood. And it's certainly good that these things are pointed out.

>>       So unless someone else is interested in helping audit all that
>> code, providing a printf() fallback on glibc etc. it'll block the i18n
>> series.
>
> Oh, I never meant to say that this should be a blocker.  Only that
> there really are costs and benefits to weigh.
>
> Much more important than the known bugs are the unknown bugs ---
> you've heard this before, I think.  The way to get rid of unknown bugs
> (aside from inspecting code) is to get users.
>
> For example, if Gerrit doesn't mind, I would like to apply your
> patches to experimental once the version being staged for squeeze
> clears from there.

That would be great. Let me know if I can help with that in some way.

Re: What's cooking in git.git (Oct 2010, #01; Wed, 13)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Thu, Oct 14, 2010 at 04:46, Junio C Hamano <gitster@pobox.com> wrote:
>
>>  - test-lib: make test_expect_code a test command
>>
>> Somewhat rerolled, but the largest one among the series was Nacked by a
>> few people and needs to be rerolled again.
>
> Why did you amend this to use this sed trick:
>
>     +sed -e 's/Z$//' >expect <<\EOF &&
>     +not ok - 1 tests clean up even after a failure
>     +#      Z
>     +#          touch clean-after-failure &&
>     +#          test_when_finished rm clean-after-failure &&
>     +#          (exit 1)
>     +#      Z
>     +not ok - 2 failure to clean up causes the test to fail
>     +#      Z
>     +#          test_when_finished \"(exit 2)\"
>     +#      Z
>
> Is it just to keep it diff --check clean?

Yes and files with trailing whitespaces are hard to understand in general
when reading, even outside the "should I apply that patch?" contenxt.

> Anyway if we munge the output like this the output of test_cmp will be
> more confusing when it fails, because it'll be diff(1)-ing something
> that the test-lib would never emit.

Hmm, why?  "expect" has trailing whitespaces on lines that end with Z,
i.e. what the original patch wanted to place in.

Re: Stable ab/i18n branch

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Ævar Arnfjörð Bjarmason wrote:
>
>> Could you please pick up the 160 commit version of this at:
>> 
>>     git://github.com/avar/git.git ab/i18n
>
> This is a "give an inch and they'll ask for a mile" sort of thing, but
> would it be possible to maintain a stable branch with the i18n
> infrastructure that only gets rebased when there is reorganization
> going on?

People might have noticed that I've refrained to take other topics that
may add new messages to 'next'.  I would wanted to merge ab/i18n early in
the cycle soon after dust has settled after 1.7.3 release.  And I still
do.

Having said that, there are different classes of risks associated with
i18n effort.

(1) Regressions that even hit a NO_I18N build.
(2) Regressions that hit LC_ALL=C execution in a !NO_I18N build.
(3) Regressions that hit plumbing run in a non-C locale.

 . i18n needs not just marking strings with _("string") but also needs to
   fix code that manually formulates messages by series of strcat().  It
   may need to start using allocations on the heap, with potential risk of
   usual bugs (leaks, use-after-free, etc.) and performance degradation.

 . Messages left unmarked with _("string"), or messages that are marked
   with _("string") that shouldn't have, won't be serious issues for the
   first two classes.  The latter is a serious regression for the
   plumbing.

We are all human, and misconversion during this process is possible, even
though the above classes of regressions are unacceptable.  On the other
hand, as long as the above three classes of regressions are minimum and
quickly fixed/fixable, issues in non-C locale Porcelains are tolerable
during the initial cut.

I've looked at the patches in the series, and plan to take another look.
I'm sure others on the list have checked the series, some with fine combs,
too, and hopefully Ævar has fixed any such regression that has been
reported and plans to do so for the ones discovered in the future.  As
long as we are sure that we have done a reasonable effort to eyeball the
patches, the logical next step would be to merge the series to 'next' for
further testing.

(4) Incomplete *.po file, and languages without *.po file.

Once we are sure that the series does not have the first two classes of
issues, we can ask everybody to mark new strings in their series, iow,
merge the i18n part to 'master'.  If we can do that sooner, it would be
better, and we do not need specific l10n part from the series during that
stage.  

A language that already has *.po file may lack necessary translation;
there may be languages that do not have *.po file.  They can be added with
a lot smaller risk later without unstabilizing the codebase.

So where are we now?  I think a constantly rebased 160-patch series that
has infrastructure bits and l10n bits mixed together is not very friendly
to review for the first three classes of regressions (which are all I care
about at this point) to help the series hit 'master' sooner.

In any case, the branch merged to 'pu' has been replaced with the tip of
the said branch from Ævar's repository now.

Re: Stable ab/i18n branch

[Ævar Arnfjörð Bjarmason]

On Sun, Oct 17, 2010 at 04:44, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Ævar Arnfjörð Bjarmason wrote:
>>
>>> Could you please pick up the 160 commit version of this at:
>>>
>>>     git://github.com/avar/git.git ab/i18n
>>
>> This is a "give an inch and they'll ask for a mile" sort of thing, but
>> would it be possible to maintain a stable branch with the i18n
>> infrastructure that only gets rebased when there is reorganization
>> going on?
>
> People might have noticed that I've refrained to take other topics that
> may add new messages to 'next'.  I would wanted to merge ab/i18n early in
> the cycle soon after dust has settled after 1.7.3 release.  And I still
> do.

Good to hear. I didn't know that before, and that's really all I
wanted to know.

> Having said that, there are different classes of risks associated with
> i18n effort.
>
> (1) Regressions that even hit a NO_I18N build.
> (2) Regressions that hit LC_ALL=C execution in a !NO_I18N build.
> (3) Regressions that hit plumbing run in a non-C locale.
>
>  . i18n needs not just marking strings with _("string") but also needs to
>   fix code that manually formulates messages by series of strcat().  It
>   may need to start using allocations on the heap, with potential risk of
>   usual bugs (leaks, use-after-free, etc.) and performance degradation.
>
>  . Messages left unmarked with _("string"), or messages that are marked
>   with _("string") that shouldn't have, won't be serious issues for the
>   first two classes.  The latter is a serious regression for the
>   plumbing.
>
> We are all human, and misconversion during this process is possible, even
> though the above classes of regressions are unacceptable.  On the other
> hand, as long as the above three classes of regressions are minimum and
> quickly fixed/fixable, issues in non-C locale Porcelains are tolerable
> during the initial cut.
>
> I've looked at the patches in the series, and plan to take another look.
> I'm sure others on the list have checked the series, some with fine combs,
> too, and hopefully Ævar has fixed any such regression that has been
> reported and plans to do so for the ones discovered in the future.  As
> long as we are sure that we have done a reasonable effort to eyeball the
> patches, the logical next step would be to merge the series to 'next' for
> further testing.

Right. I'll have time to deal with any bugs that crop up, and I'm
reasonably sure it's OK as-is.

> (4) Incomplete *.po file, and languages without *.po file.
>
> Once we are sure that the series does not have the first two classes of
> issues, we can ask everybody to mark new strings in their series, iow,
> merge the i18n part to 'master'.  If we can do that sooner, it would be
> better, and we do not need specific l10n part from the series during that
> stage.
>
> A language that already has *.po file may lack necessary translation;
> there may be languages that do not have *.po file.  They can be added with
> a lot smaller risk later without unstabilizing the codebase.

Do you mean to re-arrange it so that there's a patch at the front of
the series that introduces gettext.h with only the fallbacks:

    #define _(s) (s)
    #define N_(s) (s)

And then merge the ~120 gettextize patches first and do the
infrastructure later?

That could be done, but just merging the whole 160 patch series and
turning it off by default would have pretty much the same effect. And
since I thought this was going to get merged soon-ish anyway I didn't
spend time on something like that.

> So where are we now?  I think a constantly rebased 160-patch series that
> has infrastructure bits and l10n bits mixed together is not very friendly
> to review for the first three classes of regressions (which are all I care
> about at this point) to help the series hit 'master' sooner.

I think we're basically at a point where merging it down to next ->
master is the logical next step.

> In any case, the branch merged to 'pu' has been replaced with the tip of
> the said branch from Ævar's repository now.

Thanks.

Re: Stable ab/i18n branch

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> Do you mean to re-arrange it so that there's a patch at the front of
> the series that introduces gettext.h with only the fallbacks:
> 
>     #define _(s) (s)
>     #define N_(s) (s)
> 
> And then merge the ~120 gettextize patches first and do the
> infrastructure later?

I don't think that's what he was saying, but I think that _would_ be
helpful.  So the history could look like:

                     infrastructure
                    /              \
 introduce gettext.h                ab/i18n
                    \              /
                     gettextization
                          /
                          merges from master where appropriate,
                          perhaps just at the beginning for simplicity.


That way, each side could have patches rearranged or squashed when
needed without disrupting the other.

What do you think?

Re: Stable ab/i18n branch

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Do you mean to re-arrange it so that there's a patch at the front of
> the series that introduces gettext.h with only the fallbacks:
>
>     #define _(s) (s)
>     #define N_(s) (s)
>
> And then merge the ~120 gettextize patches first and do the
> infrastructure later?

Not really.

Two pieces that would be nice to have in 'master' (or even 'maint', if we
consider avoiding merge conflicts and mismerges when fixes are queued
there) are:

 1. preparatory fixes to code that builds message string by concatenating
    parts of speech in English word ordering into buffer or emitting to
    output stream piece by piece; they should convert them to some form of
    sprintf-like format strings plus arguments.  This does not necessarily
    have to mark the format strings with _(s).

 2. the empty definitions for _(s) and N_(s).

I would consider the first one part of general clean-up job, which we know
will help i18n, but which we would want to do regardless of i18n.  And it
is probably the most error prone part in the whole process.  The sooner
the result of these two steps hit 'master', the less pain for everybody.

And then:

 3. actual marking of strings with _(s) and N_(s).

which can be merged to 'next' after vetting for regression (the first two
classes).

 4. Adding and polishing of *.po files for actual messages and languages,
    i.e. l10n.

This can happen pretty much independently from 3.  Honestly I would be
happier if I do not have to keep track of the actual l10n part.

I think the current series to some degree conflates steps 1. and 3.  As
the list of risks I outlined in the previous message show, mistakes in 1.
is much more grave than mistakes in 3. (iow, no big deal for having a few
untranslated messages during early rounds of i18n support); I would have
preferred these two steps were clearly separated, so that we can push the
first two steps out to the 'master' sooner.

Re: Stable ab/i18n branch

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 19.10.2010 01:39:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
>> Do you mean to re-arrange it so that there's a patch at the front of
>> the series that introduces gettext.h with only the fallbacks:
>>
>>     #define _(s) (s)
>>     #define N_(s) (s)
>>
>> And then merge the ~120 gettextize patches first and do the
>> infrastructure later?
> 
> Not really.
> 
> Two pieces that would be nice to have in 'master' (or even 'maint', if we
> consider avoiding merge conflicts and mismerges when fixes are queued
> there) are:
> 
>  1. preparatory fixes to code that builds message string by concatenating
>     parts of speech in English word ordering into buffer or emitting to
>     output stream piece by piece; they should convert them to some form of
>     sprintf-like format strings plus arguments.  This does not necessarily
>     have to mark the format strings with _(s).
> 
>  2. the empty definitions for _(s) and N_(s).
> 
> I would consider the first one part of general clean-up job, which we know
> will help i18n, but which we would want to do regardless of i18n.  And it
> is probably the most error prone part in the whole process.  The sooner
> the result of these two steps hit 'master', the less pain for everybody.
> 
> And then:
> 
>  3. actual marking of strings with _(s) and N_(s).
> 
> which can be merged to 'next' after vetting for regression (the first two
> classes).
> 
>  4. Adding and polishing of *.po files for actual messages and languages,
>     i.e. l10n.
> 
> This can happen pretty much independently from 3.  Honestly I would be
> happier if I do not have to keep track of the actual l10n part.
> 
> I think the current series to some degree conflates steps 1. and 3.  As
> the list of risks I outlined in the previous message show, mistakes in 1.
> is much more grave than mistakes in 3. (iow, no big deal for having a few
> untranslated messages during early rounds of i18n support); I would have
> preferred these two steps were clearly separated, so that we can push the
> first two steps out to the 'master' sooner.

I'd just like to second (or third or..) Junio's points here since I had
suggested a split like that earlier already, and I think the current
state of affairs simply makes many potential reviewers (at least one
that I know of) go away.

1.,2. and (maybe to a lesser degree) also 3. should be able to find many
reviewers, thus making the potentially problematic parts as solid as
possible. (I'm still waiting for a conceptual approach to 4., i.e.
glossary first, but that is a different issue.)

Michael

Re: What's cooking in git.git (Oct 2010, #01; Wed, 13)

[Johan Herland]

On Thursday 14 October 2010, Junio C Hamano wrote:
> * jh/notes-merge (2010-10-09) 21 commits
>  [...]
> 
> Breaks build with arithmetic on (void *).

Fixed in the next iteration (v4, just posted). Thanks for noticing.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net