What's cooking in git.git (Jan 2016, #02; Mon, 11)

What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

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

It's been a week or so since Git 2.7 was released.  I'll draw the
projected timeline for the next cycle (which I expect to be a
shorter and lightweight cycle), reorder 'next' and possibly eject a
few topics from it to give them a fresh slate to rebuild on, and
then start the 2.7.x maintenance track soonish, but none of these
has happened yet; I'm feeling behind X-<.

Big thanks to Stephen Smith for picking up a few topics from the
Stalled pile and reviving them.  And as always, thanks for the
regular reviewers (you know who you are) for helping the topics
move forward.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

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

* dw/signoff-doc (2016-01-05) 1 commit
 - Expand documentation describing --signoff

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

 Will merge to 'next'.


* ew/for-each-ref-doc (2016-01-05) 1 commit
 - for-each-ref: document `creatordate` and `creator` fields

 Will merge to 'next'.


* sg/t6050-failing-editor-test-fix (2016-01-05) 1 commit
 - t6050-replace: make failing editor test more robust

 Will merge to 'next'.


* js/dirname-basename (2016-01-11) 4 commits
 - t0060: verify that basename() and dirname() work as expected
 - compat/basename.c: provide a dirname() compatibility function
 - compat/basename: make basename() conform to POSIX
 - Refactor skipping DOS drive prefixes

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

 Will merge to 'next', 'master', and then to 'maint'.

 The third-patch has an optional suggestion to make it easier to
 follow; I'm slightly in favor but lack of a reroll for it is not a
 showstopper, either.


* js/fopen-harder (2016-01-11) 2 commits
 - Handle more file writes correctly in shared repos
 - commit: allow editing the commit message even in shared repos

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

 Will merge to 'next'.


* nd/exclusion-regression-fix (2016-01-08) 1 commit
 - Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"

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

 Will merge to 'next' and then to 'master'.


* ss/clone-depth-single-doc (2016-01-08) 3 commits
 - docs: clarify that --depth for git-fetch works with newly initialized repos
 - docs: say "commits" in the --depth option wording for git-clone
 - docs: clarify that passing --depth to git-clone implies --single-branch

 Updates documents to clarify "git fetch --depth".

 Will merge to 'next'.

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

* kf/http-proxy-auth-methods (2015-11-04) 3 commits
 . SQUASH???
 . http: use credential API to handle proxy authentication
 . http: allow selection of proxy authentication method

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

 I ejected this from pu for the moment, as it conflicts with the
 pt/http-socks-proxy topic. That is now in master, so it can
 be re-rolled on top.

 Anybody wants to help rerolling this?  Otherwise will discard.


* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
 - t/lib-git-svn: check same httpd module dirs as lib-httpd
 - t/lib-httpd: load mod_unixd

 This is the first two commits in a three-patch series $gmane/266962

 Becoming tired of waiting for a reroll.
 with updated log message ($gmane/268061).
 Will discard.


* jc/diff-b-m (2015-02-23) 5 commits
 . WIPWIP
 . WIP: diff-b-m
 - diffcore-rename: allow easier debugging
 - diffcore-rename.c: add locate_rename_src()
 - diffcore-break: allow debugging

 "git diff -B -M" produced incorrect patch when the postimage of a
 completely rewritten file is similar to the preimage of a removed
 file; such a resulting file must not be expressed as a rename from
 other place.

 The fix in this patch is broken, unfortunately.
 Will discard.

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

* wp/sha1-name-negative-match (2016-01-11) 2 commits
 - object name: introduce '^{/!-<negative pattern>}' notation
 - test for '!' handling in rev-parse's named commits

 Introduce "<branch>^{/!-<pattern>}" notation to name a commit
 reachable from <branch> that does not match the given <pattern>.


* ak/format-patch-odir-config (2016-01-11) 1 commit
 . format-patch: introduce format.outputDirectory configuration

 Allow "-o <dir>" option to be omitted on the command line of "git
 format-patch" if you always use the same directory in your
 workflow.

 Left out of 'pu' for now as t4014 seems to break with this topic.


* jk/notes-merge-from-anywhere (2015-12-29) 1 commit
 - notes: allow merging from arbitrary references

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

 Needs review.


* dk/reflog-walk-with-non-commit (2016-01-05) 1 commit
 - reflog-walk: don't segfault on non-commit sha1's in the reflog

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

 Will merge to 'next'.


* ew/send-email-mutt-alias-fix (2016-01-04) 1 commit
 - git-send-email: do not double-escape quotes from mutt

 "git send-email" was confused by escaped quotes stored in the alias
 files saved by "mutt".

 Will merge to 'next'.


* jk/clang-pedantic (2016-01-04) 2 commits
 - bswap: add NO_UNALIGNED_LOADS define
 - avoid shifting signed integers 31 bits

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

 Will merge to 'next'.


* ea/blame-progress (2015-12-16) 1 commit
  (merged to 'next' on 2015-12-22 at f8e8643)
 + blame: add support for --[no-]progress option

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

 Will merge to 'master'.


* dt/unpack-compare-entry-optim (2016-01-05) 1 commit
 - do_compare_entry: use already-computed path

 Will merge to 'next'.


* jk/pack-revindex (2015-12-21) 2 commits
 - pack-revindex: store entries directly in packed_git
 - pack-revindex: drop hash table

 Will merge to 'next'.


* jk/symbolic-ref (2016-01-11) 5 commits
 - lock_ref_sha1_basic: handle REF_NODEREF with invalid refs
 - checkout,clone: check return value of create_symref
 - create_symref: write reflog while holding lock
 - create_symref: use existing ref-lock code
 - create_symref: modernize variable names

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

 Will merge to 'next'.


* nd/stop-setenv-work-tree (2015-12-22) 1 commit
  (merged to 'next' on 2015-12-22 at 6d7bb0c)
 + Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
 (this branch is used by nd/clear-gitenv-upon-use-of-alias.)

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

 Will merge to 'master'.


* ep/update-command-substitution-style (2016-01-11) 70 commits
 - t/t9001-send-email.sh: use the $( ... ) construct for command substitution
 - t/t8003-blame-corner-cases.sh: use the $( ... ) construct for command substitution
 - t/t7700-repack.sh: use the $( ... ) construct for command substitution
 - t/t7602-merge-octopus-many.sh: use the $( ... ) construct for command substitution
 - t/t7505-prepare-commit-msg-hook.sh: use the $( ... ) construct for command substitution
 - t/t7504-commit-msg-hook.sh: use the $( ... ) construct for command substitution
 - t/t7408-submodule-reference.sh: use the $( ... ) construct for command substitution
 - t/t7406-submodule-update.sh: use the $( ... ) construct for command substitution
 - t/t7103-reset-bare.sh: use the $( ... ) construct for command substitution
 - t/t7006-pager.sh: use the $( ... ) construct for command substitution
 - t/t7004-tag.sh: use the $( ... ) construct for command substitution
 - t/t7003-filter-branch.sh: use the $( ... ) construct for command substitution
 - t/t7001-mv.sh: use the $( ... ) construct for command substitution
 - t/t6132-pathspec-exclude.sh: use the $( ... ) construct for command substitution
 - t/t6032-merge-large-rename.sh: use the $( ... ) construct for command substitution
 - t/t6015-rev-list-show-all-parents.sh: use the $( ... ) construct for command substitution
 - t/t6002-rev-list-bisect.sh: use the $( ... ) construct for command substitution
 - t/t6001-rev-list-graft.sh: use the $( ... ) construct for command substitution
 - t/t5900-repo-selection.sh: use the $( ... ) construct for command substitution
 - t/t5710-info-alternate.sh: use the $( ... ) construct for command substitution
 - t/t5700-clone-reference.sh: use the $( ... ) construct for command substitution
 - t/t5601-clone.sh: use the $( ... ) construct for command substitution
 - t/t5570-git-daemon.sh: use the $( ... ) construct for command substitution
 - t/t5550-http-fetch-dumb.sh: use the $( ... ) construct for command substitution
 - t/t5538-push-shallow.sh: use the $( ... ) construct for command substitution
 - t/t5537-fetch-shallow.sh: use the $( ... ) construct for command substitution
 - t/t5532-fetch-proxy.sh: use the $( ... ) construct for command substitution
 - t/t5530-upload-pack-error.sh: use the $( ... ) construct for command substitution
 - t/t5522-pull-symlink.sh: use the $( ... ) construct for command substitution
 - t/t5517-push-mirror.sh: use the $( ... ) construct for command substitution
 - t/t5516-fetch-push.sh: use the $( ... ) construct for command substitution
 - t/t5515-fetch-merge-logic.sh: use the $( ... ) construct for command substitution
 - t/t5510-fetch.sh: use the $( ... ) construct for command substitution
 - t/t5506-remote-groups.sh: use the $( ... ) construct for command substitution
 - t/t5505-remote.sh: use the $( ... ) construct for command substitution
 - t/t5500-fetch-pack.sh: use the $( ... ) construct for command substitution
 - t/t5305-include-tag.sh: use the $( ... ) construct for command substitution
 - t/t5304-prune.sh: use the $( ... ) construct for command substitution
 - t/t5303-pack-corruption-resilience.sh: use the $( ... ) construct for command substitution
 - t/t5100: no need to use 'echo' command substitutions for globbing
 - t/t5302-pack-index.sh: use the $( ... ) construct for command substitution
 - t/t5301-sliding-window.sh: use the $( ... ) construct for command substitution
 - t/t5300-pack-object.sh: use the $( ... ) construct for command substitution
 - t/t5100-mailinfo.sh: use the $( ... ) construct for command substitution
 - t/t3700-add.sh: use the $( ... ) construct for command substitution
 - t/t3600-rm.sh: use the $( ... ) construct for command substitution
 - t/t3511-cherry-pick-x.sh: use the $( ... ) construct for command substitution
 - t/t3403-rebase-skip.sh: use the $( ... ) construct for command substitution
 - t/t3210-pack-refs.sh: use the $( ... ) construct for command substitution
 - t/t3101-ls-tree-dirname.sh: use the $( ... ) construct for command substitution
 - t/t3100-ls-tree-restrict.sh: use the $( ... ) construct for command substitution
 - t/t3030-merge-recursive.sh: use the $( ... ) construct for command substitution
 - t/t2102-update-index-symlinks.sh: use the $( ... ) construct for command substitution
 - t/t2025-worktree-add.sh: use the $( ... ) construct for command substitution
 - t/t1700-split-index.sh: use the $( ... ) construct for command substitution
 - t/t1512-rev-parse-disambiguation.sh: use the $( ... ) construct for command substitution
 - t/t1511-rev-parse-caret.sh: use the $( ... ) construct for command substitution
 - t/t1410-reflog.sh: use the $( ... ) construct for command substitution
 - t/t1401-symbolic-ref.sh: use the $( ... ) construct for command substitution
 - t/t1100-commit-tree-options.sh: use the $( ... ) construct for command substitution
 - unimplemented.sh: use the $( ... ) construct for command substitution
 - test-sha1.sh: use the $( ... ) construct for command substitution
 - t/lib-httpd.sh: use the $( ... ) construct for command substitution
 - git-gui/po/glossary/txt-to-pot.sh: use the $( ... ) construct for command substitution
 - contrib/thunderbird-patch-inline/appp.sh: use the $( ... ) construct for command substitution
 - contrib/examples/git-revert.sh: use the $( ... ) construct for command substitution
 - contrib/examples/git-repack.sh: use the $( ... ) construct for command substitution
 - contrib/examples/git-merge.sh: use the $( ... ) construct for command substitution
 - contrib/examples/git-fetch.sh: use the $( ... ) construct for command substitution
 - contrib/examples/git-commit.sh: use the $( ... ) construct for command substitution

 A shell script style update to change `command substitution` into
 $(command substitution).  Coverts contrib/ and much of the t/
 directory contents.

 Will merge to 'next'.


* nd/dir-exclude-cleanup (2015-12-28) 1 commit
 - dir.c: clean the entire struct in clear_exclude_list()

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

 Will merge to 'next'.


* ss/user-manual (2015-12-30) 4 commits
 - user-manual: add addition gitweb information
 - user-manual: add section documenting shallow clones
 - glossary: define the term shallow clone
 - user-manual: remove temporary branch entry from todo list

 Drop a few old "todo" items by deciding that the change one of them
 suggests is not such a good idea, and doing the change the other
 one suggested to do.

 Will merge to 'next'.


* nd/ita-cleanup (2015-12-28) 3 commits
 - grep: make it clear i-t-a entries are ignored
 - add and use a convenience macro ce_intent_to_add()
 - blame: remove obsolete comment

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

 Here are only the obviously correct bits; some other changes were
 in the posted series, but not quite ready to be queued here.

 Will merge to 'next'.


* cc/untracked (2015-12-29) 10 commits
 - t7063: add tests for core.untrackedCache
 - config: add core.untrackedCache
 - dir: simplify untracked cache "ident" field
 - dir: add remove_untracked_cache()
 - dir: add {new,add}_untracked_cache()
 - update-index: move 'uc' var declaration
 - update-index: add untracked cache notifications
 - update-index: add --test-untracked-cache
 - update-index: use enum for untracked cache options
 - dir: free untracked cache when removing it

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

 Still being discussed and worked on.
 $gmane/283080


* ep/make-phoney (2015-12-16) 1 commit
  (merged to 'next' on 2015-12-22 at 27c7593)
 + Makefile: add missing phony target

 A slight update to the Makefile.

 Will merge to 'master'.


* vl/grep-configurable-threads (2015-12-16) 3 commits
  (merged to 'next' on 2015-12-22 at 8954705)
 + grep: add --threads=<num> option and grep.threads configuration
 + grep: slight refactoring to the code that disables threading
 + grep: allow threading even on a single-core machine

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

 Will merge to 'master'.


* ps/push-delete-option (2015-12-16) 2 commits
  (merged to 'next' on 2015-12-22 at d83cc1d)
 + push: add '-d' as shorthand for '--delete'
 + push: add '--delete' flag to synopsis

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

 Will merge to 'master'.


* dt/refs-backend-lmdb (2015-12-04) 16 commits
 - refs: tests for lmdb backend
 - refs: add LMDB refs backend
 - refs: allow ref backend to be set for clone
 - init: allow alternate backends to be set for new repos
 - refs: always handle non-normal refs in files backend
 - refs: move duplicate check to common code
 - refs: make lock generic
 - refs: add method to rename refs
 - refs: add methods to init refs backend and db
 - refs: add method for delete_refs
 - refs: add method for initial ref transaction commit
 - refs: add methods for reflog
 - refs: add do_for_each_per_worktree_ref
 - refs: add methods for the ref iterators
 - refs: add methods for misc ref operations
 - refs: add a backend method structure with transaction functions

 Building on top of a few refs-backend preparatory series, LMDB
 based refs backend has been plugged into the system.

 Still being discussed and worked on.


* dw/subtree-split-do-not-drop-merge (2015-12-10) 1 commit
 - contrib/subtree: fix "subtree split" skipped-merge bug

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

 Waiting for review from 'subtree' folks.


* nd/clear-gitenv-upon-use-of-alias (2015-12-29) 5 commits
 - run-command: don't warn on SIGPIPE deaths
 - git.c: make sure we do not leak GIT_* to alias scripts
 - setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..
 - git.c: make it clear save_env() is for alias handling only
 - Merge branch 'nd/stop-setenv-work-tree' into nd/clear-gitenv-upon-use-of-alias
 (this branch uses nd/stop-setenv-work-tree.)

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

 Will merge to 'next'.


* kn/ref-filter-atom-parsing (2016-01-05) 15 commits
 - ref-filter: introduce objectname_atom_parser()
 - ref-filter: introduce contents_atom_parser()
 - ref-filter: introduce remote_ref_atom_parser()
 - ref-filter: align: introduce long-form syntax
 - ref-filter: convert variable 'width' to an unsigned int
 - ref-filter: introduce parse_align_position()
 - ref-filter: introduce align_atom_parser()
 - ref-filter: introduce color_atom_parser()
 - ref-filter: skip deref specifier in match_atom_name()
 - ref-fitler: bump match_atom() name to the top
 - ref-filter: introduce parsing functions for each valid atom
 - ref-filter: introduce struct used_atom
 - ref-filter: bump 'used_atom' and related code to the top
 - ref-filter: use strbuf_split_str_omit_term()
 - strbuf: introduce strbuf_split_str_omit_term()

 Refactoring of ref-filter's format-parsing code, in preparation
 for "branch --format" and friends.

 This replaces (for now) kn/for-each-ref-remainder, which will be built
 on top.

 Still being discussed and worked on.


* bb/merge-marker-crlf (2015-11-24) 1 commit
 - merge-file: consider core.crlf when writing merge markers

 Write out merge markers using system end-of-line convention.

 Waiting for a re-roll to handle gitattributes.
 ($gmane/281701)


* dk/gc-more-wo-pack (2015-11-24) 3 commits
 - gc: Clean garbage .bitmap files from pack dir
 - t5304: Add test for .bitmap garbage files
 - prepare_packed_git(): find more garbage

 Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
 .bitmap and .keep files.

 Waiting for review.


* ps/rebase-keep-empty (2015-11-24) 2 commits
 - rebase: fix preserving commits with --keep-empty
 - rebase: test broken behavior with --keep-empty

 Keep duplicate commits via rebase --keep-empty.

 Of dubious or negative value.
 Will discard.
 ($gmane/282107).


* rm/subtree-unwrap-tags (2015-11-24) 1 commit
 - contrib/subtree: unwrap tag refs

 Waiting for review from subtree folks.


* sg/sh-require-clean-orphan (2015-11-24) 2 commits
 - sh-setup: make require_clean_work_tree() work on orphan branches
 - Add tests for git-sh-setup's require_clean_work_tree()

 Allow users of git-sh-setup to handle orphan branch state.

 This series takes the conservative route of requiring scripts to opt
 into the looser behavior, at the expense of carrying around a new
 option-flag forever. I'm not sure if we need to do so.

 Needs review.


* tb/ls-files-eol (2016-01-07) 1 commit
 - ls-files: add eol diagnostics

 Add options to ls-files to help diagnose end-of-line problems.

 Needs review.


* ec/annotate-deleted (2015-11-20) 1 commit
 - annotate: skip checking working tree if a revision is provided

 Usability fix for annotate-specific "<file> <rev>" syntax with deleted
 files.

 Waiting for review.


* sb/submodule-parallel-fetch (2015-12-16) 7 commits
  (merged to 'next' on 2015-12-22 at 44e84ff)
 + submodules: allow parallel fetching, add tests and documentation
 + fetch_populated_submodules: use new parallel job processing
 + run-command: add an asynchronous parallel child processor
 + sigchain: add command to pop all common signals
 + strbuf: add strbuf_read_once to read without blocking
 + xread: poll on non blocking fds
 + submodule.c: write "Fetching submodule <foo>" to stderr
 (this branch is used by sb/submodule-parallel-update.)

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

 Rerolled and this seems to be a lot cleaner.  The merge of the
 earlier one to 'next' has been reverted.

 Will merge to 'master'.


* sb/submodule-parallel-update (2015-12-16) 8 commits
 - clone: allow an explicit argument for parallel submodule clones
 - submodule update: expose parallelism to the user
 - git submodule update: have a dedicated helper for cloning
 - fetching submodules: respect `submodule.fetchJobs` config option
 - submodule-config: introduce parse_generic_submodule_config
 - submodule-config: remove name_and_item_from_var
 - submodule-config: drop check against NULL
 - submodule-config: keep update strategy around
 (this branch uses sb/submodule-parallel-fetch.)

 Builds on top of the "fetch --recurse-submodules" work to introduce
 parallel downloading into multiple submodules for "submodule update".

 Needs review.


* jc/strbuf-gets (2015-12-16) 17 commits
 - test-sha1-array: read command stream with strbuf_getline_crlf()
 - grep: read -f file with strbuf_getline_crlf()
 - send-pack: read list of refs with strbuf_getline_crlf()
 - column: read lines with strbuf_getline_crlf()
 - cat-file: read batch stream with strbuf_getline_crlf()
 - transport-helper: read helper response with strbuf_getline_crlf()
 - clone/sha1_file: read info/alternates with strbuf_getline_crlf()
 - remote.c: read $GIT_DIR/remotes/* with strbuf_getline_crlf()
 - ident.c: read /etc/mailname with strbuf_getline_crlf()
 - rev-parse: read parseopt spec with strbuf_getline_crlf()
 - revision: read --stdin with strbuf_getline_crlf()
 - hash-object: read --stdin-paths with strbuf_getline_crlf()
 - mktree: read textual tree representation with strbuf_getline_crlf()
 - update-index: read list of paths with strbuf_getline_crlf() under --stdin
 - update-index: read --index-info with strbuf_getline_crlf()
 - check-attr, check-ignore, checkout-index: read paths with strbuf_getline_crlf()
 - strbuf: make strbuf_getline_crlf() global

 Teach codepaths that communicate with users by reading text files
 to be more lenient to editors that write CRLF-terminated lines.
 Note that this is only about communication with Git, like feeding
 list of object names from the standard input instead of from the
 command line, and does not involve files in the working tree.

 Rerolled.
 Needs review.


* mh/notes-allow-reading-treeish (2015-10-08) 3 commits
  (merged to 'next' on 2015-10-23 at 8a697f0)
 + notes: allow treeish expressions as notes ref
 + Merge branch 'jk/notes-dwim-doc' into next
 + Merge branch 'jc/merge-drop-old-syntax' into next
 (this branch uses jc/merge-drop-old-syntax.)

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

 As the patch was done on top of the 'drop old-syntax from merge',
 this has to wait until that other topic can graduate, unfortunately.
 It can be redone in a way that does not depend on that topic after
 this cycle, though.

 Will keep in 'next'.


* jc/mailinfo (2015-10-21) 1 commit
 - mailinfo: ignore in-body header that we do not care about

 Some people write arbitrary garbage at the beginning of a piece of
 e-mail (or after -- >8 -- scissors -- >8 -- line) in the commit log
 message and expect them to be discarded, even though "From:" and
 "Subject:" are the only documented in-body headers that you are
 supposed to have there.  Allow some garbage (specifically, what may
 look like RFC2822 headers like "MIME-Version: ...") to be there and
 ignore them.

 No comments after waiting for a long time.
 Will discard.


* js/am-3-merge-recursive-direct (2015-10-12) 2 commits
  (merged to 'next' on 2015-10-23 at dc631e5)
 + am: make a direct call to merge_recursive
 + merge_recursive_options: introduce the "gently" flag

 The merge_recursive_generic() function has been made a bit safer to
 call from inside a process.  "git am -3" was taught to make a direct
 call to the function when falling back to three-way merge.

 Being able to make a direct call would be good in general, but as a
 performance thing, we would want to see it backed up by numbers.

 I haven't gone through the "gently" change with fine toothed comb;
 I can see that the change avoids calling die(), but I haven't made
 sure that the program states (e.g. what's in the in-core index) are
 adjusted sensibly when it returns to the caller instead of dying,
 or the codepaths that used to die() are free of resource leaks.
 The original code certainly did not care the program states at the
 point of dying exactly because it knew it is going to exit, but now
 they have to care, and they need to be audited.

 Will keep in 'next'.


* sg/pretty-more-date-mode-format (2015-10-07) 1 commit
 - pretty: add format specifiers for short and raw date formats

 Introduce "%as" and "%aR" placeholders for "log --format" to show
 the author date in the short and raw formats.

 No comments after waiting for a long time.
 Will discard.


* jk/graph-format-padding (2015-09-14) 1 commit
 - pretty: pass graph width to pretty formatting for use in '%>|(N)'

 Redefine the way '%>|(N)' padding and the "--graph" option
 interacts.  It has been that the available columns to display the
 log message was measured from the edge of the area the graph ended,
 but with this it becomes the beginning of the entire output.

 I have a suspicion that 50% of the users would appreciate this
 change, and the remainder see this break their expectation.  If
 that is the case, we might need to introduce a similar but
 different alignment operator so that this new behaviour is
 available to those who want to use it, without negatively affecting
 existing uses.

 No comments after waiting for a long time.
 Will discard.
 ($gmane/278326)


* ad/cygwin-wants-rename (2015-08-07) 1 commit
 - config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES

 Will hold.
 ($gmane/275680).


* jc/rerere-multi (2015-09-14) 7 commits
 - rerere: do use multiple variants
 - t4200: rerere a merge with two identical conflicts
 - rerere: allow multiple variants to exist
 - rerere: delay the recording of preimage
 - rerere: handle leftover rr-cache/$ID directory and postimage files
 - rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id
 - rerere: split conflict ID further

 "git rerere" can encounter two or more files with the same conflict
 signature that have to be resolved in different ways, but there was
 no way to record these separate resolutions.

 Needs review.


* jc/merge-drop-old-syntax (2015-04-29) 1 commit
  (merged to 'next' on 2015-10-07 at 50fed71)
 + merge: drop 'git merge <message> HEAD <commit>' syntax
 (this branch is used by mh/notes-allow-reading-treeish.)

 Originally merged to 'next' on 2015-05-28

 Stop supporting "git merge <message> HEAD <commit>" syntax that has
 been deprecated since October 2007.  It has been reported that
 git-gui still uses the deprecated syntax, which needs to be fixed
 before this final step can proceed.
 ($gmane/282594)

 Will keep in 'next'.

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Mike Hommey]

On Mon, Jan 11, 2016 at 03:45:35PM -0800, Junio C Hamano wrote:
> * mh/notes-allow-reading-treeish (2015-10-08) 3 commits
>   (merged to 'next' on 2015-10-23 at 8a697f0)
>  + notes: allow treeish expressions as notes ref
>  + Merge branch 'jk/notes-dwim-doc' into next
>  + Merge branch 'jc/merge-drop-old-syntax' into next
>  (this branch uses jc/merge-drop-old-syntax.)
> 
>  Some "git notes" operations, e.g. "git log --notes=<note>", should
>  be able to read notes from any tree-ish that is shaped like a notes
>  tree, but the notes infrastructure required that the argument must
>  be a ref under refs/notes/.  Loosen it to require a valid ref only
>  when the operation would update the notes (in which case we must
>  have a place to store the updated notes tree, iow, a ref).
> 
>  As the patch was done on top of the 'drop old-syntax from merge',
>  this has to wait until that other topic can graduate, unfortunately.
>  It can be redone in a way that does not depend on that topic after
>  this cycle, though.

I'm not sure what you mean here. The patch applies just fine on top of
current master.

Mike

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> On Mon, Jan 11, 2016 at 03:45:35PM -0800, Junio C Hamano wrote:
>> * mh/notes-allow-reading-treeish (2015-10-08) 3 commits
>>   (merged to 'next' on 2015-10-23 at 8a697f0)
>>  + notes: allow treeish expressions as notes ref
>>  + Merge branch 'jk/notes-dwim-doc' into next
>>  + Merge branch 'jc/merge-drop-old-syntax' into next
>>  (this branch uses jc/merge-drop-old-syntax.)
>> 
>>  Some "git notes" operations, e.g. "git log --notes=<note>", should
>>  be able to read notes from any tree-ish that is shaped like a notes
>>  tree, but the notes infrastructure required that the argument must
>>  be a ref under refs/notes/.  Loosen it to require a valid ref only
>>  when the operation would update the notes (in which case we must
>>  have a place to store the updated notes tree, iow, a ref).
>> 
>>  As the patch was done on top of the 'drop old-syntax from merge',
>>  this has to wait until that other topic can graduate, unfortunately.
>>  It can be redone in a way that does not depend on that topic after
>>  this cycle, though.
>
> I'm not sure what you mean here. The patch applies just fine on top of
> current master.

I exactly mean what I wrote ;-).

IIRC, back when the patch was queued, it wasn't directly applicable
to the tip of the master branch (I suspect that you made a patch
against 'next'), and the two topics you can see merged above turned
out to be the ones your change was textually depending on.  Because
at least one of them was slated to be kept in 'next' during the 2.7
cycle, and because we do not rewind 'next' in the middle of a cycle,
this made the patch at the tip of this topic to be ineligible for
merging to 'master' without dragging the other topics that were not
meant for 'master'.

Post release is a rare occasion that we can rewind and rebuild
'next', so you can simply send an updated patch that would apply
cleanly to the tip of 'master' (which is a lot newer than the tip of
'master' back then, and possibly have merged quite a lot of changes
from either of the two other topics your patch depends on) and tell
me "Drop that old copy queued in 'next' and replace it with this new
one when you rebuild 'next'".  If the old patch is identical to such
a patch, then just telling me "When you rebuild 'next', rebuild the
topic by just cherry-picking the tip of the topic directly to the
tip of 'master', as all the prerequisite changes have been merged
already" would be sufficient.

Which I guess you just did ;-).  I haven't checked if the
changes you depended on are all in 'master' already, but if that is
the case, then I'll do just that--if you see me forgetting to do so
when I rewind 'next', please holler.

Thanks.

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Edmundo Carmona Antoranz]

Sup, Junio!

On Mon, Jan 11, 2016 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
>
.
.
.
> * ec/annotate-deleted (2015-11-20) 1 commit
>  - annotate: skip checking working tree if a revision is provided
>
>  Usability fix for annotate-specific "<file> <rev>" syntax with deleted
>  files.
>
>  Waiting for review.
>
>

Dude, this is waiting for you to decide if it's OK to go down this
path or not _but_ it's not that important anyway so feel free to drop
it so no more brain CPU time is spent on it when writing 'What's
cooking'. It's ok.

Cheers!

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Johannes Schindelin]

Hi Junio,

On Mon, 11 Jan 2016, Junio C Hamano wrote:

> * jc/strbuf-gets (2015-12-16) 17 commits
>  - test-sha1-array: read command stream with strbuf_getline_crlf()
>  - grep: read -f file with strbuf_getline_crlf()
>  - send-pack: read list of refs with strbuf_getline_crlf()
>  - column: read lines with strbuf_getline_crlf()
>  - cat-file: read batch stream with strbuf_getline_crlf()
>  - transport-helper: read helper response with strbuf_getline_crlf()
>  - clone/sha1_file: read info/alternates with strbuf_getline_crlf()
>  - remote.c: read $GIT_DIR/remotes/* with strbuf_getline_crlf()
>  - ident.c: read /etc/mailname with strbuf_getline_crlf()
>  - rev-parse: read parseopt spec with strbuf_getline_crlf()
>  - revision: read --stdin with strbuf_getline_crlf()
>  - hash-object: read --stdin-paths with strbuf_getline_crlf()
>  - mktree: read textual tree representation with strbuf_getline_crlf()
>  - update-index: read list of paths with strbuf_getline_crlf() under --stdin
>  - update-index: read --index-info with strbuf_getline_crlf()
>  - check-attr, check-ignore, checkout-index: read paths with strbuf_getline_crlf()
>  - strbuf: make strbuf_getline_crlf() global
> 
>  Teach codepaths that communicate with users by reading text files
>  to be more lenient to editors that write CRLF-terminated lines.
>  Note that this is only about communication with Git, like feeding
>  list of object names from the standard input instead of from the
>  command line, and does not involve files in the working tree.
> 
>  Rerolled.
>  Needs review.

Actually, it waits for a re-roll ;-)

Ciao,
Dscho

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>>  Rerolled.
>>  Needs review.
>
> Actually, it waits for a re-roll ;-)

True.

I think strbuf_getline() that handles the payload as "text" without
having _crlf() suffix is an ideal endgame in the longer term, but I
do not think it is a good idea to do that as a flag-day change.  So
I am inclined not to change the function names around that feature
in this series.  Others can do the wholesale rename as a separate
follow-up topic when the tree is quiescent.

The other point "We prepared to be able to use line termination
other than LF and NUL, but in practice nobody uses other values, so
tighten the interface to clarify that we allow only these two
values" you raised is something I think should be done as a
preparatory step for this series, as the correctness of the series
depends heavily on that assumption that nobody ever uses any other
value than LF or NUL.  I am looking at it but haven't published any
progress yet.

Thanks.

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Jeff King]

On Tue, Jan 12, 2016 at 10:47:25AM -0800, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >>  Rerolled.
> >>  Needs review.
> >
> > Actually, it waits for a re-roll ;-)
> 
> True.
> 
> I think strbuf_getline() that handles the payload as "text" without
> having _crlf() suffix is an ideal endgame in the longer term, but I
> do not think it is a good idea to do that as a flag-day change.  So
> I am inclined not to change the function names around that feature
> in this series.  Others can do the wholesale rename as a separate
> follow-up topic when the tree is quiescent.

Yeah, I think we would want to catch topics in flight. Should the end of
this series then be to _remove_ strbuf_getline()? Callers should be
using strbuf_getline_crlf() if they want text lines, and
strbuf_getdelim() if they do not.

Topics in flight will need fixed up, but that's OK; the breakage (and
the fix) will be obvious.

And then after a quiet period we can drop the "_crlf()" and have
strbuf_getline() back.

-Peff

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Jan 12, 2016 at 10:47:25AM -0800, Junio C Hamano wrote:
>
>> I think strbuf_getline() that handles the payload as "text" without
>> having _crlf() suffix is an ideal endgame in the longer term, but I
>> do not think it is a good idea to do that as a flag-day change.  So
>> I am inclined not to change the function names around that feature
>> in this series.  Others can do the wholesale rename as a separate
>> follow-up topic when the tree is quiescent.
>
> Yeah, I think we would want to catch topics in flight. Should the end of
> this series then be to _remove_ strbuf_getline()? Callers should be
> using strbuf_getline_crlf() if they want text lines, and
> strbuf_getdelim() if they do not.
>
> Topics in flight will need fixed up, but that's OK; the breakage (and
> the fix) will be obvious.
>
> And then after a quiet period we can drop the "_crlf()" and have
> strbuf_getline() back.

Actually, I think a patch that

 - renames strbuf_getline() to strbuf_getdelim(); and
 - renames strbuf_getline_crlf() to strbuf_getline() 

on top of the series we already have is sufficient to bring the
endgame state to us.  The new strbuf_getline() has a different
function signature from the traditional one, so any topic in flight
that is unaware of this series can easily be caught, and we can do
this without a quiet period.

A more interesting question is if strbuf_getdelim() should take an
arbitrary byte as its third parameter.  As I said elsewhere, the
only reason why it is not a "do we use LF or do we use NUL?"
boolean is because I wrote these codepaths anticipating that there
might be a value other than NUL and LF that could be useful when I
introduced line_termination long time ago, but no useful caller that
uses other useful value has emerged, so I think the interface was
too broad and too general for its own good.

It becomes very tempting not to do strbuf_getdelim() at all, but
instead rewrite the current calls to strbuf_getline() to call one of
two functions, i.e. strbuf_getline_lf() and strbuf_getline_nul(),
when we rename strbuf_getline_crlf() to strbuf_getline().

By going that route, those who want to help CRLF situation further
can then concentrate on output from "git grep strbuf_getline_lf()",
identify the ones that can be safely turned into strbuf_getline(),
and do the conversion.

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Jeff King]

On Wed, Jan 13, 2016 at 03:07:13PM -0800, Junio C Hamano wrote:

> > And then after a quiet period we can drop the "_crlf()" and have
> > strbuf_getline() back.
> 
> Actually, I think a patch that
> 
>  - renames strbuf_getline() to strbuf_getdelim(); and
>  - renames strbuf_getline_crlf() to strbuf_getline() 
> 
> on top of the series we already have is sufficient to bring the
> endgame state to us.  The new strbuf_getline() has a different
> function signature from the traditional one, so any topic in flight
> that is unaware of this series can easily be caught, and we can do
> this without a quiet period.

Ah, right, I forgot about the changed function signature.

> A more interesting question is if strbuf_getdelim() should take an
> arbitrary byte as its third parameter.  As I said elsewhere, the
> only reason why it is not a "do we use LF or do we use NUL?"
> boolean is because I wrote these codepaths anticipating that there
> might be a value other than NUL and LF that could be useful when I
> introduced line_termination long time ago, but no useful caller that
> uses other useful value has emerged, so I think the interface was
> too broad and too general for its own good.
> 
> It becomes very tempting not to do strbuf_getdelim() at all, but
> instead rewrite the current calls to strbuf_getline() to call one of
> two functions, i.e. strbuf_getline_lf() and strbuf_getline_nul(),
> when we rename strbuf_getline_crlf() to strbuf_getline().

I think you'll end up with some of the callers being a bit uglier. I.e.,
where we say:

  strbuf_getline(&buf, in, delim);

and "delim" is set elsewhere. These will become:

  if (delim == '\n') /* or maybe even "if (nul_terminate)" */
	strbuf_getline_lf(&buf, in);
  else
	strbuf_getline_nul(&buf, in);

which is a bit less nice.  But I guess these cases already need to
become uglier if we want them to handle CRLF. Unless we want to wrap the
idiom as:

  int strbuf_get_record(struct strbuf *buf,
			FILE *in,
			enum { STRBUF_RECORD_LINE,
			       STRBUF_RECORD_NUL
			     } delim);

and then "-z" option parsers use STRBUF_RECORD_NUL instead of setting a
char to '\0'.

> By going that route, those who want to help CRLF situation further
> can then concentrate on output from "git grep strbuf_getline_lf()",
> identify the ones that can be safely turned into strbuf_getline(),
> and do the conversion.

I'm not sure that is any easier than just grepping for strbuf_delim()
that takes '\n').

-Peff

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I think you'll end up with some of the callers being a bit uglier. I.e.,
> where we say:
>
>   strbuf_getline(&buf, in, delim);
>
> and "delim" is set elsewhere. These will become:
>
>   if (delim == '\n') /* or maybe even "if (nul_terminate)" */
> 	strbuf_getline_lf(&buf, in);
>   else
> 	strbuf_getline_nul(&buf, in);

My plan is to use a function pointer to switch between them.  A code
like the above in practice look more like

(1) there is a config/option parser that sets line_terminator that
    is typically a file-scope global.

	if (z_option)
        	line_terminator = '\0';
	else
        	line_terminator = '\n';

(2) the callsite calls getline with it

	strbuf_getline(..., line_terminator);

So we can introduce a file-scope global, (*getline_fn)(), and then
tweak (1) by removing line_terminator and replacing the assignment
with an assignment to getline_fn.

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

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

> My plan is to use a function pointer to switch between them.  A code
> like the above in practice look more like
>
> (1) there is a config/option parser that sets line_terminator that
>     is typically a file-scope global.
>
> 	if (z_option)
>         	line_terminator = '\0';
> 	else
>         	line_terminator = '\n';
>
> (2) the callsite calls getline with it
>
> 	strbuf_getline(..., line_terminator);
>
> So we can introduce a file-scope global, (*getline_fn)(), and then
> tweak (1) by removing line_terminator and replacing the assignment
> with an assignment to getline_fn.

And after doing the obvious wholesale replacement on callers that
hardcode either '\n' or '\0' with this:

#!/bin/sh
perl -i -p -e '
	s/strbuf_getline\((.*?), '\''\\n'\''\)/strbuf_getline_lf($1)/g;
	s/strbuf_getline\((.*?), '\''\\0'\''\)/strbuf_getline_nul($1)/g;
' "$@"

the only direct callers of strbuf_getline() that remain in the tree
are check-attr, check-ignore, checkout-index and mktree.

And the conversion of mktree would look like this.  I might further
tweak it to rename and flip the polarity of lf_lines to nul_lines,
but I do not think that matters very much.

 builtin/mktree.c | 15 +++++++++------
 strbuf.h         |  3 +++
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/builtin/mktree.c b/builtin/mktree.c
index a964d6b..7633d35 100644
--- a/builtin/mktree.c
+++ b/builtin/mktree.c
@@ -65,7 +65,7 @@ static const char *mktree_usage[] = {
 	NULL
 };
 
-static void mktree_line(char *buf, size_t len, int line_termination, int allow_missing)
+static void mktree_line(char *buf, size_t len, int lf_lines, int allow_missing)
 {
 	char *ptr, *ntr;
 	unsigned mode;
@@ -97,7 +97,7 @@ static void mktree_line(char *buf, size_t len, int line_termination, int allow_m
 	*ntr++ = 0; /* now at the beginning of SHA1 */
 
 	path = ntr + 41;  /* at the beginning of name */
-	if (line_termination && path[0] == '"') {
+	if (lf_lines && path[0] == '"') {
 		struct strbuf p_uq = STRBUF_INIT;
 		if (unquote_c_style(&p_uq, path, NULL))
 			die("invalid quoting");
@@ -141,13 +141,14 @@ int cmd_mktree(int ac, const char **av, const char *prefix)
 {
 	struct strbuf sb = STRBUF_INIT;
 	unsigned char sha1[20];
-	int line_termination = '\n';
+	int lf_lines = 1;
 	int allow_missing = 0;
 	int is_batch_mode = 0;
 	int got_eof = 0;
+	strbuf_getline_fn getline_fn;
 
 	const struct option option[] = {
-		OPT_SET_INT('z', NULL, &line_termination, N_("input is NUL terminated"), '\0'),
+		OPT_SET_INT('z', NULL, &lf_lines, N_("input is NUL terminated"), '\0'),
 		OPT_SET_INT( 0 , "missing", &allow_missing, N_("allow missing objects"), 1),
 		OPT_SET_INT( 0 , "batch", &is_batch_mode, N_("allow creation of more than one tree"), 1),
 		OPT_END()
@@ -155,9 +156,11 @@ int cmd_mktree(int ac, const char **av, const char *prefix)
 
 	ac = parse_options(ac, av, prefix, option, mktree_usage, 0);
 
+	getline_fn = lf_lines ? strbuf_getline_lf : strbuf_getline_nul;
+
 	while (!got_eof) {
 		while (1) {
-			if (strbuf_getline(&sb, stdin, line_termination) == EOF) {
+			if (getline_fn(&sb, stdin) == EOF) {
 				got_eof = 1;
 				break;
 			}
@@ -167,7 +170,7 @@ int cmd_mktree(int ac, const char **av, const char *prefix)
 					break;
 				die("input format error: (blank line only valid in batch mode)");
 			}
-			mktree_line(sb.buf, sb.len, line_termination, allow_missing);
+			mktree_line(sb.buf, sb.len, lf_lines, allow_missing);
 		}
 		if (is_batch_mode && got_eof && used < 1) {
 			/*
diff --git a/strbuf.h b/strbuf.h
index db053be..9c8d715 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -405,6 +405,9 @@ static inline int strbuf_getline_nul(struct strbuf *sb, FILE *fp)
 	return strbuf_getline(sb, fp, '\0');
 }
 
+typedef int (*strbuf_getline_fn)(struct strbuf *, FILE *);
+
+
 /**
  * Like `strbuf_getline`, but keeps the trailing terminator (if
  * any) in the buffer.

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Jeff King]

On Wed, Jan 13, 2016 at 03:54:05PM -0800, Junio C Hamano wrote:

> And after doing the obvious wholesale replacement on callers that
> hardcode either '\n' or '\0' with this:
> 
> #!/bin/sh
> perl -i -p -e '
> 	s/strbuf_getline\((.*?), '\''\\n'\''\)/strbuf_getline_lf($1)/g;
> 	s/strbuf_getline\((.*?), '\''\\0'\''\)/strbuf_getline_nul($1)/g;
> ' "$@"
> 
> the only direct callers of strbuf_getline() that remain in the tree
> are check-attr, check-ignore, checkout-index and mktree.
> 
> And the conversion of mktree would look like this.  I might further
> tweak it to rename and flip the polarity of lf_lines to nul_lines,
> but I do not think that matters very much.

Heh. I read your series first, and independently came up with the same
polarity-flipping thought. I agree it doesn't matter much, but maybe we
can count that as two votes. :)

-Peff

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[David A. Greene]

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

> * dw/subtree-split-do-not-drop-merge (2015-12-10) 1 commit
>  - contrib/subtree: fix "subtree split" skipped-merge bug
>
>  The "split" subcommand of "git subtree" (in contrib/) incorrectly
>  skipped merges when it shouldn't, which was corrected.
>
>  Waiting for review from 'subtree' folks.

Just saw this one now.  I'm sorry I missed it.  I will go review the
latest version of that.

> * rm/subtree-unwrap-tags (2015-11-24) 1 commit
>  - contrib/subtree: unwrap tag refs
>
>  Waiting for review from subtree folks.

Looks good.  I just sent (very late) follow-up messages.

                          -David

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 12.01.2016 00:45:

> 
> * mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
>  - t/lib-git-svn: check same httpd module dirs as lib-httpd
>  - t/lib-httpd: load mod_unixd
> 
>  This is the first two commits in a three-patch series $gmane/266962
> 
>  Becoming tired of waiting for a reroll.
>  with updated log message ($gmane/268061).
>  Will discard.

Oh, sorry. Work killing me plus I was waiting for help, too.

I don't care for these tests myself. I just noticed we're not really
running them (resp. are running them locally only) due to the noted
problems, i.e. default configs in which we fail to start the server.

Michael

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Jeff King]

On Mon, Jan 18, 2016 at 02:35:24PM +0100, Michael J Gruber wrote:

> Junio C Hamano venit, vidit, dixit 12.01.2016 00:45:
> 
> > 
> > * mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
> >  - t/lib-git-svn: check same httpd module dirs as lib-httpd
> >  - t/lib-httpd: load mod_unixd
> > 
> >  This is the first two commits in a three-patch series $gmane/266962
> > 
> >  Becoming tired of waiting for a reroll.
> >  with updated log message ($gmane/268061).
> >  Will discard.
> 
> Oh, sorry. Work killing me plus I was waiting for help, too.
> 
> I don't care for these tests myself. I just noticed we're not really
> running them (resp. are running them locally only) due to the noted
> problems, i.e. default configs in which we fail to start the server.

FWIW, I took a look at them a few months ago, but I couldn't reproduce
the problems in the first place. I think it has to do with the default
apache setup given by my system (debian unstable) versus others.

-Peff

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Eric Wong]

Jeff King <peff@peff.net> wrote:
> On Mon, Jan 18, 2016 at 02:35:24PM +0100, Michael J Gruber wrote:
> > Junio C Hamano venit, vidit, dixit 12.01.2016 00:45:
> > > 
> > > * mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits

> > >  Will discard.
> > 
> > Oh, sorry. Work killing me plus I was waiting for help, too.
> 
> FWIW, I took a look at them a few months ago, but I couldn't reproduce
> the problems in the first place. I think it has to do with the default
> apache setup given by my system (debian unstable) versus others.

Ugh, I was meaning to look into these too (after upgrading to
Debian Jessie), but maybe it needs to be tested on Fedora/RH-based
configs?

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Michael J Gruber]

Eric Wong venit, vidit, dixit 18.01.2016 22:39:
> Jeff King <peff@peff.net> wrote:
>> On Mon, Jan 18, 2016 at 02:35:24PM +0100, Michael J Gruber wrote:
>>> Junio C Hamano venit, vidit, dixit 12.01.2016 00:45:
>>>>
>>>> * mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
> 
>>>>  Will discard.
>>>
>>> Oh, sorry. Work killing me plus I was waiting for help, too.
>>
>> FWIW, I took a look at them a few months ago, but I couldn't reproduce
>> the problems in the first place. I think it has to do with the default
>> apache setup given by my system (debian unstable) versus others.
> 
> Ugh, I was meaning to look into these too (after upgrading to
> Debian Jessie), but maybe it needs to be tested on Fedora/RH-based
> configs?

It needs to be tested with a "default config" I think, in the sense of
"apache 2.4 default". Fedora seems to use the default config which is
different from earlier apaches' defaults.

Debian uses a config which is not the 2.4 default but makes switching
from earlier apaches easier.

Back then, I was only able to get half way to running the git svn tests
over http. I think I got our test suite to start http and run the git
over http tests that didn't run before on Fedora, but I couldn't get git
svn over http tests to run (so that they are run via local protocol
instead). I'll keep it in mind, though.

Michael

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Duy Nguyen]

On Tue, Jan 12, 2016 at 6:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * jk/graph-format-padding (2015-09-14) 1 commit
>  - pretty: pass graph width to pretty formatting for use in '%>|(N)'
>
>  Redefine the way '%>|(N)' padding and the "--graph" option
>  interacts.  It has been that the available columns to display the
>  log message was measured from the edge of the area the graph ended,
>  but with this it becomes the beginning of the entire output.
>
>  I have a suspicion that 50% of the users would appreciate this
>  change, and the remainder see this break their expectation.  If
>  that is the case, we might need to introduce a similar but
>  different alignment operator so that this new behaviour is
>  available to those who want to use it, without negatively affecting
>  existing uses.
>
>  No comments after waiting for a long time.
>  Will discard.
>  ($gmane/278326)

I carried this in my tree and didn't realize it's dropped from 'pu'.
There's actually a comment last month [1]. By your last comment, does
it mean I should check if "it" breaks anything to resurrect this one?

[1] http://thread.gmane.org/gmane.comp.version-control.git/277710/focus=282886
-- 
Duy

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Tue, Jan 12, 2016 at 6:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * jk/graph-format-padding (2015-09-14) 1 commit
>>  - pretty: pass graph width to pretty formatting for use in '%>|(N)'
>>
>>  Redefine the way '%>|(N)' padding and the "--graph" option
>>  interacts.  It has been that the available columns to display the
>>  log message was measured from the edge of the area the graph ended,
>>  but with this it becomes the beginning of the entire output.
>>
>>  I have a suspicion that 50% of the users would appreciate this
>>  change, and the remainder see this break their expectation.  If
>>  that is the case, we might need to introduce a similar but
>>  different alignment operator so that this new behaviour is
>>  available to those who want to use it, without negatively affecting
>>  existing uses.
>>
>>  No comments after waiting for a long time.
>>  Will discard.
>>  ($gmane/278326)
>
> I carried this in my tree and didn't realize it's dropped from 'pu'.
> There's actually a comment last month [1]. By your last comment, does
> it mean I should check if "it" breaks anything to resurrect this one?
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/277710/focus=282886

Ahh, yes, I remember that your response was that the patch is good
and we do not need a new separate way (as there already is one)
to specify the other behaviour.  So if that is truly the case (I
didn't check it), we would certainly want to resurrect it, as there
wouldn't be any downside to it.

Thanks.