All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Jan 2017, #04; Mon, 23)
@ 2017-01-24  0:18 Junio C Hamano
  2017-01-24 10:04 ` Lars Schneider
  2017-01-25 18:38 ` Stefan Beller
  0 siblings, 2 replies; 15+ messages in thread
From: Junio C Hamano @ 2017-01-24  0:18 UTC (permalink / raw)
  To: git

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.

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

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

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

* ad/bisect-terms (2017-01-13) 1 commit
  (merged to 'next' on 2017-01-18 at 9f500d6cf5)
 + Documentation/bisect: improve on (bad|new) and (good|bad)

 Documentation fix.


* bw/read-blob-data-does-not-modify-index-state (2017-01-11) 1 commit
  (merged to 'next' on 2017-01-18 at f33363fb07)
 + index: improve constness for reading blob data

 Code clean-up.


* jk/grep-e-could-be-extended-beyond-posix (2017-01-11) 1 commit
  (merged to 'next' on 2017-01-18 at dd1b9d1fa8)
 + t7810: avoid assumption about invalid regex syntax

 Tighten a test to avoid mistaking an extended ERE regexp engine as
 a PRE regexp engine.


* rh/diff-orderfile-doc (2017-01-15) 2 commits
  (merged to 'next' on 2017-01-18 at cc2af9c628)
 + diff: document the format of the -O (diff.orderFile) file
 + diff: document behavior of relative diff.orderFile

 Documentation fix.


* sb/cd-then-git-can-be-written-as-git-c (2017-01-13) 1 commit
  (merged to 'next' on 2017-01-18 at 8923d2d001)
 + lib-submodule-update.sh: reduce use of subshell by using "git -C"

 Test clean-up.


* sb/submodule-config-tests (2017-01-12) 2 commits
  (merged to 'next' on 2017-01-18 at bd850f6ad3)
 + t7411: test lookup of uninitialized submodules
 + t7411: quote URLs

 Test updates.


* sb/submodule-embed-gitdir (2017-01-12) 1 commit
  (merged to 'next' on 2017-01-18 at 0a5e24a3f0)
 + submodule absorbgitdirs: mention in docstring help

 Help-text fix.


* sb/submodule-init (2017-01-12) 1 commit
  (merged to 'next' on 2017-01-18 at 2e8a38b1cc)
 + submodule update --init: display correct path from submodule

 Error message fix.


* sg/fix-versioncmp-with-common-suffix (2017-01-12) 8 commits
  (merged to 'next' on 2017-01-18 at f79c24a291)
 + versioncmp: generalize version sort suffix reordering
 + versioncmp: factor out helper for suffix matching
 + versioncmp: use earliest-longest contained suffix to determine sorting order
 + versioncmp: cope with common part overlapping with prerelease suffix
 + versioncmp: pass full tagnames to swap_prereleases()
 + t7004-tag: add version sort tests to show prerelease reordering issues
 + t7004-tag: use test_config helper
 + t7004-tag: delete unnecessary tags with test_when_finished

 The prereleaseSuffix feature of version comparison that is used in
 "git tag -l" did not correctly when two or more prereleases for the
 same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
 are there and the code needs to compare 2.0-beta1 and 2.0-beta2).


* vn/diff-ihc-config (2017-01-12) 1 commit
  (merged to 'next' on 2017-01-18 at ac4915dbe6)
 + diff: add interhunk context config option

 "git diff" learned diff.interHunkContext configuration variable
 that gives the default value for its --inter-hunk-context option.


* ws/request-pull-code-cleanup (2017-01-15) 1 commit
  (merged to 'next' on 2017-01-18 at dfcb1405de)
 + request-pull: drop old USAGE stuff

 Code clean-up.

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

* sh/grep-tree-obj-tweak-output (2017-01-20) 2 commits
 - grep: use '/' delimiter for paths
 - grep: only add delimiter if there isn't one already

 "git grep", when fed a tree-ish as an input, shows each hit
 prefixed with "<tree-ish>:<path>:<lineno>:".  As <tree-ish> is
 almost always either a commit or a tag that points at a commit, the
 early part of the output "<tree-ish>:<path>" can be used as the
 name of the blob and given to "git show".  When <tree-ish> is a
 tree given in the extended SHA-1 syntax (e.g. "<commit>:", or
 "<commit>:<dir>"), however, this results in a string that does not
 name a blob (e.g. "<commit>::<path>" or "<commit>:<dir>:<path>").
 "git grep" has been taught to be a bit more intelligent about these
 cases and omit a colon (in the former case) or use slash (in the
 latter case) to produce "<commit>:<path>" and
 "<commit>:<dir>/<path>" that can be used as the name of a blob.

 Waiting for the review discussion to settle, followed by a reroll.


* vp/show-ref-verify-head (2017-01-23) 5 commits
 - show-ref: remove dead `if (verify)' check
 - show-ref: detect dangling refs under --verify as well
 - show-ref: move --quiet handling into show_one()
 - show-ref: allow -d to work with --verify
 - show-ref: accept HEAD with --verify

 "git show-ref HEAD" used with "--verify" because the user is not
 interested in seeing refs/remotes/origin/HEAD, and used with
 "--head" because the user does not want HEAD to be filtered out,
 i.e. "git show-ref --head --verify HEAD", did not work as expected.

 Will merge to 'next'.


* bc/use-asciidoctor-opt (2017-01-23) 7 commits
 - Makefile: add a knob to enable the use of Asciidoctor
 - Documentation: move dblatex arguments into variable
 - Documentation: add XSLT to fix DocBook for Texinfo
 - Documentation: sort sources for gitman.texi
 - Documentation: remove unneeded argument in cat-texi.perl
 - Documentation: modernize cat-texi.perl
 - Documentation: fix warning in cat-texi.perl

 Asciidoctor, an alternative reimplementation of AsciiDoc, still
 needs some changes to work with documents meant to be formatted
 with AsciiDoc.  "make USE_ASCIIDOCTOR=YesPlease" to use it out of
 the box to document our pages is getting closer to reality.


* ls/travis-p4-on-macos (2017-01-23) 1 commit
  (merged to 'next' on 2017-01-23 at 2d51987faa)
 + travis-ci: fix Perforce install on macOS

 Update the definition of the MacOSX test environment used by
 TravisCI.

 Will merge to 'master'.


* rs/qsort-s (2017-01-23) 5 commits
 - ref-filter: use QSORT_S in ref_array_sort()
 - string-list: use QSORT_S in string_list_sort()
 - perf: add basic sort performance test
 - add QSORT_S
 - compat: add qsort_s()

 A few codepaths had to rely on a global variable when sorting
 elements of an array because sort(3) API does not allow extra data
 to be passed to the comparison function.  Use qsort_s() when
 natively available, and a fallback implementation of it when not,
 to eliminate the need, which is a prerequisite for making the
 codepath reentrant.

 Will merge to 'next'.

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

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

* jk/coding-guidelines-update (2017-01-17) 1 commit
  (merged to 'next' on 2017-01-23 at 8c57afa288)
 + CodingGuidelines: clarify multi-line brace style

 Developer doc update.

 Will merge to 'master'.


* jk/fsck-connectivity-check-fix (2017-01-17) 6 commits
  (merged to 'next' on 2017-01-23 at e8e9b76b84)
 + fsck: check HAS_OBJ more consistently
 + fsck: do not fallback "git fsck <bogus>" to "git fsck"
 + fsck: tighten error-checks of "git fsck <head>"
 + fsck: prepare dummy objects for --connectivity-check
 + fsck: report trees as dangling
 + t1450: clean up sub-objects in duplicate-entry test

 "git fsck --connectivity-check" was not working at all.

 Will merge to 'master'.


* js/exec-path-coverity-workaround (2017-01-09) 2 commits
  (merged to 'next' on 2017-01-23 at bf5dfbf860)
 + git_exec_path: do not return the result of getenv()
 + git_exec_path: avoid Coverity warning about unfree()d result

 Code cleanup.

 Will merge to 'master'.
 Split out of another topic.


* js/mingw-isatty (2017-01-18) 1 commit
  (merged to 'next' on 2017-01-23 at ae0f80e058)
 + mingw: follow-up to "replace isatty() hack"

 An update to a topic that is already in 'master'.

 Will merge to 'master'.


* js/sequencer-i-countdown-3 (2017-01-17) 38 commits
 - sequencer (rebase -i): write out the final message
 - sequencer (rebase -i): write the progress into files
 - sequencer (rebase -i): show the progress
 - sequencer (rebase -i): suggest --edit-todo upon unknown command
 - sequencer (rebase -i): show only failed cherry-picks' output
 - sequencer (rebase -i): show only failed `git commit`'s output
 - sequencer: use run_command() directly
 - sequencer: update reading author-script
 - sequencer (rebase -i): differentiate between comments and 'noop'
 - sequencer (rebase -i): implement the 'drop' command
 - sequencer (rebase -i): allow rescheduling commands
 - sequencer (rebase -i): respect strategy/strategy_opts settings
 - sequencer (rebase -i): respect the rebase.autostash setting
 - sequencer (rebase -i): run the post-rewrite hook, if needed
 - sequencer (rebase -i): record interrupted commits in rewritten, too
 - sequencer (rebase -i): copy commit notes at end
 - sequencer (rebase -i): set the reflog message consistently
 - sequencer (rebase -i): refactor setting the reflog message
 - sequencer (rebase -i): allow fast-forwarding for edit/reword
 - sequencer (rebase -i): implement the 'reword' command
 - sequencer (rebase -i): leave a patch upon error
 - sequencer (rebase -i): update refs after a successful rebase
 - sequencer (rebase -i): the todo can be empty when continuing
 - sequencer (rebase -i): skip some revert/cherry-pick specific code path
 - sequencer (rebase -i): remove CHERRY_PICK_HEAD when no longer needed
 - sequencer (rebase -i): allow continuing with staged changes
 - sequencer (rebase -i): write an author-script file
 - sequencer (rebase -i): implement the short commands
 - sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
 - sequencer (rebase -i): write the 'done' file
 - sequencer (rebase -i): learn about the 'verbose' mode
 - sequencer (rebase -i): implement the 'exec' command
 - sequencer (rebase -i): implement the 'edit' command
 - sequencer (rebase -i): implement the 'noop' command
 - sequencer: support a new action: 'interactive rebase'
 - sequencer: use a helper to find the commit message
 - sequencer: move "else" keyword onto the same line as preceding brace
 - sequencer: avoid unnecessary curly braces

 The sequencer machinery has been further enhanced so that a later
 set of patches can start using it to reimplement "rebase -i".

 Will merge to 'next'.
 I think I've said everything that needs to be said on this topic.


* jk/clear-delta-base-cache-fix (2017-01-19) 1 commit
  (merged to 'next' on 2017-01-23 at 5f4af2b0a5)
 + clear_delta_base_cache(): don't modify hashmap while iterating

 A crashing bug introduced in v2.11 timeframe has been found (it is
 triggerable only in fast-import) and fixed.

 Will merge to 'master'.


* jk/describe-omit-some-refs (2017-01-19) 6 commits
 - SQUASH???
 - describe: teach describe negative pattern matches
 - describe: teach --match to accept multiple patterns
 - name-rev: add support to exclude refs by pattern match
 - name-rev: extend --refs to accept multiple patterns
 - doc: add documentation for OPT_STRING_LIST

 "git describe" and "git name-rev" have been taught to take more
 than one refname patterns to restrict the set of refs to base their
 naming output on, and also learned to take negative patterns to
 name refs not to be used for naming via their "--exclude" option.

 Will merge to 'next' after making sure SQUASH??? is correctly
 squashed in.


* js/remote-rename-with-half-configured-remote (2017-01-19) 2 commits
  (merged to 'next' on 2017-01-23 at a1b655dbac)
 + remote rename: more carefully determine whether a remote is configured
 + remote rename: demonstrate a bogus "remote exists" bug

 With anticipatory tweaking for remotes defined in ~/.gitconfig
 (e.g. "remote.origin.prune" set to true, even though there may or
 may not actually be "origin" remote defined in a particular Git
 repository), "git remote rename" and other commands misinterpreted
 and behaved as if such a non-existing remote actually existed.

 Will merge to 'master'.


* sb/in-core-index-doc (2017-01-19) 4 commits
  (merged to 'next' on 2017-01-23 at 30224463e8)
 + documentation: retire unfinished documentation
 + cache.h: document add_[file_]to_index
 + cache.h: document remove_index_entry_at
 + cache.h: document index_name_pos

 Documentation and in-code comments updates.

 Will merge to 'master'.


* sb/retire-convert-objects-from-contrib (2017-01-19) 1 commit
  (merged to 'next' on 2017-01-23 at decc1e237d)
 + contrib: remove git-convert-objects

 Remove an ancient tool left in contrib/.

 Will merge to 'master'.


* ep/commit-static-buf-cleanup (2017-01-13) 2 commits
 - builtin/commit.c: switch to xstrfmt(), instead of snprintf()
 - builtin/commit.c: remove the PATH_MAX limitation via dynamic allocation

 Code clean-up.

 Expecting a reroll.
 The tip one would instead be done with strbuf.
 cf. <CA+EOSB=4-TKpi6mr-yVbwRsFrVzE=vo4Y9Qm3VMm7pn=UB1_hQ@mail.gmail.com>


* jk/vreport-sanitize (2017-01-11) 2 commits
  (merged to 'next' on 2017-01-18 at 4bbf370981)
 + vreport: sanitize ASCII control chars
 + Revert "vreportf: avoid intermediate buffer"

 An error message with an ASCII control character like '\r' in it
 can alter the message to hide its early part, which is problematic
 when a remote side gives such an error message that the local side
 will relay with a "remote: " prefix.

 Will merge to 'master'.


* sb/unpack-trees-super-prefix (2017-01-12) 5 commits
 - SQUASH
 - unpack-trees: support super-prefix option
 - t1001: modernize style
 - t1000: modernize style
 - read-tree: use OPT_BOOL instead of OPT_SET_INT

 "git read-tree" and its underlying unpack_trees() machinery learned
 to report problematic paths prefixed with the --super-prefix option.

 Expecting a reroll.
 The first three are in good shape.  The last one needs a better
 explanation and possibly an update to its test.
 cf. <CAGZ79kaHDnVLQr8WLoaD5KKs7EqeW=KbkptF=iHpU5t054Xcdw@mail.gmail.com>


* sb/submodule-doc (2017-01-12) 3 commits
 - submodules: add a background story
 - submodule update documentation: don't repeat ourselves
 - submodule documentation: add options to the subcommand

 Needs review.


* bw/attr (2017-01-23) 27 commits
 - attr: reformat git_attr_set_direction() function
 - attr: push the bare repo check into read_attr()
 - attr: store attribute stack in attr_check structure
 - attr: tighten const correctness with git_attr and match_attr
 - attr: remove maybe-real, maybe-macro from git_attr
 - attr: eliminate global check_all_attr array
 - attr: use hashmap for attribute dictionary
 - attr: change validity check for attribute names to use positive logic
 - attr: pass struct attr_check to collect_some_attrs
 - attr: retire git_check_attrs() API
 - attr: convert git_check_attrs() callers to use the new API
 - attr: convert git_all_attrs() to use "struct attr_check"
 - attr: (re)introduce git_check_attr() and struct attr_check
 - attr: rename function and struct related to checking attributes
 - attr.c: outline the future plans by heavily commenting
 - Documentation/gitattributes.txt: fix a typo
 - attr.c: add push_stack() helper
 - attr: support quoting pathname patterns in C style
 - attr.c: plug small leak in parse_attr_line()
 - attr.c: tighten constness around "git_attr" structure
 - attr.c: simplify macroexpand_one()
 - attr.c: mark where #if DEBUG ends more clearly
 - attr.c: complete a sentence in a comment
 - attr.c: explain the lack of attr-name syntax check in parse_attr()
 - attr.c: update a stale comment on "struct match_attr"
 - attr.c: use strchrnul() to scan for one line
 - commit.c: use strchrnul() to scan for one line

 The gitattributes machinery is being taught to work better in a
 multi-threaded environment.

 Expecting a reroll.


* jk/loose-object-fsck (2017-01-15) 6 commits
  (merged to 'next' on 2017-01-23 at 4302ad090d)
 + fsck: detect trailing garbage in all object types
 + fsck: parse loose object paths directly
 + sha1_file: add read_loose_object() function
 + t1450: test fsck of packed objects
 + sha1_file: fix error message for alternate objects
 + t1450: refactor loose-object removal

 "git fsck" inspects loose objects more carefully now.

 Will merge to 'master'.


* vn/xdiff-func-context (2017-01-15) 1 commit
 - xdiff -W: relax end-of-file function detection

 "git diff -W" has been taught to handle the case where a new
 function is added at the end of the file better.

 Will hold.
 An follow-up change to go back from the line that matches the
 funcline to show comments before the function definition is still
 being discussed.


* mh/ref-remove-empty-directory (2017-01-07) 23 commits
 - files_transaction_commit(): clean up empty directories
 - try_remove_empty_parents(): teach to remove parents of reflogs, too
 - try_remove_empty_parents(): don't trash argument contents
 - try_remove_empty_parents(): rename parameter "name" -> "refname"
 - delete_ref_loose(): inline function
 - delete_ref_loose(): derive loose reference path from lock
 - log_ref_write_1(): inline function
 - log_ref_setup(): manage the name of the reflog file internally
 - log_ref_write_1(): don't depend on logfile argument
 - log_ref_setup(): pass the open file descriptor back to the caller
 - log_ref_setup(): improve robustness against races
 - log_ref_setup(): separate code for create vs non-create
 - log_ref_write(): inline function
 - rename_tmp_log(): improve error reporting
 - rename_tmp_log(): use raceproof_create_file()
 - lock_ref_sha1_basic(): use raceproof_create_file()
 - lock_ref_sha1_basic(): inline constant
 - raceproof_create_file(): new function
 - safe_create_leading_directories(): set errno on SCLD_EXISTS
 - safe_create_leading_directories_const(): preserve errno
 - t5505: use "for-each-ref" to test for the non-existence of references
 - refname_is_safe(): correct docstring
 - files_rename_ref(): tidy up whitespace

 Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
 once there no longer is any other branch whose name begins with
 "foo/", but we didn't do so so far.  Now we do.

 Expecting a reroll.
 cf. <5051c78e-51f9-becd-e1a6-9c0b781d6912@alum.mit.edu>


* ls/filter-process-delayed (2017-01-08) 1 commit
 . convert: add "status=delayed" to filter process protocol

 Ejected, as does not build when merged to 'pu'.


* nd/worktree-move (2017-01-09) 6 commits
 - worktree remove: new command
 - worktree move: refuse to move worktrees with submodules
 - worktree move: accept destination as directory
 - worktree move: new command
 - worktree.c: add update_worktree_location()
 - worktree.c: add validate_worktree()

 "git worktree" learned move and remove subcommands.

 Needs review.


* nd/log-graph-configurable-colors (2017-01-19) 4 commits
 - SQUASH???
 - log --graph: customize the graph lines with config log.graphColors
 - color.c: trim leading spaces in color_parse_mem()
 - color.c: fix color_parse_mem() with value_len == 0

 Some people feel the default set of colors used by "git log --graph"
 rather limiting.  A mechanism to customize the set of colors has
 been introduced.

 Will merge to 'next' after making sure SQUASH??? is correctly
 squashed in.


* cc/split-index-config (2016-12-26) 21 commits
 - Documentation/git-update-index: explain splitIndex.*
 - Documentation/config: add splitIndex.sharedIndexExpire
 - read-cache: use freshen_shared_index() in read_index_from()
 - read-cache: refactor read_index_from()
 - t1700: test shared index file expiration
 - read-cache: unlink old sharedindex files
 - config: add git_config_get_expiry() from gc.c
 - read-cache: touch shared index files when used
 - sha1_file: make check_and_freshen_file() non static
 - Documentation/config: add splitIndex.maxPercentChange
 - t1700: add tests for splitIndex.maxPercentChange
 - read-cache: regenerate shared index if necessary
 - config: add git_config_get_max_percent_split_change()
 - Documentation/git-update-index: talk about core.splitIndex config var
 - Documentation/config: add information for core.splitIndex
 - t1700: add tests for core.splitIndex
 - update-index: warn in case of split-index incoherency
 - read-cache: add and then use tweak_split_index()
 - split-index: add {add,remove}_split_index() functions
 - config: add git_config_get_split_index()
 - config: mark an error message up for translation

 The experimental "split index" feature has gained a few
 configuration variables to make it easier to use.

 Waiting for review comments to be addressed.
 cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
 cf. <a1a44640-ff6c-2294-72ac-46322eff8505@ramsayjones.plus.com>


* bw/push-submodule-only (2016-12-20) 3 commits
  (merged to 'next' on 2017-01-23 at d6cd1c60ae)
 + push: add option to push only submodules
 + submodules: add RECURSE_SUBMODULES_ONLY value
 + transport: reformat flag #defines to be more readable

 "git submodule push" learned "--recurse-submodules=only option to
 push submodules out without pushing the top-level superproject.

 Will merge to 'master'.


* ls/p4-path-encoding (2016-12-18) 1 commit
 - git-p4: fix git-p4.pathEncoding for removed files

 When "git p4" imports changelist that removes paths, it failed to
 convert pathnames when the p4 used encoding different from the one
 used on the Git side.  This has been corrected.

 Will be rerolled.
 cf. <7E1C7387-4F37-423F-803D-3B5690B49D40@gmail.com>


* js/difftool-builtin (2017-01-19) 3 commits
  (merged to 'next' on 2017-01-23 at 6f4810dbd9)
 + difftool: retire the scripted version
 + difftool: implement the functionality in the builtin
 + difftool: add a skeleton for the upcoming builtin

 Rewrite a scripted porcelain "git difftool" in C.

 Will merge to 'master'.


* sb/push-make-submodule-check-the-default (2016-11-29) 2 commits
  (merged to 'next' on 2016-12-12 at 1863e05af5)
 + push: change submodule default to check when submodules exist
 + submodule add: extend force flag to add existing repos

 Turn the default of "push.recurseSubmodules" to "check" when
 submodules seem to be in use.

 Will cook in 'next'.


* kn/ref-filter-branch-list (2017-01-10) 21 commits
 - SQUASH???
 - branch: implement '--format' option
 - branch: use ref-filter printing APIs
 - branch, tag: use porcelain output
 - ref-filter: allow porcelain to translate messages in the output
 - ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
 - ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
 - ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
 - ref-filter: rename the 'strip' option to 'lstrip'
 - ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
 - ref-filter: introduce refname_atom_parser()
 - ref-filter: introduce refname_atom_parser_internal()
 - ref-filter: make "%(symref)" atom work with the ':short' modifier
 - ref-filter: add support for %(upstream:track,nobracket)
 - ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
 - ref-filter: introduce format_ref_array_item()
 - ref-filter: move get_head_description() from branch.c
 - ref-filter: modify "%(objectname:short)" to take length
 - ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
 - ref-filter: include reference to 'used_atom' within 'atom_value'
 - ref-filter: implement %(if), %(then), and %(else) atoms

 The code to list branches in "git branch" has been consolidated
 with the more generic ref-filter API.

 I think this is almost ready.  Will wait for a few days, squash
 fixes in if needed and merge to 'next'.


* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
  (merged to 'next' on 2016-12-05 at 0c77e39cd5)
 + setup_git_env: avoid blind fall-back to ".git"

 Originally merged to 'next' on 2016-10-26

 This is the endgame of the topic to avoid blindly falling back to
 ".git" when the setup sequence said we are _not_ in Git repository.
 A corner case that happens to work right now may be broken by a
 call to die("BUG").

 Will cook in 'next'.


* pb/bisect (2016-10-18) 27 commits
 - bisect--helper: remove the dequote in bisect_start()
 - bisect--helper: retire `--bisect-auto-next` subcommand
 - bisect--helper: retire `--bisect-autostart` subcommand
 - bisect--helper: retire `--bisect-write` subcommand
 - bisect--helper: `bisect_replay` shell function in C
 - bisect--helper: `bisect_log` shell function in C
 - bisect--helper: retire `--write-terms` subcommand
 - bisect--helper: retire `--check-expected-revs` subcommand
 - bisect--helper: `bisect_state` & `bisect_head` shell function in C
 - bisect--helper: `bisect_autostart` shell function in C
 - bisect--helper: retire `--next-all` subcommand
 - bisect--helper: retire `--bisect-clean-state` subcommand
 - bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
 - t6030: no cleanup with bad merge base
 - bisect--helper: `bisect_start` shell function partially in C
 - bisect--helper: `get_terms` & `bisect_terms` shell function in C
 - bisect--helper: `bisect_next_check` & bisect_voc shell function in C
 - bisect--helper: `check_and_set_terms` shell function in C
 - bisect--helper: `bisect_write` shell function in C
 - bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
 - bisect--helper: `bisect_reset` shell function in C
 - wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
 - t6030: explicitly test for bisection cleanup
 - bisect--helper: `bisect_clean_state` shell function in C
 - bisect--helper: `write_terms` shell function in C
 - bisect: rewrite `check_term_format` shell function in C
 - bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

 Move more parts of "git bisect" to C.

 Expecting a reroll.
 cf. <CAFZEwPPXPPHi8KiEGS9ggzNHDCGhuqMgH9Z8-Pf9GLshg8+LPA@mail.gmail.com>
 cf. <CAFZEwPM9RSTGN54dzaw9gO9iZmsYjJ_d1SjUD4EzSDDbmh-XuA@mail.gmail.com>


* st/verify-tag (2017-01-18) 6 commits
  (merged to 'next' on 2017-01-23 at 2810959427)
 + t/t7004-tag: Add --format specifier tests
 + t/t7030-verify-tag: Add --format specifier tests
 + builtin/tag: add --format argument for tag -v
 + builtin/verify-tag: add --format to verify-tag
 + ref-filter: add function to print single ref_array_item
 + gpg-interface, tag: add GPG_VERIFY_OMIT_STATUS flag

 "git tag" and "git verify-tag" learned to put GPG verification
 status in their "--format=<placeholders>" output format.

 Will merge to 'master'.


* jc/merge-drop-old-syntax (2015-04-29) 1 commit
  (merged to 'next' on 2016-12-05 at 041946dae0)
 + merge: drop 'git merge <message> HEAD <commit>' syntax

 Originally merged to 'next' on 2016-10-11

 Stop supporting "git merge <message> HEAD <commit>" syntax that has
 been deprecated since October 2007, and issues a deprecation
 warning message since v2.5.0.

 Will cook in 'next'.

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

* jc/bundle (2016-03-03) 6 commits
 . index-pack: --clone-bundle option
 . Merge branch 'jc/index-pack' into jc/bundle
 . bundle v3: the beginning
 . bundle: keep a copy of bundle file name in the in-core bundle header
 . bundle: plug resource leak
 . bundle doc: 'verify' is not about verifying the bundle

 The beginning of "split bundle", which could be one of the
 ingredients to allow "git clone" traffic off of the core server
 network to CDN.

 While I think it would make it easier for people to experiment and
 build on if the topic is merged to 'next', I am at the same time a
 bit reluctant to merge an unproven new topic that introduces a new
 file format, which we may end up having to support til the end of
 time.  It is likely that to support a "prime clone from CDN", it
 would need a lot more than just "these are the heads and the pack
 data is over there", so this may not be sufficient.


* jk/nofollow-attr-ignore (2016-11-02) 5 commits
 . exclude: do not respect symlinks for in-tree .gitignore
 . attr: do not respect symlinks for in-tree .gitattributes
 . exclude: convert "check_index" into a flags field
 . attr: convert "macro_ok" into a flags field
 . add open_nofollow() helper

 As we do not follow symbolic links when reading control files like
 .gitignore and .gitattributes from the index, match the behaviour
 and not follow symbolic links when reading them from the working
 tree.  This also tightens security a bit by not leaking contents of
 an unrelated file in the error messages when it is pointed at by
 one of these files that is a symbolic link.

 Perhaps we want to cover .gitmodules too with the same mechanism?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-24  0:18 What's cooking in git.git (Jan 2017, #04; Mon, 23) Junio C Hamano
@ 2017-01-24 10:04 ` Lars Schneider
  2017-01-24 13:27   ` Jeff King
  2017-01-25 18:38 ` Stefan Beller
  1 sibling, 1 reply; 15+ messages in thread
From: Lars Schneider @ 2017-01-24 10:04 UTC (permalink / raw)
  To: Junio C Hamano, Jeff King; +Cc: git


> On 24 Jan 2017, at 01:18, Junio C Hamano <gitster@pobox.com> wrote:
> 
> * jk/fsck-connectivity-check-fix (2017-01-17) 6 commits
>  (merged to 'next' on 2017-01-23 at e8e9b76b84)
> + fsck: check HAS_OBJ more consistently
> + fsck: do not fallback "git fsck <bogus>" to "git fsck"
> + fsck: tighten error-checks of "git fsck <head>"
> + fsck: prepare dummy objects for --connectivity-check
> + fsck: report trees as dangling
> + t1450: clean up sub-objects in duplicate-entry test
> 
> "git fsck --connectivity-check" was not working at all.
> 
> Will merge to 'master'.

"fsck: prepare dummy objects for --connectivity-check" seems to
make t1450-fsck.sh fail on macOS with TravisCI:

Initialized empty Git repository in /Users/travis/build/git/git/t/trash directory.t1450-fsck/connectivity-only/.git/
[master (root-commit) 86520b7] empty
 Author: A U Thor <author@example.com>
 2 files changed, 1 insertion(+)
 create mode 100644 empty
 create mode 100644 empty.t
override r--r--r--  travis/staff for .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391? (y/n [n]) not overwritten
dangling blob c21c9352f7526e9576892a6631e0e8cf1fccd34d
test_must_fail: command succeeded: git fsck --strict
not ok 58 - fsck --connectivity-only

More test output: https://travis-ci.org/git/git/jobs/194663620

For some reason I am not able to replicate that behavior on my local
macOS machine. I found the commit using bisect on TravisCI:
https://api.travis-ci.org/jobs/194746454/log.txt?deansi=true

Any idea what might be wrong?

- Lars

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-24 10:04 ` Lars Schneider
@ 2017-01-24 13:27   ` Jeff King
  2017-01-24 14:43     ` Lars Schneider
  2017-01-25 17:01     ` Johannes Schindelin
  0 siblings, 2 replies; 15+ messages in thread
From: Jeff King @ 2017-01-24 13:27 UTC (permalink / raw)
  To: Lars Schneider; +Cc: Junio C Hamano, git

On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:

> "fsck: prepare dummy objects for --connectivity-check" seems to
> make t1450-fsck.sh fail on macOS with TravisCI:
> 
> Initialized empty Git repository in /Users/travis/build/git/git/t/trash directory.t1450-fsck/connectivity-only/.git/
> [master (root-commit) 86520b7] empty
>  Author: A U Thor <author@example.com>
>  2 files changed, 1 insertion(+)
>  create mode 100644 empty
>  create mode 100644 empty.t
> override r--r--r--  travis/staff for .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391? (y/n [n]) not overwritten
> dangling blob c21c9352f7526e9576892a6631e0e8cf1fccd34d

Looks like "mv" prompts and then fails to move the file (so we get the
dangling blob for the source blob, and fsck doesn't report failure because
we didn't actually corrupt the destination blob).

If I'm understanding the behavior correctly, this violates POSIX, which
says:

  1. If the destination path exists, the −f option is not specified, and
     either of the following conditions is true:

     a. The permissions of the destination path do not permit writing
     and the standard input is a terminal.

     b. The −i option is specified.

     the mv utility shall write a prompt to standard error and read a
     line from standard input. If the response is not affirmative,
     mv shall do nothing more with the current source_file and go on
     to any remaining source_files.

Our stdin isn't a terminal, and we do not specify "-i", so I think it
shouldn't prompt.  It also exits with code 0 after failing to move,
which is another surprise.

Here's a patch (tested by me that it works on Linux, but I don't know
for sure that it fixes the Travis problem).

-- >8 --
Subject: [PATCH] t1450: use "mv -f" within loose object directory

The loose objects are created with mode 0444. That doesn't
prevent them being overwritten by rename(), but some
versions of "mv" will be extra careful and prompt the user,
even without "-i".

Reportedly macOS does this, at least in the Travis builds.
The prompt reads from /dev/null, defaulting to "no", and the
object isn't moved. Then to make matters even more
interesting, it still returns "0" and the rest of the test
proceeds, but with a broken setup.

We can work around it by using "mv -f" to override the
prompt. This should work as it's already used in t5504 for
the same purpose.

Signed-off-by: Jeff King <peff@peff.net>
---
 t/t1450-fsck.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index efaf41b68..33a51c9a6 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -536,7 +536,7 @@ test_expect_success 'fsck --connectivity-only' '
 		# free to examine the type if it chooses.
 		empty=.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 &&
 		blob=$(echo unrelated | git hash-object -w --stdin) &&
-		mv $(sha1_file $blob) $empty &&
+		mv -f $(sha1_file $blob) $empty &&
 
 		test_must_fail git fsck --strict &&
 		git fsck --strict --connectivity-only &&
-- 
2.11.0.840.gd37c5973a


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-24 13:27   ` Jeff King
@ 2017-01-24 14:43     ` Lars Schneider
  2017-01-25 17:01     ` Johannes Schindelin
  1 sibling, 0 replies; 15+ messages in thread
From: Lars Schneider @ 2017-01-24 14:43 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git


> On 24 Jan 2017, at 14:27, Jeff King <peff@peff.net> wrote:
> 
> On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
> 
>> "fsck: prepare dummy objects for --connectivity-check" seems to
>> make t1450-fsck.sh fail on macOS with TravisCI:
>> 
>> Initialized empty Git repository in /Users/travis/build/git/git/t/trash directory.t1450-fsck/connectivity-only/.git/
>> [master (root-commit) 86520b7] empty
>> Author: A U Thor <author@example.com>
>> 2 files changed, 1 insertion(+)
>> create mode 100644 empty
>> create mode 100644 empty.t
>> override r--r--r--  travis/staff for .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391? (y/n [n]) not overwritten
>> dangling blob c21c9352f7526e9576892a6631e0e8cf1fccd34d
> 
> Looks like "mv" prompts and then fails to move the file (so we get the
> dangling blob for the source blob, and fsck doesn't report failure because
> we didn't actually corrupt the destination blob).
> 
> If I'm understanding the behavior correctly, this violates POSIX, which
> says:
> 
>  1. If the destination path exists, the −f option is not specified, and
>     either of the following conditions is true:
> 
>     a. The permissions of the destination path do not permit writing
>     and the standard input is a terminal.
> 
>     b. The −i option is specified.
> 
>     the mv utility shall write a prompt to standard error and read a
>     line from standard input. If the response is not affirmative,
>     mv shall do nothing more with the current source_file and go on
>     to any remaining source_files.
> 
> Our stdin isn't a terminal, and we do not specify "-i", so I think it
> shouldn't prompt.  It also exits with code 0 after failing to move,
> which is another surprise.
> 
> Here's a patch (tested by me that it works on Linux, but I don't know
> for sure that it fixes the Travis problem).
> 
> -- >8 --
> Subject: [PATCH] t1450: use "mv -f" within loose object directory
> 
> The loose objects are created with mode 0444. That doesn't
> prevent them being overwritten by rename(), but some
> versions of "mv" will be extra careful and prompt the user,
> even without "-i".
> 
> Reportedly macOS does this, at least in the Travis builds.
> The prompt reads from /dev/null, defaulting to "no", and the
> object isn't moved. Then to make matters even more
> interesting, it still returns "0" and the rest of the test
> proceeds, but with a broken setup.
> 
> We can work around it by using "mv -f" to override the
> prompt. This should work as it's already used in t5504 for
> the same purpose.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> t/t1450-fsck.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
> index efaf41b68..33a51c9a6 100755
> --- a/t/t1450-fsck.sh
> +++ b/t/t1450-fsck.sh
> @@ -536,7 +536,7 @@ test_expect_success 'fsck --connectivity-only' '
> 		# free to examine the type if it chooses.
> 		empty=.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 &&
> 		blob=$(echo unrelated | git hash-object -w --stdin) &&
> -		mv $(sha1_file $blob) $empty &&
> +		mv -f $(sha1_file $blob) $empty &&
> 
> 		test_must_fail git fsck --strict &&
> 		git fsck --strict --connectivity-only &&
> -- 
> 2.11.0.840.gd37c5973a

Ack. This patch fixes the issue:
https://travis-ci.org/larsxschneider/git/builds/194819605

Thanks,
Lars

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-24 13:27   ` Jeff King
  2017-01-24 14:43     ` Lars Schneider
@ 2017-01-25 17:01     ` Johannes Schindelin
  2017-01-25 17:39       ` Jeff King
  1 sibling, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2017-01-25 17:01 UTC (permalink / raw)
  To: Jeff King; +Cc: Lars Schneider, Junio C Hamano, git

Hi Peff,

On Tue, 24 Jan 2017, Jeff King wrote:

> On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
> 
> > "fsck: prepare dummy objects for --connectivity-check" seems to
> > make t1450-fsck.sh fail on macOS with TravisCI:
> >
> > Initialized empty Git repository in /Users/travis/build/git/git/t/trash directory.t1450-fsck/connectivity-only/.git/
> > [master (root-commit) 86520b7] empty
> >  Author: A U Thor <author@example.com>
> >  2 files changed, 1 insertion(+)
> >  create mode 100644 empty
> >  create mode 100644 empty.t
> > override r--r--r--  travis/staff for .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391? (y/n [n]) not overwritten
> > dangling blob c21c9352f7526e9576892a6631e0e8cf1fccd34d
> 
> Looks like "mv" prompts and then fails to move the file (so we get the
> dangling blob for the source blob, and fsck doesn't report failure
> because we didn't actually corrupt the destination blob).

IIRC I had similar problems years ago, on a machine where the
administrator defined mandatory aliases, including mv="mv -i".

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-25 17:01     ` Johannes Schindelin
@ 2017-01-25 17:39       ` Jeff King
  2017-01-25 18:16         ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: Jeff King @ 2017-01-25 17:39 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Lars Schneider, Junio C Hamano, git

On Wed, Jan 25, 2017 at 06:01:11PM +0100, Johannes Schindelin wrote:

> > Looks like "mv" prompts and then fails to move the file (so we get the
> > dangling blob for the source blob, and fsck doesn't report failure
> > because we didn't actually corrupt the destination blob).
> 
> IIRC I had similar problems years ago, on a machine where the
> administrator defined mandatory aliases, including mv="mv -i".

Yeah, that was my first thought, too. But this should be a
non-interactive shell, which would generally avoid loading rc files. I
think there are some exceptions, though (e.g., setting ENV or BASH_ENV).
Loading aliases like "mv -i" for non-interactive shells seems somewhat
insane to me. But whatever the cause, I think the workaround I posted is
easy enough to do.

-Peff

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-25 17:39       ` Jeff King
@ 2017-01-25 18:16         ` Junio C Hamano
  2017-01-25 18:39           ` Jeff King
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2017-01-25 18:16 UTC (permalink / raw)
  To: Jeff King; +Cc: Johannes Schindelin, Lars Schneider, git

Jeff King <peff@peff.net> writes:

> On Wed, Jan 25, 2017 at 06:01:11PM +0100, Johannes Schindelin wrote:
>
>> > Looks like "mv" prompts and then fails to move the file (so we get the
>> > dangling blob for the source blob, and fsck doesn't report failure
>> > because we didn't actually corrupt the destination blob).
>> 
>> IIRC I had similar problems years ago, on a machine where the
>> administrator defined mandatory aliases, including mv="mv -i".
>
> Yeah, that was my first thought, too. But this should be a
> non-interactive shell, which would generally avoid loading rc files. I
> think there are some exceptions, though (e.g., setting ENV or BASH_ENV).
> Loading aliases like "mv -i" for non-interactive shells seems somewhat
> insane to me. 

It does to me, too.

> But whatever the cause, I think the workaround I posted is
> easy enough to do.

Or spelling it explicitly as "/bin/mv" (forgetting systems that does
not have it in /bin but as /usr/bin/mv) would also defeat alias if
that were the cause.

One downside of working it around like your patch does, or spelling
it out as "/bin/mv", is that we'd need to worry about all the uses
of "mv" in our scripts.  If this were _only_ happening in the Travis
environment, I'd prefer to see why it happens only there and fix that
instead.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-24  0:18 What's cooking in git.git (Jan 2017, #04; Mon, 23) Junio C Hamano
  2017-01-24 10:04 ` Lars Schneider
@ 2017-01-25 18:38 ` Stefan Beller
  2017-01-25 20:35   ` Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Beller @ 2017-01-25 18:38 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Mon, Jan 23, 2017 at 4:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> * sb/unpack-trees-super-prefix (2017-01-12) 5 commits
>  - SQUASH
>  - unpack-trees: support super-prefix option
>  - t1001: modernize style
>  - t1000: modernize style
>  - read-tree: use OPT_BOOL instead of OPT_SET_INT
>
>  "git read-tree" and its underlying unpack_trees() machinery learned
>  to report problematic paths prefixed with the --super-prefix option.
>
>  Expecting a reroll.
>  The first three are in good shape.  The last one needs a better
>  explanation and possibly an update to its test.
>  cf. <CAGZ79kaHDnVLQr8WLoaD5KKs7EqeW=KbkptF=iHpU5t054Xcdw@mail.gmail.com>
>

Please see
https://public-inbox.org/git/20170118010520.8804-1-sbeller@google.com/


>
> * sb/submodule-doc (2017-01-12) 3 commits
>  - submodules: add a background story
>  - submodule update documentation: don't repeat ourselves
>  - submodule documentation: add options to the subcommand
>
>  Needs review.

The first 2 commit are asking for the standard review, whereas the last patch
(submodules: add a background story), needs more of a design review/opinion
if such a patch is a good idea actually.

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-25 18:16         ` Junio C Hamano
@ 2017-01-25 18:39           ` Jeff King
  2017-01-25 22:51             ` Junio C Hamano
  0 siblings, 1 reply; 15+ messages in thread
From: Jeff King @ 2017-01-25 18:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, Lars Schneider, git

On Wed, Jan 25, 2017 at 10:16:40AM -0800, Junio C Hamano wrote:

> > But whatever the cause, I think the workaround I posted is
> > easy enough to do.
> 
> Or spelling it explicitly as "/bin/mv" (forgetting systems that does
> not have it in /bin but as /usr/bin/mv) would also defeat alias if
> that were the cause.

Yes, but I think it's less tricky and unportable to write "mv -f" than
"/bin/mv". So even if it _is_ a funny alias thing, I think my patch is
the right fix.

> One downside of working it around like your patch does, or spelling
> it out as "/bin/mv", is that we'd need to worry about all the uses
> of "mv" in our scripts.  If this were _only_ happening in the Travis
> environment, I'd prefer to see why it happens only there and fix that
> instead.

I would be curious to know whether it is a funny thing in the Travis
environment, or if some version of macOS "mv" really is that braindead
(and it is just the case that Travis has that version and Lars's
computer doesn't). I just didn't want to waste anybody's time digging
into it if it won't affect our patch.

I guess the way to dig would be to add a test that looks at the output
of "type mv" or something, push it to a Travis-hooked branch, and then
wait for the output

-Peff

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-25 18:38 ` Stefan Beller
@ 2017-01-25 20:35   ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2017-01-25 20:35 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git

Stefan Beller <sbeller@google.com> writes:

> On Mon, Jan 23, 2017 at 4:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> * sb/unpack-trees-super-prefix (2017-01-12) 5 commits
>>  - SQUASH
>>  - unpack-trees: support super-prefix option
>>  - t1001: modernize style
>>  - t1000: modernize style
>>  - read-tree: use OPT_BOOL instead of OPT_SET_INT
>>
>>  "git read-tree" and its underlying unpack_trees() machinery learned
>>  to report problematic paths prefixed with the --super-prefix option.
>>
>>  Expecting a reroll.
>>  The first three are in good shape.  The last one needs a better
>>  explanation and possibly an update to its test.
>>  cf. <CAGZ79kaHDnVLQr8WLoaD5KKs7EqeW=KbkptF=iHpU5t054Xcdw@mail.gmail.com>
>>
>
> Please see
> https://public-inbox.org/git/20170118010520.8804-1-sbeller@google.com/

Thanks, applied.  Let's move this forward.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-25 18:39           ` Jeff King
@ 2017-01-25 22:51             ` Junio C Hamano
  2017-01-26  9:14               ` Lars Schneider
  0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2017-01-25 22:51 UTC (permalink / raw)
  To: Jeff King; +Cc: Johannes Schindelin, Lars Schneider, git

Jeff King <peff@peff.net> writes:

> I guess the way to dig would be to add a test that looks at the output
> of "type mv" or something, push it to a Travis-hooked branch, and then
> wait for the output

Sounds tempting ;-)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-25 22:51             ` Junio C Hamano
@ 2017-01-26  9:14               ` Lars Schneider
  2017-01-26  9:48                 ` Lars Schneider
  2017-01-26 18:05                 ` Junio C Hamano
  0 siblings, 2 replies; 15+ messages in thread
From: Lars Schneider @ 2017-01-26  9:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, git


> On 25 Jan 2017, at 23:51, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Jeff King <peff@peff.net> writes:
> 
>> I guess the way to dig would be to add a test that looks at the output
>> of "type mv" or something, push it to a Travis-hooked branch, and then
>> wait for the output
> 
> Sounds tempting ;-)

Well, I tried that:

mv is /bin/mv

... and "/bin/mv" is exactly the version that I have on my machine.

The difference between Travis and my machine is that I changed the 
default shell to ZSH with a few plugins [1]. If I run the test with 
plain BASH on my Mac then I can reproduce the test failure. Therefore,
we might want to adjust the commit message if anyone else can reproduce
the problem on a Mac. 

I can even reproduce the failure if I run the test with plain ZSH. 
However, I can't find a plugin that defines an alias for "mv". Puzzled...

- Lars

[1] https://github.com/robbyrussell/oh-my-zsh

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-26  9:14               ` Lars Schneider
@ 2017-01-26  9:48                 ` Lars Schneider
  2017-01-26 14:26                   ` Jeff King
  2017-01-26 18:05                 ` Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Lars Schneider @ 2017-01-26  9:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, git


> On 26 Jan 2017, at 10:14, Lars Schneider <larsxschneider@gmail.com> wrote:
> 
> 
>> On 25 Jan 2017, at 23:51, Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> Jeff King <peff@peff.net> writes:
>> 
>>> I guess the way to dig would be to add a test that looks at the output
>>> of "type mv" or something, push it to a Travis-hooked branch, and then
>>> wait for the output
>> 
>> Sounds tempting ;-)
> 
> Well, I tried that:
> 
> mv is /bin/mv
> 
> ... and "/bin/mv" is exactly the version that I have on my machine.
> 
> The difference between Travis and my machine is that I changed the 
> default shell to ZSH with a few plugins [1]. If I run the test with 
> plain BASH on my Mac then I can reproduce the test failure. Therefore,
> we might want to adjust the commit message if anyone else can reproduce
> the problem on a Mac. 
> 
> I can even reproduce the failure if I run the test with plain ZSH. 
> However, I can't find a plugin that defines an alias for "mv". Puzzled...
> 
> - Lars
> 
> [1] https://github.com/robbyrussell/oh-my-zsh

Oh. I must have made a mistake on my very first test run. I can reproduce
the failure with ZSH and my plugins... looks like it's a Mac OS problem
and no TravisCI only problem after all. 

Sorry for the noise/confusion,
Lars

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-26  9:48                 ` Lars Schneider
@ 2017-01-26 14:26                   ` Jeff King
  0 siblings, 0 replies; 15+ messages in thread
From: Jeff King @ 2017-01-26 14:26 UTC (permalink / raw)
  To: Lars Schneider; +Cc: Junio C Hamano, Johannes Schindelin, git

On Thu, Jan 26, 2017 at 10:48:30AM +0100, Lars Schneider wrote:

> Oh. I must have made a mistake on my very first test run. I can reproduce
> the failure with ZSH and my plugins... looks like it's a Mac OS problem
> and no TravisCI only problem after all.

Thanks for digging into it. If it's really /bin/mv that causes the
problem, then I doubly think the "mv -f" patch is the right fix.

-Peff

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
  2017-01-26  9:14               ` Lars Schneider
  2017-01-26  9:48                 ` Lars Schneider
@ 2017-01-26 18:05                 ` Junio C Hamano
  1 sibling, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2017-01-26 18:05 UTC (permalink / raw)
  To: Lars Schneider; +Cc: Jeff King, Johannes Schindelin, git

Lars Schneider <larsxschneider@gmail.com> writes:

> The difference between Travis and my machine is that I changed the 
> default shell to ZSH with a few plugins [1]. If I run the test with 
> plain BASH on my Mac then I can reproduce the test failure. Therefore,
> we might want to adjust the commit message if anyone else can reproduce
> the problem on a Mac. 

With "Reportedly macOS does this, at least in the Travis builds.",
even with the result from you in your follow-up message to the
message I am responding to, I think what Peff wrote in the log
message is good enough.

Thanks for digging, and thanks Peff for coming up the workaround.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2017-01-26 18:07 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-24  0:18 What's cooking in git.git (Jan 2017, #04; Mon, 23) Junio C Hamano
2017-01-24 10:04 ` Lars Schneider
2017-01-24 13:27   ` Jeff King
2017-01-24 14:43     ` Lars Schneider
2017-01-25 17:01     ` Johannes Schindelin
2017-01-25 17:39       ` Jeff King
2017-01-25 18:16         ` Junio C Hamano
2017-01-25 18:39           ` Jeff King
2017-01-25 22:51             ` Junio C Hamano
2017-01-26  9:14               ` Lars Schneider
2017-01-26  9:48                 ` Lars Schneider
2017-01-26 14:26                   ` Jeff King
2017-01-26 18:05                 ` Junio C Hamano
2017-01-25 18:38 ` Stefan Beller
2017-01-25 20:35   ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.