Git development
 help / color / mirror / Atom feed
* What's cooking in git.git (Oct 2012, #08; Thu, 25)
From: Jeff King @ 2012-10-25 11:54 UTC (permalink / raw)
  To: git

What's cooking in git.git (Oct 2012, #08; Thu, 25)
--------------------------------------------------

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

Now that 1.8.0 is out, I've graduated the first batch of topics to
master. I've also picked up some topics from the list, mostly
documentation fixes that went straight to next. I haven't yet moved any
of the cooking topics up to next.

You can find the changes described here in the integration branches of
my repository at:

  git://github.com/peff/git.git

Until Junio returns, kernel.org and the other "usual" places will not be
updated.

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

* gb/maint-doc-svn-log-window-size (2012-10-25) 1 commit
 - Document git-svn fetch --log-window-size parameter

Looks good to me, but I'd like to get an ack from svn folks.


* jk/config-ignore-duplicates (2012-10-24) 8 commits
  (merged to 'next' on 2012-10-25 at 233df08)
 + git-config: use git_config_with_options
 + git-config: do not complain about duplicate entries
 + git-config: collect values instead of immediately printing
 + git-config: fix regexp memory leaks on error conditions
 + git-config: remove memory leak of key regexp
 + t1300: test "git config --get-all" more thoroughly
 + t1300: remove redundant test
 + t1300: style updates

Drop duplicate detection from git-config; this lets it
better match the internal config callbacks, which clears up
some corner cases with includes.


* mm/maint-doc-remote-tracking (2012-10-25) 1 commit
  (merged to 'next' on 2012-10-25 at 80f1592)
 + Documentation: remote tracking branch -> remote-tracking branch

We long ago hyphenated "remote-tracking branch"; this
catches some new instances added since then.


* ph/pull-rebase-detached (2012-10-25) 1 commit
  (merged to 'next' on 2012-10-25 at 73d9d14)
 + git-pull: Avoid merge-base on detached head

Avoids spewing error messages when using "pull --rebase" on a
detached HEAD.


* ph/submodule-sync-recursive (2012-10-24) 2 commits
 - Add tests for submodule sync --recursive
 - Teach --recursive to submodule sync

I'd like review from submodule folks on this one.


* po/maint-refs-replace-docs (2012-10-25) 1 commit
  (merged to 'next' on 2012-10-25 at 3874c9d)
 + Doc repository-layout: Show refs/replace

The refs/replace hierarchy was not mentioned in the
repository-layout docs.


* sl/maint-configure-messages (2012-10-25) 1 commit
  (merged to 'next' on 2012-10-25 at e1d7ecd)
 + configure: fix some output message

Minor message fixes for the configure script.

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

* bw/config-lift-variable-name-length-limit (2012-10-01) 1 commit
  (merged to 'next' on 2012-10-08 at 69f54f4)
 + Remove the hard coded length limit on variable names in config files

 The configuration parser had an unnecessary hardcoded limit on
 variable names that was not checked consistently. Lift the limit.


* da/mergetools-p4 (2012-10-11) 1 commit
  (merged to 'next' on 2012-10-12 at 16f5c06)
 + mergetools/p4merge: Handle "/dev/null"


* fa/remote-svn (2012-10-07) 16 commits
  (merged to 'next' on 2012-10-07 at 7b90cf4)
 + Add a test script for remote-svn
 + remote-svn: add marks-file regeneration
 + Add a svnrdump-simulator replaying a dump file for testing
 + remote-svn: add incremental import
 + remote-svn: Activate import/export-marks for fast-import
 + Create a note for every imported commit containing svn metadata
 + vcs-svn: add fast_export_note to create notes
 + Allow reading svn dumps from files via file:// urls
 + remote-svn, vcs-svn: Enable fetching to private refs
 + When debug==1, start fast-import with "--stats" instead of "--quiet"
 + Add documentation for the 'bidi-import' capability of remote-helpers
 + Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
 + Add argv_array_detach and argv_array_free_detached
 + Add svndump_init_fd to allow reading dumps from arbitrary FDs
 + Add git-remote-testsvn to Makefile
 + Implement a remote helper for svn in C

 A GSoC project.


* jc/test-say-color-avoid-echo-escape (2012-10-11) 1 commit
  (merged to 'next' on 2012-10-11 at 639036d)
 + test-lib: Fix say_color () not to interpret \a\b\c in the message

 Recent nd/wildmatch series was the first to reveal this ancient bug
 in the test scaffolding.


* jk/no-more-pre-exec-callback (2012-06-05) 1 commit
  (merged to 'next' on 2012-10-12 at 69fed45)
 + pager: drop "wait for output to run less" hack

 (Originally merged to 'next' on 2012-07-23)
 Removes a workaround for buggy version of less older than version
 406.


* jk/peel-ref (2012-10-04) 4 commits
  (merged to 'next' on 2012-10-08 at 4adfa2f)
 + upload-pack: use peel_ref for ref advertisements
 + peel_ref: check object type before loading
 + peel_ref: do not return a null sha1
 + peel_ref: use faster deref_tag_noverify

 Speeds up "git upload-pack" (what is invoked by "git fetch" on the
 other side of the connection) by reducing the cost to advertise the
 branches and tags that are available in the repository.


* jk/strbuf-detach-always-non-null (2012-10-18) 1 commit
  (merged to 'next' on 2012-10-18 at 54561c7)
 + strbuf: always return a non-NULL value from strbuf_detach


* jm/diff-context-config (2012-10-02) 2 commits
  (merged to 'next' on 2012-10-02 at e57700a)
 + t4055: avoid use of sed 'a' command
  (merged to 'next' on 2012-10-01 at 509a558)
 + diff: diff.context configuration gives default to -U

 Teaches a new configuration variable to "git diff" Porcelain and
 its friends.


* js/mingw-fflush-errno (2012-10-17) 1 commit
  (merged to 'next' on 2012-10-18 at 43d6ebb)
 + maybe_flush_or_die: move a too-loose Windows specific error


* nd/attr-match-optim (2012-10-05) 2 commits
  (merged to 'next' on 2012-10-08 at bfbdd8a)
 + attr: avoid searching for basename on every match
 + attr: avoid strlen() on every match
 (this branch is used by as/check-ignore, nd/attr-match-optim-more and nd/wildmatch.)

 Trivial and obvious optimization for finding attributes that match
 a given path.

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

* rc/maint-complete-git-p4 (2012-09-24) 1 commit
 - Teach git-completion about git p4

 Comment from Pete will need to be addressed in a follow-up patch.


* as/test-tweaks (2012-09-20) 7 commits
 - tests: paint unexpectedly fixed known breakages in bold red
 - tests: test the test framework more thoroughly
 - [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
 - tests: refactor mechanics of testing in a sub test-lib
 - tests: paint skipped tests in bold blue
 - tests: test number comes first in 'not ok $count - $message'
 - tests: paint known breakages in bold yellow

 Various minor tweaks to the test framework to paint its output
 lines in colors that match what they mean better.

 Has the "is this really blue?" issue Peff raised resolved???


* jc/maint-name-rev (2012-09-17) 7 commits
 - describe --contains: use "name-rev --algorithm=weight"
 - name-rev --algorithm=weight: tests and documentation
 - name-rev --algorithm=weight: cache the computed weight in notes
 - name-rev --algorithm=weight: trivial optimization
 - name-rev: --algorithm option
 - name_rev: clarify the logic to assign a new tip-name to a commit
 - name-rev: lose unnecessary typedef

 "git name-rev" names the given revision based on a ref that can be
 reached in the smallest number of steps from the rev, but that is
 not useful when the caller wants to know which tag is the oldest one
 that contains the rev.  This teaches a new mode to the command that
 uses the oldest ref among those which contain the rev.

 I am not sure if this is worth it; for one thing, even with the help
 from notes-cache, it seems to make the "describe --contains" even
 slower. Also the command will be unusably slow for a user who does
 not have a write access (hence unable to create or update the
 notes-cache).

 Stalled mostly due to lack of responses.


* jc/xprm-generation (2012-09-14) 1 commit
 - test-generation: compute generation numbers and clock skews

 A toy to analyze how bad the clock skews are in histories of real
 world projects.

 Stalled mostly due to lack of responses.


* jc/blame-no-follow (2012-09-21) 2 commits
 - blame: pay attention to --no-follow
 - diff: accept --no-follow option

 Teaches "--no-follow" option to "git blame" to disable its
 whole-file rename detection.

 Stalled mostly due to lack of responses.


* jc/doc-default-format (2012-10-07) 2 commits
 - [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
 - Allow generating a non-default set of documentation

 Need to address the installation half if this is to be any useful.


* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
 - graph.c: infinite loop in git whatchanged --graph -m

 The --graph code fell into infinite loop when asked to do what the
 code did not expect ;-)

 Anybody who worked on "--graph" wants to comment?
 Stalled mostly due to lack of responses.


* jc/add-delete-default (2012-08-13) 1 commit
 - git add: notice removal of tracked paths by default

 "git add dir/" updated modified files and added new files, but does
 not notice removed files, which may be "Huh?" to some users.  They
 can of course use "git add -A dir/", but why should they?

 Resurrected from graveyard, as I thought it was a worthwhile thing
 to do in the longer term.

 Waiting for comments.


* mb/remote-default-nn-origin (2012-07-11) 6 commits
 - Teach get_default_remote to respect remote.default.
 - Test that plain "git fetch" uses remote.default when on a detached HEAD.
 - Teach clone to set remote.default.
 - Teach "git remote" about remote.default.
 - Teach remote.c about the remote.default configuration setting.
 - Rename remote.c's default_remote_name static variables.

 When the user does not specify what remote to interact with, we
 often attempt to use 'origin'.  This can now be customized via a
 configuration variable.

 Expecting a reroll.

 "The first remote becomes the default" bit is better done as a
 separate step.

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

* mh/ceiling (2012-10-21) 8 commits
 - string_list_longest_prefix(): remove function
 - normalize_ceiling_entry(): resolve symlinks
 - longest_ancestor_length(): require prefix list entries to be normalized
 - longest_ancestor_length(): take a string_list argument for prefixes
 - longest_ancestor_length(): use string_list_split()
 - Introduce new function real_path_if_valid()
 - real_path_internal(): add comment explaining use of cwd
 - Introduce new static function real_path_internal()

 Elements of GIT_CEILING_DIRECTORIES list may not match the real
 pathname we obtain from getcwd(), leading the GIT_DIR discovery
 logic to escape the ceilings the user thought to have specified.


* mo/cvs-server-cleanup (2012-10-16) 10 commits
  (merged to 'next' on 2012-10-25 at c70881d)
 + cvsserver status: provide real sticky info
 + cvsserver: cvs add: do not expand directory arguments
 + cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
 + cvsserver: split up long lines in req_{status,diff,log}
 + cvsserver: clean up client request handler map comments
 + cvsserver: remove unused functions _headrev and gethistory
 + cvsserver update: comment about how we shouldn't remove a user-modified file
 + cvsserver: add comments about database schema/usage
 + cvsserver: removed unused sha1Or-k mode from kopts_from_path
 + cvsserver t9400: add basic 'cvs log' test
 (this branch is used by mo/cvs-server-updates.)


* mo/cvs-server-updates (2012-10-16) 10 commits
 - cvsserver Documentation: new cvs ... -r support
 - cvsserver: add t9402 to test branch and tag refs
 - cvsserver: support -r and sticky tags for most operations
 - cvsserver: Add version awareness to argsfromdir
 - cvsserver: generalize getmeta() to recognize commit refs
 - cvsserver: implement req_Sticky and related utilities
 - cvsserver: add misc commit lookup, file meta data, and file listing functions
 - cvsserver: define a tag name character escape mechanism
 - cvsserver: cleanup extra slashes in filename arguments
 - cvsserver: factor out git-log parsing logic
 (this branch uses mo/cvs-server-cleanup.)


* ta/doc-cleanup (2012-10-25) 6 commits
 - Documentation: build html for all files in technical and howto
 - Documentation/howto: convert plain text files to asciidoc
 - Documentation/technical: convert plain text files to asciidoc
 - Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
 - Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
 - Split over-long synopsis in git-fetch-pack.txt into several lines

 Misapplication of a patch fixed; the ones near the tip needs to
 update the links to point at the html files, though.


* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
 - Fix "git diff --stat" for interesting - but empty - file changes

 We failed to mention a file without any content change but whose
 permission bit was modified, or (worse yet) a new file without any
 content in the "git diff --stat" output.


* jc/prettier-pretty-note (2012-10-25) 11 commits
 - Doc User-Manual: Patch cover letter, three dashes, and --notes
 - Doc format-patch: clarify --notes use case
 - Doc notes: Include the format-patch --notes option
 - Doc SubmittingPatches: Mention --notes option after "cover letter"
 - Documentation: decribe format-patch --notes
 - format-patch --notes: show notes after three-dashes
 - format-patch: append --signature after notes
 - pretty_print_commit(): do not append notes message
 - pretty: prepare notes message at a centralized place
 - format_note(): simplify API
 - pretty: remove reencode_commit_message()

 Needs updates to the placeholder documentation.


* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
  (merged to 'next' on 2012-10-25 at 3879f0e)
 + filter-branch: use git-sh-setup's ident parsing functions
 + git-sh-setup: refactor ident-parsing functions

 Will merge to 'master' in the second batch after 1.8.0 ships.


* nd/status-long (2012-10-18) 1 commit
  (merged to 'next' on 2012-10-25 at ff1b3a0)
 + status: add --long output format option

 Allow an earlier "--short" option on the command line to be
 countermanded with the "--long" option for "git status" and "git
 commit".

 Will merge to 'master' in the second batch after 1.8.0 ships.


* rs/branch-del-symref (2012-10-18) 5 commits
  (merged to 'next' on 2012-10-25 at c2cd358)
 + branch: show targets of deleted symrefs, not sha1s
 + branch: skip commit checks when deleting symref branches
 + branch: delete symref branch, not its target
 + branch: factor out delete_branch_config()
 + branch: factor out check_branch_commit()
 (this branch is used by jh/update-ref-d-through-symref.)

 A symbolic ref refs/heads/SYM was not correctly removed with
 "git branch -d SYM"; the command removed the ref pointed by
 SYM instead.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* sz/maint-curl-multi-timeout (2012-10-19) 1 commit
 - Fix potential hang in https handshake

 Sometimes curl_multi_timeout() function suggested a wrong timeout
 value when there is no file descriptors to wait on and the http
 transport ended up sleeping for minutes in select(2) system call.
 Detect this and reduce the wait timeout in such a case.


* jc/same-encoding (2012-10-18) 1 commit
 - reencode_string(): introduce and use same_encoding()

 Various codepaths checked if two encoding names are the same using
 ad-hoc code and some of them ended up asking iconv() to convert
 between "utf8" and "UTF-8".  The former is not a valid way to spell
 the encoding name, but often people use it by mistake, and we
 equated them in some but not all codepaths. Introduce a new helper
 function to make these codepaths consistent.


* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
 - tree-walk: use enum interesting instead of integer


* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
  (merged to 'next' on 2012-10-25 at 59d3687)
 + http: do not set up curl auth after a 401
 + remote-curl: do not call run_slot repeatedly

 Further clean-up to the http codepath that picks up results after
 cURL library is done with one request slot.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* nd/grep-true-path (2012-10-12) 1 commit
  (merged to 'next' on 2012-10-25 at 1c7d320)
 + grep: stop looking at random places for .gitattributes

 "git grep -e pattern <tree>" asked the attribute system to read
 "<tree>:.gitattributes" file in the working tree, which was
 nonsense.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* cr/cvsimport-local-zone (2012-10-16) 1 commit
 - git-cvsimport: allow author-specific timezones

 Allows "cvsimport" to read per-author timezone from the author info
 file.


* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
 - completion: add format-patch options to send-email


* fc/zsh-completion (2012-10-15) 3 commits
 - completion: add new zsh completion
 - tests: use __gitcompadd to simplify completion tests
 - completion: add new __gitcompadd helper


* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
 - apply.c:update_pre_post_images(): the preimage can be truncated

 Fix to update_pre_post_images() that did not take into account the
 possibility that whitespace fix could shrink the preimage and
 change the number of lines in it.

 Extra set of eyeballs appreciated.


* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
 - config: exit on error accessing any config file
 - doc: advertise GIT_CONFIG_NOSYSTEM
 - config: treat user and xdg config permission problems as errors
 - config, gitignore: failure to access with ENOTDIR is ok

 An RFC to deal with a situation where .config/git is a file and we
 notice .config/git/config is not readable due to ENOTDIR, not
 ENOENT; I think a bit more refactored approach to consistently
 address permission errors across config, exclude and attrs is
 desirable.  Don't we also need a check for an opposite situation
 where we open .config/git/config or .gitattributes for reading but
 they turn out to be directories?


* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
  (merged to 'next' on 2012-10-25 at 9341eea)
 + refs: lock symref that is to be deleted, not its target

 When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
 SYM, it incorrectly locked the underlying reference pointed by SYM,
 not the symbolic ref itself.


* as/check-ignore (2012-10-19) 13 commits
 - Documentation/check-ignore: we show the deciding match, not the first
 - Add git-check-ignore sub-command
 - dir.c: provide free_directory() for reclaiming dir_struct memory
 - pathspec.c: move reusable code from builtin/add.c
 - dir.c: refactor treat_gitlinks()
 - dir.c: keep track of where patterns came from
 - dir.c: refactor is_path_excluded()
 - dir.c: refactor is_excluded()
 - dir.c: refactor is_excluded_from_list()
 - dir.c: rename excluded() to is_excluded()
 - dir.c: rename excluded_from_list() to is_excluded_from_list()
 - dir.c: rename path_excluded() to is_path_excluded()
 - dir.c: rename cryptic 'which' variable to more consistent name
 (this branch uses nd/attr-match-optim-more; is tangled with nd/wildmatch.)

 Duy helped to reroll this.


* js/format-2047 (2012-10-18) 7 commits
  (merged to 'next' on 2012-10-25 at 76d91fe)
 + format-patch tests: check quoting/encoding in To: and Cc: headers
 + format-patch: fix rfc2047 address encoding with respect to rfc822 specials
 + format-patch: make rfc2047 encoding more strict
 + format-patch: introduce helper function last_line_length()
 + format-patch: do not wrap rfc2047 encoded headers too late
 + format-patch: do not wrap non-rfc2047 headers too early
 + utf8: fix off-by-one wrapping of text

 Fixes many rfc2047 quoting issues in the output from format-patch.


* km/send-email-compose-encoding (2012-10-25) 5 commits
 - git-send-email: add rfc2047 quoting for "=?"
 - git-send-email: introduce quote_subject()
 - git-send-email: skip RFC2047 quoting for ASCII subjects
 - git-send-email: use compose-encoding for Subject
  (merged to 'next' on 2012-10-25 at 5447367)
 + git-send-email: introduce compose-encoding

 "git send-email --compose" can let the user create a non-ascii
 cover letter message, but there was not a way to mark it with
 appropriate content type before sending it out.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* so/prompt-command (2012-10-17) 4 commits
  (merged to 'next' on 2012-10-25 at 79565a1)
 + coloured git-prompt: paint detached HEAD marker in red
 + Fix up colored git-prompt
 + show color hints based on state of the git tree
 + Allow __git_ps1 to be used in PROMPT_COMMAND

 Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
 instead of being used for command substitution in $PS1, to embed
 color escape sequences in its output.


* aw/rebase-am-failure-detection (2012-10-11) 1 commit
 - rebase: Handle cases where format-patch fails

 I am unhappy a bit about the possible performance implications of
 having to store the output in a temporary file only for a rare case
 of format-patch aborting.


* nd/wildmatch (2012-10-15) 13 commits
  (merged to 'next' on 2012-10-25 at 510e8df)
 + Support "**" wildcard in .gitignore and .gitattributes
 + wildmatch: make /**/ match zero or more directories
 + wildmatch: adjust "**" behavior
 + wildmatch: fix case-insensitive matching
 + wildmatch: remove static variable force_lower_case
 + wildmatch: make wildmatch's return value compatible with fnmatch
 + t3070: disable unreliable fnmatch tests
 + Integrate wildmatch to git
 + wildmatch: follow Git's coding convention
 + wildmatch: remove unnecessary functions
 + Import wildmatch from rsync
 + ctype: support iscntrl, ispunct, isxdigit and isprint
 + ctype: make sane_ctype[] const array
 (this branch uses nd/attr-match-optim-more; is tangled with as/check-ignore.)

 Allows pathname patterns in .gitignore and .gitattributes files
 with double-asterisks "foo/**/bar" to match any number of directory
 hierarchies.

 I suspect that this needs to be plugged to pathspec matching code;
 otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
 commits that touch Documentation/git.txt, which would be confusing
 to the users.


* jk/lua-hackery (2012-10-07) 6 commits
 - pretty: fix up one-off format_commit_message calls
 - Minimum compilation fixup
 - Makefile: make "lua" a bit more configurable
 - add a "lua" pretty format
 - add basic lua infrastructure
 - pretty: make some commit-parsing helpers more public

 Interesting exercise. When we do this for real, we probably would want
 to wrap a commit to make it more like an "object" with methods like
 "parents", etc.


* nd/attr-match-optim-more (2012-10-15) 7 commits
  (merged to 'next' on 2012-10-25 at 09f70ce)
 + attr: more matching optimizations from .gitignore
 + gitignore: make pattern parsing code a separate function
 + exclude: split pathname matching code into a separate function
 + exclude: fix a bug in prefix compare optimization
 + exclude: split basename matching code into a separate function
 + exclude: stricten a length check in EXC_FLAG_ENDSWITH case
 + Merge commit 'f9f6e2c' into nd/attr-match-optim-more
 (this branch is used by as/check-ignore and nd/wildmatch.)

 Start laying the foundation to build the "wildmatch" after we can
 agree on its desired semantics.


* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
  (merged to 'next' on 2012-10-25 at 2ea9b27)
 + log: honor grep.* configuration
 + log --grep: accept --basic-regexp and --perl-regexp
 + log --grep: use the same helper to set -E/-F options as "git grep"
 + revisions: initialize revs->grep_filter using grep_init()
 + grep: move pattern-type bits support to top-level grep.[ch]
 + grep: move the configuration parsing logic to grep.[ch]
 + builtin/grep.c: make configuration callback more reusable

 "git log -F -E --grep='<ere>'" failed to use the given <ere>
 pattern as extended regular expression, and instead looked for the
 string literally.  The early part of this series is a fix for it.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* jl/submodule-add-by-name (2012-09-30) 2 commits
  (merged to 'next' on 2012-10-25 at a322082)
 + submodule add: Fail when .git/modules/<name> already exists unless forced
 + Teach "git submodule add" the --name option

 If you remove a submodule, in order to keep the repository so that
 "git checkout" to an older commit in the superproject history can
 resurrect the submodule, the real repository will stay in $GIT_DIR
 of the superproject.  A later "git submodule add $path" to add a
 different submodule at the same path will fail.  Diagnose this case
 a bit better, and if the user really wants to add an unrelated
 submodule at the same path, give the "--name" option to give it a
 place in $GIT_DIR of the superproject that does not conflict with
 the original submodule.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* jl/submodule-rm (2012-09-29) 1 commit
  (merged to 'next' on 2012-10-25 at 0fb5876)
 + submodule: teach rm to remove submodules unless they contain a git directory

 "git rm submodule" cannot blindly remove a submodule directory as
 its working tree may have local changes, and worse yet, it may even
 have its repository embedded in it.  Teach it some special cases
 where it is safe to remove a submodule, specifically, when there is
 no local changes in the submodule working tree, and its repository
 is not embedded in its working tree but is elsewhere and uses the
 gitfile mechanism to point at it.

 Will merge to 'master' in the second batch after 1.8.0 ships.


* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
 . pretty: support %>> that steal trailing spaces
 . pretty: support truncating in %>, %< and %><
 . pretty: support padding placeholders, %< %> and %><
 . pretty: two phase conversion for non utf-8 commits
 . utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
 . utf8.c: move display_mode_esc_sequence_len() for use by other functions
 . pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
 . pretty: split parsing %C into a separate function
 . pretty: share code between format_decoration and show_decorations

 This causes warnings with -Wuninitialized, so I've ejected it from pu
 for the time being.


* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
 - get_fetch_map(): tighten checks on dest refs

 This was split out from discarded jc/maint-push-refs-all topic.


* jh/symbolic-ref-d (2012-10-21) 1 commit
 - git symbolic-ref --delete $symref

 Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.

 It is already possible to remove a symbolic ref with "update-ref -d
 --no-deref", but it may be a good addition for completeness.


* jh/update-ref-d-through-symref (2012-10-21) 2 commits
 - Fix failure to delete a packed ref through a symref
 - t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
 (this branch uses rs/branch-del-symref.)

 "update-ref -d --deref SYM" to delete a ref through a symbolic ref
 that points to it did not remove it correctly.


--------------------------------------------------
[Discarded]

* fa/vcs-svn (2012-10-07) 4 commits
 - vcs-svn: remove repo_tree
 - vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
 - vcs-svn/svndump: restructure node_ctx, rev_ctx handling
 - svndump: move struct definitions to .h
 (this branch uses fa/remote-svn.)

 A follow-up to a GSoC project, but seems not quite ready.


* ph/credential-refactor (2012-09-02) 5 commits
 - wincred: port to generic credential helper
 - Merge branch 'ef/win32-cred-helper' into ph/credential-refactor
 - osxkeychain: port to generic credential helper implementation
 - gnome-keyring: port to generic helper implementation
 - contrib: add generic credential helper

 Attempts to refactor to share code among OSX keychain, Gnome keyring
 and Win32 credential helpers.  Turns out that the sharing wasn't
 big enough to worth the churn.


* ms/contrib-thunderbird-updates (2012-08-31) 2 commits
 - [SQUASH] minimum fixup
 - Thunderbird: fix appp.sh format problems

 Update helper to send out format-patch output using Thunderbird.
 Seems to have design regression for silent users.


* jx/test-real-path (2012-08-27) 1 commit
 - test: set the realpath of CWD as TRASH_DIRECTORY

 Running tests with the "trash" directory elsewhere with the "--root"
 option did not work well if the directory was specified by a symbolic
 link pointing at it.

 Seems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.


* jc/maint-push-refs-all (2012-08-27) 2 commits
 - get_fetch_map(): tighten checks on dest refs
 - [BROKEN] fetch/push: allow refs/*:refs/*

 This is broken (see the log message there).  "git fetch/push
 $there 'refs/*:refs/*'" already propagates heads, tags, notes,
 etc. hierarchies; an attempt to propagate refs/stash will fail
 against an older version of the other side and is not worth
 supporting.


* tx/relative-in-the-future (2012-08-16) 2 commits
 - date: show relative dates in the future
 - date: refactor the relative date logic from presentation

 Not my itch; rewritten an earlier submission by Tom Xue into
 somewhat more maintainable form, though it breaks existing i18n.

 Was waiting for a voluteer to fix it up, which never happend.


* jc/split-blob (2012-04-03) 6 commits
 - chunked-object: streaming checkout
 - chunked-object: fallback checkout codepaths
 - bulk-checkin: support chunked-object encoding
 - bulk-checkin: allow the same data to be multiply hashed
 - new representation types in the packstream
 - packfile: use varint functions

 I finished the streaming checkout codepath, but as explained in
 127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
 these are still early steps of a long and painful journey. At least
 pack-objects and fsck need to learn the new encoding for the series
 to be usable locally, and then index-pack/unpack-objects needs to
 learn it to be used remotely.

 Given that I heard a lot of noise that people want large files, and
 that I was asked by somebody at GitTogether'11 privately for an
 advice on how to pay developers (not me) to help adding necessary
 support, I am somewhat disappointed that the original patch series
 that was sent long time ago still remains here without much comments
 and updates from the developer community. I even made the interface
 to the logic that decides where to split chunks easily replaceable,
 and I deliberately made the logic in the original patch extremely
 stupid to entice others, especially the "bup" fanbois, to come up
 with a better logic, thinking that giving people an easy target to
 shoot for, they may be encouraged to help out. The plan is not
 working :-<.

^ permalink raw reply

* Re: [PATCH] Fixes handling of --reference argument.
From: W. Trevor King @ 2012-10-25 10:45 UTC (permalink / raw)
  To: Jeff King; +Cc: szager, git
In-Reply-To: <20121025083625.GA8390@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On Thu, Oct 25, 2012 at 04:36:26AM -0400, Jeff King wrote:
> On Wed, Oct 24, 2012 at 09:52:52PM -0700, szager@google.com wrote:
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index ab6b110..dcceb43 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -270,7 +270,6 @@ cmd_add()
> >  			;;
> >  		--reference=*)
> >  			reference="$1"
> > -			shift
> >  			;;
> 
> Is that right? We'll unconditionally do a "shift" at the end of the
> loop. If it were a two-part argument like "--reference foo", the extra
> shift would make sense, but for "--reference=*", no extra shift should
> be neccessary. Am I missing something?

Both the patch and Jeff's analysis are right.  You only need an
in-case shift if you consume "$2", or you're on ‘--’ and you're
breaking before the end-of-case shift.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-25 11:19 UTC (permalink / raw)
  To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121025100854.GN8390@sigill.intra.peff.net>

On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote:
> 
> Ah, never mind. I missed your earlier "use compose-encoding for
> Subject". I've queued it and all of the follow-ons onto the
> km/send-email-compose-encoding topic.
> 

thanks, what about the problem with whitespaces in "quote_subject" patch?

Krzysiek

^ permalink raw reply

* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-25 11:21 UTC (permalink / raw)
  To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121025111919.GA25272@shrek.podlesie.net>

On Thu, Oct 25, 2012 at 01:19:19PM +0200, Krzysztof Mazur wrote:

> On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote:
> > 
> > Ah, never mind. I missed your earlier "use compose-encoding for
> > Subject". I've queued it and all of the follow-ons onto the
> > km/send-email-compose-encoding topic.
> > 
> 
> thanks, what about the problem with whitespaces in "quote_subject" patch?

I fixed the whitespace problems, and just applying your patches in
sequence on top of send-email-compose-encoding actually looks sensible
(after looking at it, I came to the same conclusion as you that the two
patches should be kept separate). I'll push out the results of tonight's
work in a few minutes, if you want to eyeball what's in pu.

-Peff

^ permalink raw reply

* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-25 11:12 UTC (permalink / raw)
  To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121025090149.GC8390@sigill.intra.peff.net>

On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote:
> 
> Hmm. What is this patch on top of? It looks like it is on top of your
> original patch, but when I tried it on top of that, it does not apply
> either, and the index lines in the patch do not mention a sha1 that I do
> not have.

Sorry, it's against km/send-email-compose-encoding (or current next)
+ "git-send-email: use compose-encoding for Subject".

> 
> Do you mind re-rolling a final 2-patch series with:
> 
>   1. Your original patch and this one squashed together, with an
>      appropriate commit message.

I think that it's better to do refactoring and fix for ASCII in separate
patches. Maybe we should reverse order of first two patches. This first
will do refactoring and the second will just replace quote_rfc2047()
with quote_subject() in "broken" encoding case and add test
for this problem.

> 
>   2. The second "quote when we see '=?'" patch.
> 
> Thanks.
> 
> -Peff

ok, I will resend the final series.

I need also to fix "git-send-email: use compose-encoding for Subject"
patch. Now it's depends both on this series and
km/send-email-compose-encoding branch.

Krzysiek

^ permalink raw reply

* RE: [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:59 UTC (permalink / raw)
  To: 'Jeff King'; +Cc: git
In-Reply-To: <20121025105236.GA2962@sigill.intra.peff.net>

> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, October 25, 2012 12:53 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
> 
> On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote:
> 
> > > But then I would think using /usr/local would be the sane thing to put
> > > there, if that is the closest to "standard" for your platform.
> >
> > OK, yes, hardcoding /usr/local seems OK too.
> > Would I need to re-roll?
> 
> Please do.

Done. For some reason not 'chained' to this thread though

Bye, Jojo

^ permalink raw reply

* RE: [PATCH v2] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:57 UTC (permalink / raw)
  To: 'Jeff King'; +Cc: git

This fixes the vast majority of test failures on HP NonStop.

Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
---
v2: hardcode /usr/local rather than using ${prefix}

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

diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
	MKDIR_WO_TRAILING_SLASH = YesPlease
	# RFE 10-120912-4693 submitted to HP NonStop development.
	NO_SETITIMER = UnfortunatelyYes
+
+	# for 'make test'
+	# some test don't work with /bin/diff, some fail with /bin/tar
+	# some need bash, and some need /usr/local/bin in PATH first
+	SHELL_PATH=/usr/local/bin/bash
+	SANE_TOOL_PATH=/usr/local/bin
+	# as of H06.25/J06.14, we might better use this
+	#SHELL_PATH=/usr/coreutils/bin/bash
+	#SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
endif
ifneq (,$(findstring MINGW,$(uname_S)))
	pathsep = ;

^ permalink raw reply related

* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25 10:52 UTC (permalink / raw)
  To: Joachim Schmitz; +Cc: git
In-Reply-To: <002f01cdb29e$c2db47e0$4891d7a0$@schmitz-digital.de>

On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote:

> > But then I would think using /usr/local would be the sane thing to put
> > there, if that is the closest to "standard" for your platform.
> 
> OK, yes, hardcoding /usr/local seems OK too.
> Would I need to re-roll?

Please do.

-Peff

^ permalink raw reply

* RE: [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:51 UTC (permalink / raw)
  To: 'Jeff King'; +Cc: git
In-Reply-To: <20121025104900.GA6363@sigill.intra.peff.net>

> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, October 25, 2012 12:49 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
> 
> On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
> 
> > > > +	# for 'make test'
> > > > +	# some test don't work with /bin/diff, some fail with /bin/tar
> > > > +	# some need bash, and some need ${prefix}/bin in PATH first
> > > > +	SHELL_PATH=${prefix}/bin/bash
> > > > +	SANE_TOOL_PATH=${prefix}/bin
> > >
> > > This feels a little too specific to go in our Makefile. Do we have any
> > > reason to think that where you are installing git is going to be the
> > > same place you have bash and other sane tools? Wouldn't this mean that
> > > things work when you run "make" but mysteriously break when you run
> > > "make prefix=/my/local/install/of/git"?
> >
> > Well, "make" won't break (I think), but "make test" very well might.
> 
> Sure.
> 
> > Well, so far all OpenSource packages ported to HP NonStop (at least
> > the ones on ituglib.connect-community.org) use prefix=/usr/local and
> > there is no intention to change that.
> 
> But then I would think using /usr/local would be the sane thing to put
> there, if that is the closest to "standard" for your platform.

OK, yes, hardcoding /usr/local seems OK too.
Would I need to re-roll?

Bye, Jojo

^ permalink raw reply

* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25 10:49 UTC (permalink / raw)
  To: Joachim Schmitz; +Cc: git
In-Reply-To: <002e01cdb29a$893593f0$9ba0bbd0$@schmitz-digital.de>

On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:

> > > +	# for 'make test'
> > > +	# some test don't work with /bin/diff, some fail with /bin/tar
> > > +	# some need bash, and some need ${prefix}/bin in PATH first
> > > +	SHELL_PATH=${prefix}/bin/bash
> > > +	SANE_TOOL_PATH=${prefix}/bin
> > 
> > This feels a little too specific to go in our Makefile. Do we have any
> > reason to think that where you are installing git is going to be the
> > same place you have bash and other sane tools? Wouldn't this mean that
> > things work when you run "make" but mysteriously break when you run
> > "make prefix=/my/local/install/of/git"?
> 
> Well, "make" won't break (I think), but "make test" very well might.

Sure.

> Well, so far all OpenSource packages ported to HP NonStop (at least
> the ones on ituglib.connect-community.org) use prefix=/usr/local and
> there is no intention to change that.

But then I would think using /usr/local would be the sane thing to put
there, if that is the closest to "standard" for your platform.

If there is not a standard, then I think we are better off leaving it
blank and letting people do the right thing for their system (including
packagers who are building for other people).

-Peff

^ permalink raw reply

* Re: [PATCH] Doc repository-layout: Show refs/replace
From: Jeff King @ 2012-10-25 10:34 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList
In-Reply-To: <1350852757-3924-1-git-send-email-philipoakley@iee.org>

On Sun, Oct 21, 2012 at 09:52:37PM +0100, Philip Oakley wrote:

> Signed-off-by: Philip Oakley <philipoakley@iee.org>

Thanks, this makes sense.

> +refs/replace/`<obj-sha1>`::
> +	records the SHA1 of the object that replaces `<obj-sha1>`.
> +	This is similar to info/grafts and is internally used and
> +	maintained by `git replace`. Such refs can be exchanged between
> +	repositories while grafts are not.

This should probably be an actual link to the git-replace manpage. I'll
convert it to a linkgit. No need to resend.

-Peff

^ permalink raw reply

* Re: [PATCH] Doc User-Manual: Patch cover letter, three dashes, and --notes
From: Jeff King @ 2012-10-25 10:26 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-2-git-send-email-philipoakley@iee.org>

On Sun, Oct 21, 2012 at 10:34:08PM +0100, Philip Oakley wrote:

> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 85651b5..d918c53 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1787,6 +1787,11 @@ $ git format-patch origin
>  will produce a numbered series of files in the current directory, one
>  for each patch in the current branch but not in origin/HEAD.
>  
> +`git format-patch` can include an initial "cover letter". You can insert
> +a commentary on individual patches using a three dash line after the
> +commit message, and before the patch itself. `git format-patch --notes`
> +(v1.8.1) will include the commit's notes in the similar manner.

I'd rather not mention a version number here, as we do not yet know
which version (if any) will contain the feature. Besides, we write our
documentation to match the current version, so as long as this is queued
on top of the new code, I do not see any reason to mention a version at
all.

I'll tweak it while queueing.

-Peff

^ permalink raw reply

* Re: [PATCH] Doc format-patch: clarify --notes use case
From: Jeff King @ 2012-10-25 10:25 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-4-git-send-email-philipoakley@iee.org>

On Sun, Oct 21, 2012 at 10:34:10PM +0100, Philip Oakley wrote:

>  The expected use case of this is to write supporting explanation for
> -the commit that does not belong to the commit log message proper
> -when (or after) you create the commit, and include it in your patch
> -submission.  But if you can plan ahead and write it down, there may
> -not be a good reason not to write it in your commit message, and if
> -you can't, you can always edit the output of format-patch before
> -sending it out, so the practical value of this option is somewhat
> -dubious, unless your workflow is broken.
> +the commit, that does not belong to the commit log message proper,
> +and include it with the patch submission. The notes can be maintained
> +between versions of the patch series. You can also edit the output of
> +format-patch before sending.

I found the "you can also" slightly awkward here, as it was not clear
why it was mentioned. I think the intent is "this is an alternative that
does not involve the notes workflow", but it is not clear from the text
why you would prefer the notes workflow. Here is what I queued instead,
which tires to clarify that, and also mentions that this workflow needs
additional setup to track rewritten commits:

diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 066dc8b..750b3fa 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -196,13 +196,12 @@ The expected use case of this is to write supporting explanation for
 	after the three-dash line.
 +
 The expected use case of this is to write supporting explanation for
-the commit that does not belong to the commit log message proper
-when (or after) you create the commit, and include it in your patch
-submission.  But if you can plan ahead and write it down, there may
-not be a good reason not to write it in your commit message, and if
-you can't, you can always edit the output of format-patch before
-sending it out, so the practical value of this option is somewhat
-dubious, unless your workflow is broken.
+the commit that does not belong to the commit log message proper,
+and include it with the patch submission. While one can simply write
+these explanations after `format-patch` has run but before sending,
+keeping them as git notes allows them to be maintained between versions
+of the patch series (but see the discussion of the `notes.rewrite.*`
+configuration in linkgit:git-notes[1] to use this workflow).
 
 --[no]-signature=<signature>::
 	Add a signature to each message produced. Per RFC 3676 the signature


I've queued that and your other patches on top of jc/prettier-pretty-note.

-Peff

^ permalink raw reply related

* RE: [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:21 UTC (permalink / raw)
  To: 'Jeff King'; +Cc: git
In-Reply-To: <20121025095826.GM8390@sigill.intra.peff.net>

> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, October 25, 2012 11:58 AM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
> 
> On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:
> 
> > +	# for 'make test'
> > +	# some test don't work with /bin/diff, some fail with /bin/tar
> > +	# some need bash, and some need ${prefix}/bin in PATH first
> > +	SHELL_PATH=${prefix}/bin/bash
> > +	SANE_TOOL_PATH=${prefix}/bin
> 
> This feels a little too specific to go in our Makefile. Do we have any
> reason to think that where you are installing git is going to be the
> same place you have bash and other sane tools? Wouldn't this mean that
> things work when you run "make" but mysteriously break when you run
> "make prefix=/my/local/install/of/git"?

Well, "make" won't break (I think), but "make test" very well might.

Well, so far all OpenSource packages ported to HP NonStop (at least the ones on ituglib.connect-community.org) use prefix=/usr/local and there is no intention to change that.
A few (bash, vim, coreutils, tar, gzip, bzip2) get delivered with the system meanwhile (rather than having to be downloaded and installed by the customer) and live in /usr/corutiles. Still more are needed (e.g. diff , make).
The next lines in my patch cater for that, it is missing though an automatic switch.
Such a switch would be possible, using 'uname -r' and 'uname -v', but pretty convoluted

Pseudo code:
If (`uname -r` = J06 && `uname -v` >= 14) || (`uname -r`= H06 && `uname -v` >= 25)
	SHELL_PATH=/usr/coreutils/bin/bash
	SANE_TOOL_PATH=/usr/coreutils/bin:${prefix}/bin
else
	SHELL_PATH=${prefix}/bin/bash
	SANE_TOOL_PATH=${prefix}/bin
endif	

I didn't deem it worth the effort. As mentioned it'd most likely still need stuff from /usr/local/bin

And someone wanting prefix somewhere else could still do
PATH=/usr/local/bin:$PATH make prefix=/my/local/install/of/git 
And so find what's need in either the 1st or 2nd path of PATH

Bye, Jojo

^ permalink raw reply

* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-25 10:08 UTC (permalink / raw)
  To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121025090149.GC8390@sigill.intra.peff.net>

On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote:

> > -	if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> > -			($subject =~ /[^[:ascii:]]/)) {
> > -		$subject = quote_rfc2047($subject, $auto_8bit_encoding);
> > +	if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> > +		$subject = quote_subject($subject, $auto_8bit_encoding);
> >  	}
> 
> Hmm. What is this patch on top of? It looks like it is on top of your
> original patch, but when I tried it on top of that, it does not apply
> either, and the index lines in the patch do not mention a sha1 that I do
> not have.
>
> Do you mind re-rolling a final 2-patch series with:

Ah, never mind. I missed your earlier "use compose-encoding for
Subject". I've queued it and all of the follow-ons onto the
km/send-email-compose-encoding topic.

Thanks.

-Peff

^ permalink raw reply

* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25  9:58 UTC (permalink / raw)
  To: Joachim Schmitz; +Cc: git
In-Reply-To: <001e01cdb061$c25f6380$471e2a80$@schmitz-digital.de>

On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote:

> +	# for 'make test'
> +	# some test don't work with /bin/diff, some fail with /bin/tar
> +	# some need bash, and some need ${prefix}/bin in PATH first
> +	SHELL_PATH=${prefix}/bin/bash
> +	SANE_TOOL_PATH=${prefix}/bin

This feels a little too specific to go in our Makefile. Do we have any
reason to think that where you are installing git is going to be the
same place you have bash and other sane tools? Wouldn't this mean that
things work when you run "make" but mysteriously break when you run
"make prefix=/my/local/install/of/git"?

-Peff

^ permalink raw reply

* Re: [PATCH] Documentation: remote tracking branch -> remote-tracking branch
From: Jeff King @ 2012-10-25  9:54 UTC (permalink / raw)
  To: Matthieu Moy; +Cc: git, gitster, angelo.borsotti
In-Reply-To: <1350992045-11141-1-git-send-email-Matthieu.Moy@imag.fr>

On Tue, Oct 23, 2012 at 01:34:05PM +0200, Matthieu Moy wrote:

> This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2
> 2010, Replace "remote tracking" with "remote-tracking"), but new
> instances of remote tracking (without dash) were introduced in the
> meantime.

Thanks. It seems like an obvious step forward.

> I'm not opposed to dropping completely the remote-tracking part in the
> case of merge (i.e. "remote-tracking branches that the current branch
> is configured to use as its upstream" -> "upstream branch") on top of
> that, but if we do this, merge-config.txt should be updated too).

Yeah, I do not care too deeply, but I think it reads just fine without
mentioning remote-tracking at all.

-Peff

^ permalink raw reply

* Re: [PATCH] Document git-svn fetch --log-window-size parameter
From: Jeff King @ 2012-10-25  9:52 UTC (permalink / raw)
  To: Gunnlaugur Þór Briem; +Cc: Eric Wong, git
In-Reply-To: <1350988406-97624-1-git-send-email-gunnlaugur@gmail.com>

On Tue, Oct 23, 2012 at 10:33:26AM +0000, Gunnlaugur Þór Briem wrote:

> The --log-window-size parameter to git-svn fetch is undocumented.
> 
> Minimally describe what it does and why the user might change it.

Thanks. Your description makes sense to me, but I do not have enough
git-svn knowledge to know if it covers all intended uses of the flag.
Eric?

> +--log-window-size=<n>;;
> +    Fetch <n> log entries per request when scanning Subversion history.
> +    The default is 100. For very large Subversion repositories, larger
> +    values may be needed for 'clone'/'fetch' to complete in reasonable
> +    time. But overly large values may lead to request timeouts.

-Peff

^ permalink raw reply

* Re: [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
From: Jeff King @ 2012-10-25  9:45 UTC (permalink / raw)
  To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1350959091-30030-1-git-send-email-pclouds@gmail.com>

On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote:

> These functions are called in sequencer.c, which is part of
> libgit.a. This makes libgit.a potentially require builtin/merge.c for
> external git commands.
> 
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  I made some unrelated changes in sequencer.c and this problem shown
>  up. merge-recursive.c is probably not the best place for these
>  functions. I just don't want to create merge.c for them.

I'm fine with this conceptually, but merge-recursive really is the wrong
place. I'd much rather see a new merge.c to collect merge-related helper
functions that are not strategy-specific.

-Peff

^ permalink raw reply

* Re: [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
From: Jeff King @ 2012-10-25  9:42 UTC (permalink / raw)
  To: Thomas Ackermann; +Cc: git, gitster
In-Reply-To: <1531209463.296427.1351015084181.JavaMail.ngmail@webmail16.arcor-online.net>

On Tue, Oct 23, 2012 at 07:58:04PM +0200, Thomas Ackermann wrote:

> - target "html" creates html for all files in Documentation/howto and
> Documentation/technical

Thanks.

> +TECH_DOCS = technical/index-format
> +TECH_DOCS += technical/pack-format
> +TECH_DOCS += technical/pack-heuristics
> +TECH_DOCS += technical/pack-protocol
> +TECH_DOCS += technical/protocol-capabilities
> +TECH_DOCS += technical/protocol-common
> +TECH_DOCS += technical/racy-git
> +TECH_DOCS += technical/send-pack-pipeline
> +TECH_DOCS += technical/shallow
> +TECH_DOCS += technical/trivial-merge
> +SP_ARTICLES += $(TECH_DOCS)

I wonder if these could even be part of the generated api-index.html
(that is, if somebody is reading about the API, they just as well may
want to see these format documents). But I do not overly care much, as I
(and I suspect most other developers) just read the technical
documentation in its original txt format.

If somebody cares, we can easily build it on top.

-Peff

^ permalink raw reply

* Re: [PATCHv2] git-pull: Avoid merge-base on detached head
From: Jeff King @ 2012-10-25  9:34 UTC (permalink / raw)
  To: Phil Hord; +Cc: git, phil.hord, Junio C Hamano
In-Reply-To: <1351024796-28174-2-git-send-email-hordp@cisco.com>

On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote:

> git pull --rebase does some clever tricks to find the base
> for $upstream , but it forgets that we may not have any
> branch at all.  When this happens, git merge-base reports its
> "usage" help in the middle of an otherwise successful
> rebase operation, because git-merge is called with one too
> few parameters.
> 
> Since we do not need the merge-base trick in the case of a
> detached HEAD, detect this condition and bypass the clever
> trick and the usage noise.

Makes sense. I notice there is no test with your patch. It sounds from
the description like the operation still may succeed, but we just get
cruft on stderr?

-Peff

^ permalink raw reply

* Re: [PATCHv2] git-status: show short sequencer state
From: Jeff King @ 2012-10-25  9:29 UTC (permalink / raw)
  To: Phil Hord
  Cc: git, phil.hord, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien,
	Duperray Valentin, Jonas Franck, Nguy Thomas,
	Nguyen Huynh Khoi Nguyen
In-Reply-To: <1351022574-27869-2-git-send-email-hordp@cisco.com>

On Tue, Oct 23, 2012 at 04:02:54PM -0400, Phil Hord wrote:

> Teach git-status to report the sequencer state in short form
> using a new --sequencer (-S) switch.  Output zero or more
> simple state token strings indicating the deduced state of the
> git sequencer.
> 
> Introduce a common function to determine the current sequencer
> state so the regular status function and this short version can
> share common code.
> 
> Add a substate to wt_status_state to track more detailed
> information about a state, such as "conflicted" or "resolved".
> Move the am_empty_patch flage out of wt_status_state and into

This patch ended up quite long. It might be a little easier to review
if it were broken into refactoring steps (I have not looked at it too
closely yet, but it seems like the three paragraphs above could each be
their own commit).

> State token strings which may be emitted and their meanings:
>     merge              a git-merge is in progress
>     am                 a git-am is in progress
>     rebase             a git-rebase is in progress
>     rebase-interactive a git-rebase--interactive is in progress

A minor nit, but you might want to update this list from the one in the
documentation.

> diff --git a/builtin/commit.c b/builtin/commit.c
> index a17a5df..9706ed9 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
>  static enum {
>  	STATUS_FORMAT_LONG,
>  	STATUS_FORMAT_SHORT,
> -	STATUS_FORMAT_PORCELAIN
> +	STATUS_FORMAT_PORCELAIN,
> +	STATUS_FORMAT_SEQUENCER
>  } status_format = STATUS_FORMAT_LONG;

Hmm. So the new format is its own distinct output format. I could not
say "I would like to see short status, and by the way, show me the
sequencer state", as you can with "-b". Is it possible to do this (or
even desirable; getting the sequencer state should be way cheaper, so
conflating the two may not be what some callers want).

Not complaining, just wondering about the intended use cases.

Also, does there need to be a --porcelain version of this output? It
seems like we can have multiple words (e.g., in a merge, with conflicted
entries). If there is no arbitrary data, we do not have to worry about
delimiters and quoting.  But I wonder if we would ever want to expand
the information to include arbitrary strings, at which point we would
want NUL delimiters; should we start with that now?

> +	// Determine main sequencer activity

Please avoid C99 comments (there are others in the patch, too).

> +void wt_sequencer_print(struct wt_status *s)
> +{
> +	struct wt_status_state state;
> +
> +	wt_status_get_state(s, &state);
> +
> +	if (state.merge_in_progress)
> +		wt_print_token(s, "merge");
> +	if (state.am_in_progress)
> +		wt_print_token(s, "am");
> +	if (state.rebase_in_progress)
> +		wt_print_token(s, "rebase");
> +	if (state.rebase_interactive_in_progress)
> +		wt_print_token(s, "rebase-interactive");
> +	if (state.cherry_pick_in_progress)
> +		wt_print_token(s, "cherry-pick");
> +	if (state.bisect_in_progress)
> +		wt_print_token(s, "bisect");
> +
> +	switch (state.substate) {
> +	case WT_SUBSTATE_NOMINAL:
> +		break;
> +	case WT_SUBSTATE_CONFLICTED:
> +		wt_print_token(s, "conflicted");
> +		break;
> +	case WT_SUBSTATE_RESOLVED:
> +		wt_print_token(s, "resolved");
> +		break;
> +	case WT_SUBSTATE_EDITED:
> +		wt_print_token(s, "edited");
> +		break;
> +	case WT_SUBSTATE_EDITING:
> +		wt_print_token(s, "editing");
> +		break;
> +	case WT_SUBSTATE_SPLITTING:
> +		wt_print_token(s, "splitting");
> +		break;
> +	case WT_SUBSTATE_AM_EMPTY:
> +		wt_print_token(s, "am-empty");
> +		break;
> +	}
> +}

It is clear from this code that some tokens can happen together, and
some are mutually exclusive. Should the documentation talk about that,
or do we want to literally keep it as a list of tags?

-Peff

^ permalink raw reply

* Re: signing commits with openssl/PKCS#11
From: Mat Arge @ 2012-10-25  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <CA+sFfMdSc30xmzFrqbPFYigLkW9v_YSrnTBtumhZiU5TKiBxqQ@mail.gmail.com>

On Thursday 25. October 2012 01:02:33 Brandon Casey wrote:
> On Mon, Oct 22, 2012 at 6:38 AM, Mat Arge <argemat1010@gmail.com> wrote:
> > Hy!
> > 
> > I would like to sign each commit with a X.509 certificate and a private
> > key
> > stored on a PKCS#11 token. I assume that that should be possible somehow
> > using a hook which calls openssl. Does somebody know a working
> > implementation of this?
> 
> Creating signatures from an rsa key on a pkcs11 token should be
> possible, but gnupg doesn't support pkcs11 for philosophical reasons.
> You need to use gnupg-pkcs11 which is maintained outside of the gnupg
> tree.
> 
> Once you configure gnupg-pkcs11-scd, you'll be able to use git and gpg
> to sign tags as usual.
> 
> I configured this a while back for use with CAC cards using the
> following resources:
> 
>    http://alpha.uwb.edu.pl/map/eToken_gpg_howto.shtml (dead)
>    http://alpha.uwb.edu.pl/amicke/eToken_gpg_howto.shtml (replacement
> for above?)
>    http://gnupg-pkcs11.sourceforge.net/man.html
> 
> Try those docs.  If you have questions, I'll try to find my notes.
> 
> -Brandon

Thanks for the tip, I will try them (though the appear to be very outdated).
Do you know, if gnupg-pkcs11-scd is able to cooperate with the standard pcscd 
from pcsc-lite, or is a one-or-the-other situation?

cheers
Mat

^ permalink raw reply

* Re: signing commits with openssl/PKCS#11
From: Mat Arge @ 2012-10-25  9:12 UTC (permalink / raw)
  To: git
In-Reply-To: <5087B8E7.8010306@drmicha.warpmail.net>

On Wednesday 24. October 2012 11:46:15 Michael J Gruber wrote:
> Mat Arge venit, vidit, dixit 22.10.2012 15:38:
> > Hy!
> > 
> > I would like to sign each commit with a X.509 certificate and a private
> > key
> > stored on a PKCS#11 token. I assume that that should be possible somehow
> > using a hook which calls openssl. Does somebody know a working
> > implementation of this?
> > 
> > cheers
> > Mat
> 
> In principle, we have an almost pluggable architecture. See for example
> the latter part of the 2nd post in
> 
> http://article.gmane.org/gmane.comp.version-control.git/175127
> 
> Unless you want to change git itself, you're probably better off storing
> your non-gpg signatures in a note (or a self-created signed tag). 

So, there is no possibility to modify the commit itself via a hook, and add a, 
say, "opensslsig" instead of a gpgsig tag?

> To
> sign the commit rev, you could sign the output of "git cat-file commit
> rev" (or of "git rev-parse rev") and store that signature in a note that
> commit. To verify, you verify the note against the commit.
> 
> Michael

But if I crete/modify a signature file while commiting, that file wouldn't be 
commited itself, so the signatur-file would always be one commit behind. Or am 
I missing something? I'm quite new to git (or DVCSs in general), so sorry if 
this is a dumb question.

cheers
Mat

^ permalink raw reply

* Re: [PATCH] configure: fix some output message
From: Jeff King @ 2012-10-25  9:11 UTC (permalink / raw)
  To: Stefano Lattarini; +Cc: git
In-Reply-To: <b67d9e47dc92c2c316495ac4bd8e7ba93d339781.1351091006.git.stefano.lattarini@gmail.com>

On Wed, Oct 24, 2012 at 05:34:27PM +0200, Stefano Lattarini wrote:

> Before this change, output from ./configure could contain
> botched wording like this:
> 
>     checking Checking for POSIX Threads with '-pthread'... yes
> 
> instead of the intended:
> 
>     checking for POSIX Threads with '-pthread'... yes
> 
> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

Thanks, looks obviously correct.

-Peff

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox