* What's cooking in git.git (Feb 2017, #07; Thu, 23)
From: Junio C Hamano @ 2017-02-23 22:13 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
--------------------------------------------------
[New Topics]
* js/curl-empty-auth-set-by-default (2017-02-22) 1 commit
- http(s): automatically try NTLM authentication first
Flip "http.emptyAuth" on by default to help OOB experience for
users of HTTP Negotiate authentication scheme.
Under discussion.
cf. <20170222233419.q3fxqmrscosumbjm@genre.crustytoothpaste.net>
* bc/blame-doc-fix (2017-02-22) 1 commit
(merged to 'next' on 2017-02-22 at 81c0ff2283)
+ Documentation: use brackets for optional arguments
Doc update.
Will merge to 'master'.
* bc/worktree-doc-fix-detached (2017-02-22) 1 commit
(merged to 'next' on 2017-02-22 at 8257025363)
+ Documentation: correctly spell git worktree --detach
Doc update.
Will merge to 'master'.
* rt/align-add-i-help-text (2017-02-22) 1 commit
(merged to 'next' on 2017-02-22 at a8573afb9a)
+ git add -i: replace \t with blanks in the help message
Doc update.
Will merge to 'master'.
* jh/send-email-one-cc (2017-02-23) 1 commit
- send-email: only allow one address per body tag
"Cc:" on the trailer part does not have to conform to RFC strictly,
unlike in the e-mail header. "git send-email" has been updated to
ignore anything after '>' when picking addresses, to allow non-address
cruft like " # stable 4.4" after the address.
Will merge to and then cook in 'next'.
* jk/http-auth (2017-02-23) 1 commit
- http: restrict auth methods to what the server advertises
Reduce authentication round-trip over HTTP when the server supports
just a single authentication method.
Will merge to and then cook in 'next'.
There is a follow-up that would supersede js/curl-empty-auth-set-by-default
topic; as it expected to be refined further, it is not queued here yet.
* jk/ident-empty (2017-02-23) 4 commits
- ident: do not ignore empty config name/email
- ident: reject all-crud ident name
- ident: handle NULL email when complaining of empty name
- ident: mark error messages for translation
user.email that consists of only cruft chars should have
consistently errored out, but didn't.
Will merge to and then cook in 'next'.
* jt/upload-pack-error-report (2017-02-23) 1 commit
- upload-pack: report "not our ref" to client
"git upload-pack", which is a counter-part of "git fetch", did not
report a request for a ref that was not advertised as invalid.
This is generally not a problem (because "git fetch" will stop
before making such a request), but is the right thing to do.
Will merge to and then cook in 'next'.
--------------------------------------------------
[Stalled]
* nd/worktree-move (2017-01-27) 7 commits
. fixup! worktree move: new command
. 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.
Tentatively ejected as it seems to break 'pu' when merged.
* 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.
Expecting a reroll.
cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
cf. <a1a44640-ff6c-2294-72ac-46322eff8505@ramsayjones.plus.com>
cf. <CAP8UFD3_1EN=0EsD12Cew1MuW8yhtPAZw0M_g3wmvKFk-uGXxw@mail.gmail.com>
cf. <CAP8UFD1wmbR_rHyqn0q=0hw6-hHYFTzr=3yxS2XS9qTdY1kWFA@mail.gmail.com>
cf. <xmqqbmunq6mg.fsf@gitster.mtv.corp.google.com>
cf. <CAP8UFD0bgxVrc=RGHs1GrZ_5PF4cdfhqXLMiCSJTNw9axrr=_w@mail.gmail.com>
* pb/bisect (2017-02-18) 28 commits
- fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- 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>
cf. <CAFZEwPNUXcNY9Qdz=_B7q2kQuaecPzJtTMGdv8YMUPEz2vnp8A@mail.gmail.com>
* 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'.
* 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.
Expecting a reroll? Is this good enough with known limitations?
* 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/tempfile-ferror-fclose-confusion (2017-02-17) 1 commit
(merged to 'next' on 2017-02-21 at 479ba0131f)
+ tempfile: set errno to a known value before calling ferror()
A caller of tempfile API that uses stdio interface to write to
files may ignore errors while writing, which is detected when
tempfile is closed (with a call to ferror()). By that time, the
original errno that may have told us what went wrong is likely to
be long gone and was overwritten by an irrelevant value.
close_tempfile() now resets errno to EIO to make errno at least
predictable.
Will cook in 'next'.
* ah/doc-ls-files-quotepath (2017-02-22) 1 commit
- Documentation: clarify core.quotePath and update git-ls-files doc
Documentation for "git ls-files" did not refer to core.quotePath
Looked good, but another reroll is still incoming?
cf. <3c801e54-28c7-52d0-6915-ee7aaf1d89c9@gmail.com>
* dr/doc-check-ref-format-normalize (2017-02-21) 1 commit
(merged to 'next' on 2017-02-21 at 5e88b7a93d)
+ git-check-ref-format: clarify documentation for --normalize
Doc update.
Will merge to 'master'.
* gp/document-dotfiles-in-templates-are-not-copied (2017-02-17) 1 commit
(merged to 'next' on 2017-02-21 at bbfa2bb7d4)
+ init: document dotfiles exclusion on template copy
Doc update.
Will merge to 'master'.
* jc/config-case-cmdline (2017-02-21) 3 commits
(merged to 'next' on 2017-02-21 at 63d3652c77)
+ config: squelch stupid compiler
(merged to 'next' on 2017-02-21 at 354f023a3a)
+ config: reject invalid VAR in 'git -c VAR=VAL command'
+ config: preserve <subsection> case for one-shot config on the command line
The code to parse "git -c VAR=VAL cmd" and set configuration
variable for the duration of cmd had two small bugs, which have
been fixed.
Will cook in 'next'.
* jh/memihash-opt (2017-02-17) 5 commits
- name-hash: remember previous dir_entry during lazy_init_name_hash
- name-hash: specify initial size for istate.dir_hash table
- name-hash: precompute hash values during preload-index
- hashmap: allow memihash computation to be continued
- name-hash: eliminate duplicate memihash call
Expecting an update for perf?
* km/delete-ref-reflog-message (2017-02-20) 4 commits
(merged to 'next' on 2017-02-21 at 4ee4ce3f64)
+ branch: record creation of renamed branch in HEAD's log
+ rename_ref: replace empty message in HEAD's log
+ update-ref: pass reflog message to delete_ref()
+ delete_ref: accept a reflog message argument
"git update-ref -d" and other operations to delete references did
not leave any entry in HEAD's reflog when the reference being
deleted was the current branch. This is not a problem in practice
because you do not want to delete the branch you are currently on,
but caused renaming of the current branch to something else not to
be logged in a useful way.
Will cook in 'next'.
* nd/prune-in-worktree (2017-02-19) 15 commits
. rev-list: expose and document --single-worktree
. revision.c: --reflog add HEAD reflog from all worktrees
. files-backend: make reflog iterator go through per-worktree reflog
. refs: add refs_for_each_reflog[_ent]()
. revision.c: --all adds HEAD from all worktrees
. refs: remove dead for_each_*_submodule()
. revision.c: use refs_for_each*() instead of for_each_*_submodule()
. refs: add a refs_for_each_in() and friends
. refs: add refs_for_each_ref()
. refs: add refs_head_ref()
. refs: add refs_read_ref[_full]()
. refs: move submodule slash stripping code to get_submodule_ref_store
. revision.c: --indexed-objects add objects from all worktrees
. revision.c: refactor add_index_objects_to_pending()
. revision.h: new flag in struct rev_info wrt. worktree-related refs
(this branch uses mh/ref-remove-empty-directory, mh/submodule-hash and nd/worktree-kill-parse-ref; is tangled with nd/files-backend-git-dir.)
"git gc" and friends when multiple worktrees are used off of a
single repository did not consider the index and per-worktree refs
of other worktrees as the root for reachability traversal, making
objects that are in use only in other worktrees to be subject to
garbage collection.
* mm/fetch-show-error-message-on-unadvertised-object (2017-02-22) 4 commits
- fetch-pack: add specific error for fetching an unadvertised object
- fetch_refs_via_pack: call report_unmatched_refs
- squash??? remove unfinished sentence
- fetch-pack: move code to report unmatched refs to a function
"git fetch" that requests a commit by object name, when the other
side does not allow such an request, failed without much
explanation.
* rl/remote-allow-missing-branch-name-merge (2017-02-21) 1 commit
(merged to 'next' on 2017-02-22 at cbe923c8da)
+ remote: ignore failure to remove missing branch.<name>.merge
"git remote rm X", when a branch has remote X configured as the
value of its branch.*.remote, tried to remove branch.*.remote and
branch.*.merge and failed if either is unset.
Will cook in 'next'.
* vn/xdiff-func-context (2017-01-15) 1 commit
(merged to 'next' on 2017-02-21 at 838eab8d93)
+ 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 cook in 'next'.
* nd/worktree-kill-parse-ref (2017-02-19) 22 commits
. refs: kill set_worktree_head_symref()
. refs: add refs_create_symref()
. worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe()
. refs.c: add refs_resolve_ref_unsafe()
. refs: introduce get_worktree_ref_store()
. refs: rename get_ref_store() to get_submodule_ref_store() and make it public
. files-backend: remove submodule_allowed from files_downcast()
. refs: move submodule code out of files-backend.c
. path.c: move some code out of strbuf_git_path_submodule()
. refs.c: make get_main_ref_store() public and use it
. refs.c: kill register_ref_store(), add register_submodule_ref_store()
. refs.c: flatten get_ref_store() a bit
. refs: rename lookup_ref_store() to lookup_submodule_ref_store()
. refs.c: introduce get_main_ref_store()
. files-backend: remove the use of git_path()
. refs.c: share is_per_worktree_ref() to files-backend.c
. files-backend: replace *git_path*() with files_path()
. files-backend: add files_path()
. files-backend: convert git_path() to strbuf_git_path()
. refs-internal.c: make files_log_ref_write() static
. Merge branch 'mh/ref-remove-empty-directory' into nd/files-backend-git-dir
. Merge branch 'mh/submodule-hash' into nd/files-backend-git-dir
(this branch is used by nd/prune-in-worktree; uses mh/ref-remove-empty-directory and mh/submodule-hash; is tangled with nd/files-backend-git-dir.)
(hopefully) a beginning of safer "git worktree" that is resistant
to "gc".
Needs review.
* nd/files-backend-git-dir (2017-02-22) 26 commits
. t1406: new tests for submodule ref store
. t1405: some basic tests on main ref store
. t/helper: add test-ref-store to test ref-store functions
. refs: delete pack_refs() in favor of refs_pack_refs()
. files-backend: avoid ref api targetting main ref store
. refs: new transaction related ref-store api
. refs: add new ref-store api
. refs: rename get_ref_store() to get_submodule_ref_store() and make it public
. files-backend: replace submodule_allowed check in files_downcast()
. refs: move submodule code out of files-backend.c
. path.c: move some code out of strbuf_git_path_submodule()
. refs.c: make get_main_ref_store() public and use it
. refs.c: kill register_ref_store(), add register_submodule_ref_store()
. refs.c: flatten get_ref_store() a bit
. refs: rename lookup_ref_store() to lookup_submodule_ref_store()
. refs.c: introduce get_main_ref_store()
. files-backend: remove the use of git_path()
. files-backend: add and use files_refname_path()
. files-backend: add and use files_reflog_path()
. files-backend: move "logs/" out of TMP_RENAMED_LOG
. files-backend: convert git_path() to strbuf_git_path()
. files-backend: add and use files_packed_refs_path()
. files-backend: make files_log_ref_write() static
. refs.h: add forward declaration for structs used in this file
. Merge branch 'mh/ref-remove-empty-directory' into nd/files-backend-git-dir
. Merge branch 'mh/submodule-hash' into nd/files-backend-git-dir
(this branch uses mh/ref-remove-empty-directory and mh/submodule-hash; is tangled with nd/prune-in-worktree and nd/worktree-kill-parse-ref.)
The "submodule" specific field in the ref_store structure is
replaced with a more generic "gitdir" that can later be used also
when dealing with ref_store that represents the set of refs visible
from the other worktrees.
Needs review.
* nd/clean-preserve-errno-in-warning (2017-02-16) 1 commit
(merged to 'next' on 2017-02-16 at c0802f7627)
+ clean: use warning_errno() when appropriate
Some warning() messages from "git clean" were updated to show the
errno from failed system calls.
Will cook in 'next'.
* mm/two-more-xstrfmt (2017-02-16) 2 commits
(merged to 'next' on 2017-02-17 at 2454ee9847)
+ bisect_next_all: convert xsnprintf to xstrfmt
+ stop_progress_msg: convert xsnprintf to xstrfmt
Code clean-up and a string truncation fix.
Will cook in 'next'.
* sb/checkout-recurse-submodules (2017-02-16) 15 commits
- builtin/checkout: add --recurse-submodules switch
- entry.c: update submodules when interesting
- read-cache: remove_marked_cache_entries to wipe selected submodules.
- unpack-trees: check if we can perform the operation for submodules
- unpack-trees: pass old oid to verify_clean_submodule
- update submodules: add submodule_go_from_to
- update submodules: move up prepare_submodule_repo_env
- submodules: introduce check to see whether to touch a submodule
- update submodules: add a config option to determine if submodules are updated
- update submodules: add submodule config parsing
- connect_work_tree_and_git_dir: safely create leading directories
- make is_submodule_populated gently
- lib-submodule-update.sh: define tests for recursing into submodules
- lib-submodule-update.sh: do not use ./. as submodule remote
- lib-submodule-update.sh: reorder create_lib_submodule_repo
"git checkout" is taught --recurse-submodules option.
Needs review.
* jh/preload-index-skip-skip (2017-02-10) 1 commit
(merged to 'next' on 2017-02-16 at 39077062f9)
+ preload-index: avoid lstat for skip-worktree items
The preload-index code has been taught not to bother with the index
entries that are paths that are not checked out by "sparse checkout".
Will cook in 'next'.
* tg/stash-push (2017-02-19) 6 commits
- stash: allow pathspecs in the no verb form
- stash: use stash_push for no verb form
- stash: teach 'push' (and 'create_stash') to honor pathspec
- stash: refactor stash_create
- stash: add test for the create command line arguments
- stash: introduce push verb
Allow "git stash" to take pathspec so that the local changes can be
stashed away only partially.
Needs review.
cf. <xmqqmvdfh4az.fsf@gitster.mtv.corp.google.com>
* bc/object-id (2017-02-22) 19 commits
- wt-status: convert to struct object_id
- builtin/merge-base: convert to struct object_id
- Convert object iteration callbacks to struct object_id
- sha1_file: introduce an nth_packed_object_oid function
- refs: simplify parsing of reflog entries
- refs: convert each_reflog_ent_fn to struct object_id
- reflog-walk: convert struct reflog_info to struct object_id
- builtin/replace: convert to struct object_id
- Convert remaining callers of resolve_refdup to object_id
- builtin/merge: convert to struct object_id
- builtin/clone: convert to struct object_id
- builtin/branch: convert to struct object_id
- builtin/grep: convert to struct object_id
- builtin/fmt-merge-message: convert to struct object_id
- builtin/fast-export: convert to struct object_id
- builtin/describe: convert to struct object_id
- builtin/diff-tree: convert to struct object_id
- builtin/commit: convert to struct object_id
- hex: introduce parse_oid_hex
"uchar [40]" to "struct object_id" conversion continues.
Now at v5; looked alright.
cf. <20170221234737.894681-1-sandals@crustytoothpaste.net>
* jk/grep-no-index-fix (2017-02-14) 7 commits
(merged to 'next' on 2017-02-16 at c84c927fa8)
+ grep: treat revs the same for --untracked as for --no-index
+ grep: do not diagnose misspelt revs with --no-index
+ grep: avoid resolving revision names in --no-index case
+ grep: fix "--" rev/pathspec disambiguation
+ grep: re-order rev-parsing loop
+ grep: do not unnecessarily query repo for "--"
+ grep: move thread initialization a little lower
The code to parse the command line "git grep <patterns>... <rev>
[[--] <pathspec>...]" has been cleaned up, and a handful of bugs
have been fixed (e.g. we used to check "--" if it is a rev).
Will cook in 'next'.
* jk/show-branch-lift-name-len-limit (2017-02-15) 3 commits
(merged to 'next' on 2017-02-16 at 40d22f5f34)
+ show-branch: use skip_prefix to drop magic numbers
+ show-branch: store resolved head in heap buffer
+ show-branch: drop head_len variable
"git show-branch" expected there were only very short branch names
in the repository and used a fixed-length buffer to hold them
without checking for overflow.
Will cook in 'next'.
* lt/oneline-decoration-at-end (2017-02-21) 2 commits
(merged to 'next' on 2017-02-21 at 35c7731ee3)
+ log: fix regression to "--source" when "--decorate" was updated
(merged to 'next' on 2017-02-16 at 5854e58811)
+ show decorations at the end of the line
The output from "git log --oneline --decorate" has been updated to
show the extra information at the end of the line, not near the
front.
Will cook in 'next'.
Perhaps this is not such a cool idea?
cf. <CA+55aFwT2HUBzZO8Gpt9tHoJtdRxv9oe3TDoSH5jcEOixRNBXg@mail.gmail.com>
* jn/remote-helpers-with-git-dir (2017-02-14) 2 commits
(merged to 'next' on 2017-02-16 at c093c543c4)
+ remote helpers: avoid blind fall-back to ".git" when setting GIT_DIR
+ remote: avoid reading $GIT_DIR config in non-repo
"git ls-remote" and "git archive --remote" are designed to work
without being in a directory under Git's control. However, recent
updates revealed that we randomly look into a directory called
.git/ without actually doing necessary set-up when working in a
repository. Stop doing so.
Will cook in 'next'.
* jk/alternate-ref-optim (2017-02-08) 11 commits
(merged to 'next' on 2017-02-10 at f26f32cff6)
+ receive-pack: avoid duplicates between our refs and alternates
+ receive-pack: treat namespace .have lines like alternates
+ receive-pack: fix misleading namespace/.have comment
+ receive-pack: use oidset to de-duplicate .have lines
+ add oidset API
+ fetch-pack: cache results of for_each_alternate_ref
+ for_each_alternate_ref: replace transport code with for-each-ref
+ for_each_alternate_ref: pass name/oid instead of ref struct
+ for_each_alternate_ref: use strbuf for path allocation
+ for_each_alternate_ref: stop trimming trailing slashes
+ for_each_alternate_ref: handle failure from real_pathdup()
Optimizes resource usage while enumerating refs from alternate
object store, to help receiving end of "push" that hosts a
repository with many "forks".
Will cook in 'next'.
* lt/pathspec-negative (2017-02-10) 2 commits
(merged to 'next' on 2017-02-10 at 8ea7874076)
+ pathspec: don't error out on all-exclusionary pathspec patterns
+ pathspec magic: add '^' as alias for '!'
The "negative" pathspec feature was somewhat more cumbersome to use
than necessary in that its short-hand used "!" which needed to be
escaped from shells, and it required "exclude from what?" specified.
Will cook in 'next'.
* js/rebase-helper (2017-02-09) 2 commits
(merged to 'next' on 2017-02-14 at ae2474048e)
+ rebase -i: use the rebase--helper builtin
+ rebase--helper: add a builtin helper for interactive rebases
"git rebase -i" starts using the recently updated "sequencer" code.
Will cook in 'next'.
The change itself is small, but what it enables is rather a large
body of new code. We are getting there ;-)
* mh/submodule-hash (2017-02-13) 9 commits
(merged to 'next' on 2017-02-14 at 43f2dcbe29)
+ read_loose_refs(): read refs using resolve_ref_recursively()
+ files_ref_store::submodule: use NULL for the main repository
+ base_ref_store_init(): remove submodule argument
+ refs: push the submodule attribute down
+ refs: store submodule ref stores in a hashmap
+ register_ref_store(): new function
+ refs: remove some unnecessary handling of submodule == ""
+ refs: make some ref_store lookup functions private
+ refs: reorder some function definitions
(this branch is used by nd/files-backend-git-dir, nd/prune-in-worktree and nd/worktree-kill-parse-ref.)
Code and design clean-up for the refs API.
Will cook in 'next'.
The tip one is newer than the one posted to the list but was sent
privately by the author via his GitHub repository.
* jh/mingw-openssl-sha1 (2017-02-09) 1 commit
(merged to 'next' on 2017-02-10 at 084b3d8503)
+ mingw: use OpenSSL's SHA-1 routines
Windows port wants to use OpenSSL's implementation of SHA-1
routines, so let them.
Will cook in 'next'.
cf. <31bb0b9f-d498-24b3-57d5-9f34cb8e3914@kdbg.org>
* dt/gc-ignore-old-gc-logs (2017-02-13) 1 commit
(merged to 'next' on 2017-02-16 at 8f48e1b405)
+ gc: ignore old gc.log files
A "gc.log" file left by a backgrounded "gc --auto" disables further
automatic gc; it has been taught to run at least once a day (by
default) by ignoring a stale "gc.log" file that is too old.
Will cook in 'next'.
This is v6 posted on Feb 10th.
* js/git-path-in-subdir (2017-02-17) 2 commits
(merged to 'next' on 2017-02-17 at b3c3b2dce6)
+ rev-parse: fix several options when running in a subdirectory
+ rev-parse tests: add tests executed from a subdirectory
The "--git-path", "--git-common-dir", and "--shared-index-path"
options of "git rev-parse" did not produce usable output. They are
now updated to show the path to the correct file, relative to where
the caller is.
Will cook in 'next'.
* mh/ref-remove-empty-directory (2017-01-07) 23 commits
(merged to 'next' on 2017-02-10 at bcfd359e95)
+ 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
(this branch is used by nd/files-backend-git-dir, nd/prune-in-worktree and nd/worktree-kill-parse-ref.)
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.
Will cook in 'next'.
* cw/tag-reflog-message (2017-02-08) 1 commit
(merged to 'next' on 2017-02-10 at 3968b3a58b)
+ tag: generate useful reflog message
"git tag", because refs/tags/* doesn't keep reflog by default, did
not leave useful message when adding a new entry to reflog.
Will cook in 'next'.
* sg/completion (2017-02-13) 22 commits
(merged to 'next' on 2017-02-13 at 118c192874)
+ completion: restore removed line continuating backslash
(merged to 'next' on 2017-02-10 at 55b2785d89)
+ completion: cache the path to the repository
+ completion: extract repository discovery from __gitdir()
+ completion: don't guard git executions with __gitdir()
+ completion: consolidate silencing errors from git commands
+ completion: don't use __gitdir() for git commands
+ completion: respect 'git -C <path>'
+ rev-parse: add '--absolute-git-dir' option
+ completion: fix completion after 'git -C <path>'
+ completion: don't offer commands when 'git --opt' needs an argument
+ completion: list short refs from a remote given as a URL
+ completion: don't list 'HEAD' when trying refs completion outside of a repo
+ completion: list refs from remote when remote's name matches a directory
+ completion: respect 'git --git-dir=<path>' when listing remote refs
+ completion: fix most spots not respecting 'git --git-dir=<path>'
+ completion: ensure that the repository path given on the command line exists
+ completion tests: add tests for the __git_refs() helper function
+ completion tests: check __gitdir()'s output in the error cases
+ completion tests: consolidate getting path of current working directory
+ completion tests: make the $cur variable local to the test helper functions
+ completion tests: don't add test cruft to the test repository
+ completion: improve __git_refs()'s in-code documentation
(this branch is used by sg/completion-refs-speedup.)
Clean-up and updates to command line completion (in contrib/).
Will cook in 'next'.
* sg/completion-refs-speedup (2017-02-13) 13 commits
- squash! completion: fill COMPREPLY directly when completing refs
- completion: fill COMPREPLY directly when completing refs
- completion: list only matching symbolic and pseudorefs when completing refs
- completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
- completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
- completion: let 'for-each-ref' strip the remote name from remote branches
- completion: let 'for-each-ref' and 'ls-remote' filter matching refs
- completion: don't disambiguate short refs
- completion: don't disambiguate tags and branches
- completion: support excluding full refs
- completion: support completing full refs after '--option=refs/<TAB>'
- completion: wrap __git_refs() for better option parsing
- completion: remove redundant __gitcomp_nl() options from _git_commit()
(this branch uses sg/completion.)
The refs completion for large number of refs has been sped up,
partly by giving up disambiguating ambiguous refs and partly by
eliminating most of the shell processing between 'git for-each-ref'
and 'ls-remote' and Bash's completion facility.
Will hold.
* sk/parse-remote-cleanup (2017-02-21) 2 commits
(merged to 'next' on 2017-02-21 at 302250072e)
+ Revert "parse-remote: remove reference to unused op_prep"
(merged to 'next' on 2017-02-06 at 6ec89f72d5)
+ parse-remote: remove reference to unused op_prep
Code clean-up.
Will discard.
There may be third-party scripts that are dot-sourcing this one.
* jk/delta-chain-limit (2017-01-27) 2 commits
(merged to 'next' on 2017-02-06 at 9ff36ae9b2)
+ pack-objects: convert recursion to iteration in break_delta_chain()
+ pack-objects: enforce --depth limit in reused deltas
"git repack --depth=<n>" for a long time busted the specified depth
when reusing delta from existing packs. This has been corrected.
Will cook in 'next'.
* mm/merge-rename-delete-message (2017-01-30) 1 commit
(merged to 'next' on 2017-02-10 at 8bf8146029)
+ merge-recursive: make "CONFLICT (rename/delete)" message show both paths
When "git merge" detects a path that is renamed in one history
while the other history deleted (or modified) it, it now reports
both paths to help the user understand what is going on in the two
histories being merged.
Will cook in 'next'.
* ps/urlmatch-wildcard (2017-02-01) 5 commits
(merged to 'next' on 2017-02-10 at 2ed9ea48ee)
+ urlmatch: allow globbing for the URL host part
+ urlmatch: include host in urlmatch ranking
+ urlmatch: split host and port fields in `struct url_info`
+ urlmatch: enable normalization of URLs with globs
+ mailmap: add Patrick Steinhardt's work address
The <url> part in "http.<url>.<variable>" configuration variable
can now be spelled with '*' that serves as wildcard.
E.g. "http.https://*.example.com.proxy" can be used to specify the
proxy used for https://a.example.com, https://b.example.com, etc.,
i.e. any host in the example.com domain.
Will cook in 'next'.
* sf/putty-w-args (2017-02-10) 5 commits
(merged to 'next' on 2017-02-14 at 7f157e7020)
+ connect.c: stop conflating ssh command names and overrides
+ connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config
+ git_connect(): factor out SSH variant handling
+ connect: rename tortoiseplink and putty variables
+ connect: handle putty/plink also in GIT_SSH_COMMAND
The command line options for ssh invocation needs to be tweaked for
some implementations of SSH (e.g. PuTTY plink wants "-P <port>"
while OpenSSH wants "-p <port>" to specify port to connect to), and
the variant was guessed when GIT_SSH environment variable is used
to specify it. The logic to guess now applies to the command
specified by the newer GIT_SSH_COMMAND and also core.sshcommand
configuration variable, and comes with an escape hatch for users to
deal with misdetected cases.
Will cook in 'next'.
* jk/describe-omit-some-refs (2017-01-23) 5 commits
(merged to 'next' on 2017-01-23 at f8a14b4996)
+ 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 cook in 'next'.
* bw/attr (2017-02-01) 27 commits
(merged to 'next' on 2017-02-14 at d35c1d7e4a)
+ 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: 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.
Will cook in 'next'.
* kn/ref-filter-branch-list (2017-02-07) 21 commits
(merged to 'next' on 2017-02-10 at 794bb8284d)
+ ref-filter: resurrect "strip" as a synonym to "lstrip"
(merged to 'next' on 2017-01-31 at e7592a5461)
+ 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.
Will cook in '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'.
* 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'.
* 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.
--------------------------------------------------
[Discarded]
* sb/push-make-submodule-check-the-default (2017-01-26) 2 commits
(merged to 'next' on 2017-01-26 at 5f4715cea6)
+ Revert "push: change submodule default to check when submodules exist"
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ push: change submodule default to check when submodules exist
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Retracted.
* ls/submodule-config-ucase (2017-02-15) 2 commits
. submodule config does not apply to upper case submodules?
. t7400: cleanup "submodule add clone shallow submodule" test
Demonstrate a breakage in handling submodule.UPPERCASENAME.update
configuration variables.
Superseded by jc/config-case-cmdline.
^ permalink raw reply
* Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits
From: Devin J. Pohly @ 2017-02-23 21:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Charles Bailey, Jeff King, Pierre Habouzit,
git
In-Reply-To: <xmqqbmts7gjm.fsf@gitster.mtv.corp.google.com>
On Thu, Feb 23, 2017 at 01:17:49PM -0800, Junio C Hamano wrote:
> "Devin J. Pohly" <djpohly@gmail.com> writes:
>
> > Previously, the git_commit_non_empty_tree function would always pass any
> > commit with no parents to git-commit-tree, regardless of whether the
> > tree was nonempty. The new commit would then be recorded in the
> > filter-branch revision map, and subsequent commits which leave the tree
> > untouched would be correctly filtered.
> >
> > With this change, parentless commits with an empty tree are correctly
> > pruned, and an empty file is recorded in the revision map, signifying
> > that it was rewritten to "no commits." This works naturally with the
> > parent mapping for subsequent commits.
> >
> > Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
> > ---
>
> I am not sure if a root that records an empty tree should be pruned
> with --prune-empty to begin with.
>
> When we are pruning consecutive commits in the other parts of the
> history because they have identical (presumably non-empty) trees,
> should an empty root that the original history wanted to create be
> pruned because before the commit it was void, after the commit it is
> empty? Should "void" (lack of any tree) and "empty" (the tree is
> there, but it does not have anything in it) be treated the same?
> Shouldn't root be treated as a bit more special thing?
>
The case I had in mind was a filter which happened to remove all changes
from any parentless commit (see the testcase added to t7003). It would
not necessarily have been an empty commit in the original history.
Use case/motivation: I am splitting my dotfiles repo to migrate to vcsh,
and the original first commit (which only touches a few files) appears
in every branch. In the branches which do not include those files, the
commit is empty but still present.
I think your point is interesting too, though. If a commit is also
TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems
reasonable that someone might want to leave it in the filtered branch as
an empty commit while pruning empt*ied* commits. I would imagine that
as another option (--prune-newly-empty?).
>
> I myself do not have a good answer to the above questions.
>
> I think the updated code makes sense, provided if we decide that
> void to empty is just like transitioning between two identical
> (presumably non-empty) trees. The updated documentation is a lot
> more readable as well.
>
> Comments from those who have been involved in filter-branch?
>
> > Documentation/git-filter-branch.txt | 14 ++++++--------
> > git-filter-branch.sh | 2 ++
> > 2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
> > index 0a09698c0..6e4bb0220 100644
> > --- a/Documentation/git-filter-branch.txt
> > +++ b/Documentation/git-filter-branch.txt
> > @@ -167,14 +167,12 @@ to other tags will be rewritten to point to the underlying commit.
> > project root. Implies <<Remap_to_ancestor>>.
> >
> > --prune-empty::
> > - Some kind of filters will generate empty commits, that left the tree
> > - untouched. This switch allow git-filter-branch to ignore such
> > - commits. Though, this switch only applies for commits that have one
> > - and only one parent, it will hence keep merges points. Also, this
> > - option is not compatible with the use of `--commit-filter`. Though you
> > - just need to use the function 'git_commit_non_empty_tree "$@"' instead
> > - of the `git commit-tree "$@"` idiom in your commit filter to make that
> > - happen.
> > + Some filters will generate empty commits that leave the tree untouched.
> > + This option instructs git-filter-branch to remove such commits if they
> > + have exactly one or zero non-pruned parents; merge commits will
> > + therefore remain intact. This option cannot be used together with
> > + `--commit-filter`, though the same effect can be achieved by using the
> > + provided `git_commit_non_empty_tree` function in a commit filter.
> >
> > --original <namespace>::
> > Use this option to set the namespace where the original commits
> > diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> > index 86b2ff1e0..2b8cdba15 100755
> > --- a/git-filter-branch.sh
> > +++ b/git-filter-branch.sh
> > @@ -46,6 +46,8 @@ git_commit_non_empty_tree()
> > {
> > if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
> > map "$3"
> > + elif test $# = 1 && test "$1" = 4b825dc642cb6eb9a060e54bf8d69288fbee4904; then
> > + :
> > else
> > git commit-tree "$@"
> > fi
--
<><
^ permalink raw reply
* Re: SHAttered (the first practical SHA1 attack)
From: Jakub Narębski @ 2017-02-23 21:20 UTC (permalink / raw)
To: Santiago Torres, Git
In-Reply-To: <20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>
W dniu 23.02.2017 o 16:50, Santiago Torres pisze:
> Hello all,
>
> I ran into this website presenting the "first practical attack on
> sha1"[1]. I don't recall seeing this on the ML, so I'm sharing this just
> in case. I know there are proposals to move out of sha1 already. I
> wonder if this affects the timeline for their adoption?
>
> Thanks,
> -Santiago.
>
> [1] https://shattered.io/
This is already being discussed in "SHA1 collisions found"[1]
thread. Let's do the discussion there.
[1] https://public-inbox.org/git/xmqqk28g92h7.fsf@gitster.mtv.corp.google.com
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits
From: Junio C Hamano @ 2017-02-23 21:17 UTC (permalink / raw)
To: Johannes Schindelin, Charles Bailey, Jeff King, Pierre Habouzit
Cc: git, Devin J. Pohly
In-Reply-To: <20170223082736.31283-3-djpohly@gmail.com>
"Devin J. Pohly" <djpohly@gmail.com> writes:
> Previously, the git_commit_non_empty_tree function would always pass any
> commit with no parents to git-commit-tree, regardless of whether the
> tree was nonempty. The new commit would then be recorded in the
> filter-branch revision map, and subsequent commits which leave the tree
> untouched would be correctly filtered.
>
> With this change, parentless commits with an empty tree are correctly
> pruned, and an empty file is recorded in the revision map, signifying
> that it was rewritten to "no commits." This works naturally with the
> parent mapping for subsequent commits.
>
> Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
> ---
I am not sure if a root that records an empty tree should be pruned
with --prune-empty to begin with.
When we are pruning consecutive commits in the other parts of the
history because they have identical (presumably non-empty) trees,
should an empty root that the original history wanted to create be
pruned because before the commit it was void, after the commit it is
empty? Should "void" (lack of any tree) and "empty" (the tree is
there, but it does not have anything in it) be treated the same?
Shouldn't root be treated as a bit more special thing?
I myself do not have a good answer to the above questions.
I think the updated code makes sense, provided if we decide that
void to empty is just like transitioning between two identical
(presumably non-empty) trees. The updated documentation is a lot
more readable as well.
Comments from those who have been involved in filter-branch?
> Documentation/git-filter-branch.txt | 14 ++++++--------
> git-filter-branch.sh | 2 ++
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
> index 0a09698c0..6e4bb0220 100644
> --- a/Documentation/git-filter-branch.txt
> +++ b/Documentation/git-filter-branch.txt
> @@ -167,14 +167,12 @@ to other tags will be rewritten to point to the underlying commit.
> project root. Implies <<Remap_to_ancestor>>.
>
> --prune-empty::
> - Some kind of filters will generate empty commits, that left the tree
> - untouched. This switch allow git-filter-branch to ignore such
> - commits. Though, this switch only applies for commits that have one
> - and only one parent, it will hence keep merges points. Also, this
> - option is not compatible with the use of `--commit-filter`. Though you
> - just need to use the function 'git_commit_non_empty_tree "$@"' instead
> - of the `git commit-tree "$@"` idiom in your commit filter to make that
> - happen.
> + Some filters will generate empty commits that leave the tree untouched.
> + This option instructs git-filter-branch to remove such commits if they
> + have exactly one or zero non-pruned parents; merge commits will
> + therefore remain intact. This option cannot be used together with
> + `--commit-filter`, though the same effect can be achieved by using the
> + provided `git_commit_non_empty_tree` function in a commit filter.
>
> --original <namespace>::
> Use this option to set the namespace where the original commits
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 86b2ff1e0..2b8cdba15 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -46,6 +46,8 @@ git_commit_non_empty_tree()
> {
> if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
> map "$3"
> + elif test $# = 1 && test "$1" = 4b825dc642cb6eb9a060e54bf8d69288fbee4904; then
> + :
> else
> git commit-tree "$@"
> fi
^ permalink raw reply
* Re: [PATCH 4/4] ident: do not ignore empty config name/email
From: Junio C Hamano @ 2017-02-23 20:58 UTC (permalink / raw)
To: Jeff King; +Cc: bs.x.ttp, git
In-Reply-To: <20170223081708.ge34zjkmpsolocqx@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This one is perhaps questionable. Maybe somebody is relying on setting a
> per-repo user.name to override a ~/.gitconfig value and enforce
> auto-detection?
Thanks for splitting this step out. 1/4 and 2/4 are obvious
improvements, and 3/4 is a very sensible fix. Compared to those
three, this one does smell questionable, because I do not quite see
any other reasonable fallback other than the auto-detection if the
user gives an empty ident on purpose.
Erroring out to say "don't do that" is probably not too bad, but
perhaps we are being run by a script that is doing a best-effort
conversion from $ANOTHER_SCM using a list of known authors that is
incomplete, ending up feeding empty ident and allowing us to fall
back to attribute them to the user who runs the script. I do not
see a point in breaking that user and having her or him update the
script to stuff in a truly bogus "Unknown <unknown>" name.
>
> ident.c | 4 ++--
> t/t7518-ident-corner-cases.sh | 11 +++++++++++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/ident.c b/ident.c
> index ead09ff7f..c0364fe3a 100644
> --- a/ident.c
> +++ b/ident.c
> @@ -153,7 +153,7 @@ static void copy_email(const struct passwd *pw, struct strbuf *email,
>
> const char *ident_default_name(void)
> {
> - if (!git_default_name.len) {
> + if (!(ident_config_given & IDENT_NAME_GIVEN) && !git_default_name.len) {
> copy_gecos(xgetpwuid_self(&default_name_is_bogus), &git_default_name);
> strbuf_trim(&git_default_name);
> }
> @@ -162,7 +162,7 @@ const char *ident_default_name(void)
>
> const char *ident_default_email(void)
> {
> - if (!git_default_email.len) {
> + if (!(ident_config_given & IDENT_MAIL_GIVEN) && !git_default_email.len) {
> const char *email = getenv("EMAIL");
>
> if (email && email[0]) {
> diff --git a/t/t7518-ident-corner-cases.sh b/t/t7518-ident-corner-cases.sh
> index 3d2560c3c..ef570ac62 100755
> --- a/t/t7518-ident-corner-cases.sh
> +++ b/t/t7518-ident-corner-cases.sh
> @@ -22,4 +22,15 @@ test_expect_success 'commit rejects all-crud name' '
> git commit --allow-empty -m foo
> '
>
> +# We must test the actual error message here, as an unwanted
> +# auto-detection could fail for other reasons.
> +test_expect_success 'empty configured name does not auto-detect' '
> + (
> + sane_unset GIT_AUTHOR_NAME &&
> + test_must_fail \
> + git -c user.name= commit --allow-empty -m foo 2>err &&
> + test_i18ngrep "empty ident name" err
> + )
> +'
> +
> test_done
^ permalink raw reply
* Re: SHA1 collisions found
From: Jeff King @ 2017-02-23 20:57 UTC (permalink / raw)
To: Jakub Narębski
Cc: David Lang, Junio C Hamano, Joey Hess, Git Mailing List
In-Reply-To: <e57958d4-7c51-3f5e-6ff5-f863920fd883@gmail.com>
On Thu, Feb 23, 2017 at 09:49:09PM +0100, Jakub Narębski wrote:
> > How is GIT affected? GIT strongly relies on SHA-1 for the
> > identification and integrity checking of all file objects and
> > commits. It is essentially possible to create two GIT repositories
> > with the same head commit hash and different contents, say a benign
> > source code and a backdoored one. An attacker could potentially
> > selectively serve either repository to targeted users. This will
> > require attackers to compute their own collision.
>
> The attack on SHA-1 presented there is "identical-prefix" collision,
> which is less powerful than "chosen-prefix" collision. It is the
> latter that is required to defeat SHA-1 used in object identity.
> Objects in Git _must_ begin with given prefix;
I don't think this helps. The chosen-prefix lets you append hash data to
an existing file. Here we just have identical prefixes in the two
colliding halves. In the real-world example, they used a PDF header. But
it could have been a PDF header with "blob 1234" prepended to it (note
also that Git's use of the size doesn't help; the attack files are the
same length).
> the use of zlib
> compression adds to the difficulty. 'Forged' Git object would
> simply not validate...
No, zlib doesn't help. The sha1 is computed on the uncompressed data.
-Peff
^ permalink raw reply
* Re: SHA1 collisions found
From: Joey Hess @ 2017-02-23 20:46 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20170223184637.xr74k42vc6y2pmse@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
Jeff King wrote:
> It's not an identical prefix, but I think collision attacks generally
> are along the lines of selecting two prefixes followed by garbage, and
> then mutating the garbage on both sides. That would "work" in this case
> (modulo the fact that git would complain about the NUL).
>
> I haven't read the paper yet to see if that is the case here, though.
The current attack is an identical-prefix attack, not chosen-prefix, so
not quite to that point yet.
The MD5 chosen-prefix attack was 2^15 harder than the known-prefix attack,
but who knows if the numbers will be comprable for SHA1.
> A related case is if you could stick a "cruft ...." header at the end of
> the commit headers, and mutate its value (avoiding newlines). fsck
> doesn't complain about that.
git log and git show don't show such cruft headers either.
BTW, the SHA attack only added ~128 bytes to the pdfs, not really a
huge amount of garbage.
--
see shy jo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] git svn branch fails with authenticaton failures
From: Eric Wong @ 2017-02-23 20:54 UTC (permalink / raw)
To: Hiroshi Shirosaki; +Cc: git
In-Reply-To: <1487731055-29153-1-git-send-email-h.shirosaki@gmail.com>
Hiroshi Shirosaki <h.shirosaki@gmail.com> wrote:
> I have the following authentication failure while svn rebase and
> svn dcommit works fine without authentication failures.
>
> $ git svn branch v7_3
> Copying https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx at r27519
> to https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/v7_3...
> Can't create session: Unable to connect to a repository at URL
> 'https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx': No more
> credentials or we tried too many times.
> Authentication failed at
> C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 1200.
>
> I can workaround the issue to add auth configuration to
> SVN::Client->new().
Missing sign-off (see Documentation/SubmittingPatches).
Not my rule, but it's unfortunately required for this project.
Also, the Subject: should be in the imperative mood,
Perhaps something like:
Subject: [PATCH] git svn: fix authentication with 'branch'
I am less picky about the message body.
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1175,10 +1175,10 @@ sub cmd_branch {
> ::_req_svn();
> require SVN::Client;
>
> + my ($config, $baton, $callbacks) = Git::SVN::Ra::prepare_config_once();
Since we're not using it, here, you can avoid setting a variable
for $callbacks more explicitly:
my ($config, $baton, undef) = Git::SVN::Ra::prepare_config_once();
> my $ctx = SVN::Client->new(
> - config => SVN::Core::config_get_config(
> - $Git::SVN::Ra::config_dir
> - ),
> + auth => $baton,
> + config => $config,
> log_msg => sub {
> ${ $_[0] } = defined $_message
> ? $_message
> --
Anyways, this looks like a good change. I will accept a v2
with your sign-off and changes noted above. Thank you.
^ permalink raw reply
* Re: SHA1 collisions found
From: Jakub Narębski @ 2017-02-23 20:49 UTC (permalink / raw)
To: David Lang, Junio C Hamano; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <nycvar.QRO.7.75.62.1702230907340.6590@qynat-yncgbc>
W dniu 23.02.2017 o 18:12, David Lang pisze:
> On Thu, 23 Feb 2017, Junio C Hamano wrote:
>
>> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess <id@joeyh.name> wrote:
>>>
>>> Since we now have collisions in valid PDF files, collisions in
>>> valid git commit and tree objects are probably able to be
>>> constructed.
>>
>> That may be true, but
>> https://public-inbox.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/
>>
>
> it doesn't help that the Google page on this explicitly says that
> this shows that it's possible to create two different git repos that
> have the same hash but different contents.
>
> https://shattered.it/
>
> How is GIT affected? GIT strongly relies on SHA-1 for the
> identification and integrity checking of all file objects and
> commits. It is essentially possible to create two GIT repositories
> with the same head commit hash and different contents, say a benign
> source code and a backdoored one. An attacker could potentially
> selectively serve either repository to targeted users. This will
> require attackers to compute their own collision.
The attack on SHA-1 presented there is "identical-prefix" collision,
which is less powerful than "chosen-prefix" collision. It is the
latter that is required to defeat SHA-1 used in object identity.
Objects in Git _must_ begin with given prefix; the use of zlib
compression adds to the difficulty. 'Forged' Git object would
simply not validate...
https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/
^ permalink raw reply
* Re: [PATCH] http(s): automatically try NTLM authentication first
From: Jeff King @ 2017-02-23 20:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, David Turner, git@vger.kernel.org,
sandals@crustytoothpaste.net, Eric Sunshine
In-Reply-To: <xmqqlgsw7iey.fsf@gitster.mtv.corp.google.com>
On Thu, Feb 23, 2017 at 12:37:25PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I suspect it isn't enough to help without 2/2. This will tell curl that
> > the server does not do Negotiate, so it will skip the probe request. But
> > Git will still feed curl the bogus empty credential.
> >
> > That's what 2/2 tries to fix: only kick in the emptyAuth hack when there
> > is something besides Basic[1] to try. The way it is written adds an
>
> In your [1] you wanted to mention that Digest would have the same
> property as Basic, or something like that?
Oops, yeah. What I was going to say is that we may want a list of auth
types where we _do_ want the hack on, rather than ones where we know it
does not work. People are more likely to notice when the list is wrong,
then.
> > But if we are worried about turning on emptyAuth everywhere, the auto
> > behavior could be tied to emptyauth=true (and have something like
> > "emptyauth=always" to _really_ force it). I don't have an opinion there.
>
> I do not have a strong opinion, either, but it sounds like that even
> the "disable emptyAuth hack if the server is Basic only" variant
> would be much better than setting emptyAuth on by default. At least
> the user whose issue was reported in Dscho's message would be fixed
> by such a variant, I would think (i.e. talking to a server with no
> Negotiate and emptyAuth set to true results in no attempt to give
> the user a chance to tell who s/he is --- your 2/2 will turn
> emptyAuth off in that case).
Yes, I agree that the "auto" behavior is better than defaulting to
"true". I am speaking from the perspective of git.git, which is
currently defaulting to "false". It is not clear to me if "auto" is
better than "false" because of the security implications.
For Git for Windows, it seems like the auto behavior would be a strict
improvement over the "true" default they've been shipping.
-Peff
^ permalink raw reply
* Re: SHA1 collisions found
From: Øyvind A. Holm @ 2017-02-23 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Joey Hess, Git Mailing List
In-Reply-To: <CA+55aFx=0EVfSG2iEKKa78g3hFN_yZ+L_FRm4R749nNAmTGO9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]
On 2017-02-23 11:09:32, Linus Torvalds wrote:
> I'm aware of the fsck checks, but I have to admit I wasn't aware of
> 'transfer.fsckobjects'. I should turn that on myself.
>
> Or maybe git should just turn it on by default?
The problem with this is that there are many repos with errors out
there, for example coreutils.git and nasm.git, which complains about
"missingSpaceBeforeDate: invalid author/committer line - missing space
before date".
There are also lots of repositories bitten by the Github bug from back
in 2011 where they zero-padded the file modes, git clone aborts with
"zeroPaddedFilemode: contains zero-padded file modes".
Paranoid as I am, I'm using fetch.fsckObjects and receive.fsckObjects
set to "true", but that means I'm not able to clone repositories with
these kind of errors, have to use the alias
fclone = clone -c "fetch.fsckObjects=false"
So enabling them by default will create problems among users. Of course,
one solution would be to turn these kind of errors into warnings so the
clone isn't aborted.
Reagards,
Øyvind
+-| Øyvind A. Holm <sunny@sunbase.org> - N 60.37604° E 5.33339° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+------------| c7e47a18-fa06-11e6-ad93-db5caa6d21d3 |-------------+
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] http(s): automatically try NTLM authentication first
From: Junio C Hamano @ 2017-02-23 20:37 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, David Turner, git@vger.kernel.org,
sandals@crustytoothpaste.net, Eric Sunshine
In-Reply-To: <20170223194237.eckkpiqv7inuz7un@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I suspect it isn't enough to help without 2/2. This will tell curl that
> the server does not do Negotiate, so it will skip the probe request. But
> Git will still feed curl the bogus empty credential.
>
> That's what 2/2 tries to fix: only kick in the emptyAuth hack when there
> is something besides Basic[1] to try. The way it is written adds an
In your [1] you wanted to mention that Digest would have the same
property as Basic, or something like that?
> extra "auto" mode to emptyAuth, as I wanted to leave "emptyauth=true" as
> a workaround in case the "auto" behavior does not work. And then I
> turned on "auto" by default, since that was what the discussion was
> shooting for.
>
> But if we are worried about turning on emptyAuth everywhere, the auto
> behavior could be tied to emptyauth=true (and have something like
> "emptyauth=always" to _really_ force it). I don't have an opinion there.
I do not have a strong opinion, either, but it sounds like that even
the "disable emptyAuth hack if the server is Basic only" variant
would be much better than setting emptyAuth on by default. At least
the user whose issue was reported in Dscho's message would be fixed
by such a variant, I would think (i.e. talking to a server with no
Negotiate and emptyAuth set to true results in no attempt to give
the user a chance to tell who s/he is --- your 2/2 will turn
emptyAuth off in that case).
^ permalink raw reply
* git bugs
From: Sean Hunt @ 2017-02-23 20:27 UTC (permalink / raw)
To: git
There are a few bugs I git I noticed when using mingw, mingw64,
cygwin, and cygwin64. These bugs are the following:
if I do git ``rebase -i --root`` and tell it to edit every commit to
gpg sign all my commits it bugs out and merges all of the commits into
1 commit instead of only appending the ``-S`` to each and every commit
and keeping all of the commits. It is as if I told it to squash the
commits but yet I did not. There is also another bug where if I clone
a repo on Windows and not on github desktop and that I placed commits
to the repo on github web and then when I rebase to squash the commits
to 1 commit (some repos are doing it as a requirement for 1 commit
PR's) that all of my commits on the remote (fork in this case) that is
linked to an open pull request are discarded and then the pull request
is somehow and oddly closed. It is super annoying.
^ permalink raw reply
* Re: [PATCH] upload-pack: report "not our ref" to client
From: Junio C Hamano @ 2017-02-23 20:14 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <20170223184303.26530-1-jonathantanmy@google.com>
Thanks.
^ permalink raw reply
* RE: [PATCH 2/2] http: add an "auto" mode for http.emptyauth
From: David Turner @ 2017-02-23 20:05 UTC (permalink / raw)
To: 'Jeff King'
Cc: Junio C Hamano, git@vger.kernel.org, sandals@crustytoothpaste.net,
Johannes Schindelin, Eric Sunshine
In-Reply-To: <20170223194418.eqi5ynhyhrcybiok@sigill.intra.peff.net>
> -----Original Message-----
> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, February 23, 2017 2:44 PM
> To: David Turner <David.Turner@twosigma.com>
> Cc: Junio C Hamano <gitster@pobox.com>; git@vger.kernel.org;
> sandals@crustytoothpaste.net; Johannes Schindelin
> <johannes.schindelin@gmx.de>; Eric Sunshine <sunshine@sunshineco.com>
> Subject: Re: [PATCH 2/2] http: add an "auto" mode for http.emptyauth
>
> On Thu, Feb 23, 2017 at 04:31:13PM +0000, David Turner wrote:
>
> > > As somebody who is using non-Basic auth, can you apply these patches
> > > and show us the output of:
> > >
> > > GIT_TRACE_CURL=1 \
> > > git ls-remote https://your-server 2>&1 >/dev/null |
> > > egrep '(Send|Recv) header: (GET|HTTP|Auth)'
> > >
> > > (without http.emptyauth turned on, obviously).
> >
> > The results appear to be identical with and without the patch. With
> > http.emptyauth turned off,
> > 16:27:28.208924 http.c:524 => Send header: GET
> /info/refs?service=git-upload-pack HTTP/1.1
> > 16:27:28.212872 http.c:524 <= Recv header: HTTP/1.1 401
> Authorization Required
> > Username for 'http://git': [I just pressed enter] Password for
> > 'http://git': [ditto]
> > 16:27:29.928872 http.c:524 => Send header: GET
> /info/refs?service=git-upload-pack HTTP/1.1
> > 16:27:29.929787 http.c:524 <= Recv header: HTTP/1.1 401
> Authorization Required
>
> Just to be sure: did you remove http.emptyauth config completely from your
> config files, or did you turn it to "false"? Because the new behavior only kicks
> in when it isn't configured at all (probably we should respect "auto" as a user-
> provided name).
I turned it to false. With it completely removed, I get this, both times:
20:03:49.896797 http.c:524 => Send header: GET /info/refs?service=git-upload-pack HTTP/1.1
20:03:49.900776 http.c:524 <= Recv header: HTTP/1.1 401 Authorization Required
20:03:49.900929 http.c:524 => Send header: GET /info/refs?service=git-upload-pack HTTP/1.1
20:03:49.904754 http.c:524 <= Recv header: HTTP/1.1 401 Authorization Required
20:03:49.906649 http.c:524 => Send header: GET /info/refs?service=git-upload-pack HTTP/1.1
20:03:49.906654 http.c:524 => Send header: Authorization: Negotiate <redacted>
20:03:49.956753 http.c:524 <= Recv header: HTTP/1.1 200 OK - $gitservername
> > (if someone else wants to replicate this, delete >/dev/null bit from
> > Jeff's shell snippet)
>
> Hrm, you shouldn't need to. The stderr redirection comes first, so it should
> become the new stdout.
Weird. It didn't appear work earlier, but I must have screwed something up.
And I learned something about shell redirection.
^ permalink raw reply
* Re: [PATCH v5 1/1] config: add conditional include
From: Junio C Hamano @ 2017-02-23 19:59 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jeff King, sschuberth, Matthieu Moy
In-Reply-To: <20170223122346.12222-2-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>> There was some discussion after v4. I think the open issues are:
>>
>> - the commit message is rather terse (it should describe motivation,
>> and can refer to the docs for the "how")
> This allows some more flexibility in managing configuration across
> repositories.
That is not an ideal opening to describe motivation without people
knowing what "this" is ;-) Of course, the person who wrote the
sentence know it already after writing the patch and the subject,
but others don't.
Sometimes a set of repositories want to share configuration
settings among themselves that are distinct from other such
sets of repositories. A user may work on two projects, each
of which have multiple repositories, and use one user.email
for one project while using another for the other. Having
the settings in ~/.gitconfig, which would work for just one
set of repositories, would not well in such a situation.
Extend the include.path mechanism that lets a config file
include another config file, so that the inclusion can be
done only when some conditions hold. Then ~/.gitconfig can
say "include config-project-A only when working on project-A"
for each project A the user works on.
In this patch, the only supported grouping is based on
$GIT_DIR (in absolute path), so you would need to group
repositories by directory, or something like that to take
advantage of it.
We already have include.path for unconditional
includes. This patch goes with include-if.xxx.path to make
it clearer that a condition is required.
Similar to include.path, older git versions that don't
understand include-if will simply ignore them.
or something along that line?
> +Conditional includes
> +~~~~~~~~~~~~~~~~~~~~
> +
> +You can include one config file from another conditionally by setting
> +a special `include-if.<condition>.path` variable to the name of the
> +file to be included. The variable is treated the same way as
> +`include.path`.
Drop "special", as all configuration variables are "special" in their
own sense, it does not add any useful information.
I think we avoid '-' in Git-native variable and section names, so
"include-if" would become an odd-man-out.
The variable is obviously not treated the same way as include.path ;-)
When includeIf.<condition>.path variable is set in a
configuration file, the configuration file named by that
variable is included (in a way similar to how include.path
works) only if the <condition> holds true.
> +The condition starts with a keyword, followed by a colon and a
> +pattern. The interpretation of the pattern depends on the keyword.
"a pattern"? I think it is "some data whose format and meaning
depends on the keyword".
Hence...
> +Supported keywords are:
> +
> +`gitdir`::
> + The environment variable `GIT_DIR` must match the following
> + pattern for files to be included. The pattern can contain
The data that follows the keyword `gitdir:` is used as a
glob pattern. If the location of the .git directory (which
may be auto-discovered, or come from `GIT_DIR` environment
variable) match the pattern, the `<condition>` becomes true.
> + ...
> + * If the pattern ends with `/`, `**` will be automatically added. For
> + example, the pattern `foo/` becomes `foo/**`. In other words, it
> + matches "foo" and everything inside, recursively.
> +
> +`gitdir/i`::
> + This is the same as `gitdir` except that matching is done
> + case-insensitively (e.g. on case-insensitive file sytems)
> +
> +A few more notes on matching:
As future <keywords> may not be about path or matching at all, this
belongs to `gitdir`:: section (and it would be obvious that that
applies to `gitdir/i`:: because we say "this is the same as...").
> + * Symlinks in `$GIT_DIR` are not resolved before matching.
> +
> + * Note that "../" is not special and will match literally, which is
> + unlikely what you want.
> +static int prepare_include_condition_pattern(struct strbuf *pat)
> +{
> + struct strbuf path = STRBUF_INIT;
> + int prefix = 0;
> +
> + /* TODO: maybe support ~user/ too */
> + if (pat->buf[0] == '~' && is_dir_sep(pat->buf[1])) {
> + const char *home = getenv("HOME");
> +
> + if (!home)
> + return error(_("$HOME is not defined"));
Instead of half-duplicating it here yourself, can't we let
expand_user_path() do its thing?
> +static int include_condition_is_true(const char *cond, size_t cond_len)
> +{
> + /* no condition (i.e., "include.path") is always true */
> + if (!cond)
> + return 1;
> +
> + if (skip_prefix_mem(cond, cond_len, "gitdir:", &cond, &cond_len))
> + return include_by_gitdir(cond, cond_len, 0);
> + else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond, &cond_len))
> + return include_by_gitdir(cond, cond_len, 1);
This may be OK for now, but it should be trivial to start from a
table with two entries, i.e.
struct include_cond {
const char *keyword;
int (*fn)(const char *, size_t);
};
and will show a better way to do things to those who follow your
footsteps.
^ permalink raw reply
* Re: SHA1 collisions found
From: Jeff King @ 2017-02-23 19:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <CA+55aFx=0EVfSG2iEKKa78g3hFN_yZ+L_FRm4R749nNAmTGO9w@mail.gmail.com>
On Thu, Feb 23, 2017 at 11:09:32AM -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2017 at 10:46 AM, Jeff King <peff@peff.net> wrote:
> >>
> >> So I agree with you that we need to make git check for the opaque
> >> data. I think I was the one who brought that whole argument up.
> >
> > We do already.
>
> I'm aware of the fsck checks, but I have to admit I wasn't aware of
> 'transfer.fsckobjects'. I should turn that on myself.
>
> Or maybe git should just turn it on by default? At least the
> per-object fsck costs should be essentially free compared to the
> network costs when you just apply them to the incoming objects.
Yeah, they're not expensive. We've discussed enabling them by default.
The sticking point is that there is old history with minor bugs which
triggers some warnings (e.g., malformed committer names), and it would
be annoying to start rejecting that unconditionally.
So I think we would need a good review of what is a "warning" versus an
"error", and to only reject on errors (right now the NUL thing is a
warning, and it should probably upgraded).
> And in particular, while the *kernel* doesn't generally have critical
> opaque blobs, other projects do. Things like firmware images etc are
> open to attack, and crazy people put ISO images in repositories etc.
>
> So I don't think this discussion should focus exclusively on the git metadata.
>
> It is likely much easier to replace a binary blob than it is to
> replace a commit or tree (or a source file that has to go through a
> compiler). And for many projects, that would be a bad thing.
Yes, I'd agree we need to consider both. And no matter what Git does in
its own data formats, blobs will always be a sequence of bytes. Hiding
collision-cruft in them isn't up to us, but rather the data format.
The nice thing about a blob collision, though, is that you can only
replace the opaque files, not, say, C source code. That doesn't make it
a non-issue, but it reduces the scope of an attack.
Replacing a commit or tree wholesale means the attacker has a lot more
flexibility. So to whatever degree we can make that harder (like
complaining of commits with NULs), the better.
> > It's not an identical prefix, but I think collision attacks generally
> > are along the lines of selecting two prefixes followed by garbage, and
> > then mutating the garbage on both sides. That would "work" in this case
> > (modulo the fact that git would complain about the NUL).
>
> I think this particular attack depended on an actual identical prefix,
> but I didn't go back to the paper and check.
The paper describes the content as:
SHA-1(P | M1 | M2 | S)
and they replace both "M1" and "M2", with a near-collision for the
first, and then the final collision for the second. What's not clear to
me is if part of M1 can be chosen, or if it's perturbed fully into
random garbage.
> But the attacks tend to very much depend on particular input bit
> patterns that have very particular effects on the resulting
> intermediate hash, and those bit patterns are specific to the hash and
> known.
>
> So a very powerful defense is to just look for those bit patterns in
> the objects, and just warn about them. Those patterns don't tend to
> exist in normal inputs anyway, but particularly if you just warn, it's
> a heads-ups that "ok, something iffy is going on"
Yes, that would be a wonderful hardening to put into Git if we know what
those patterns look like. That part isn't clear to me.
> The whole _point_ of an SCM is that it isn't about a one-time event,
> but about continuous history. That also fundamentally means that a
> successful attack needs to work over time, and not be detectable.
Yeah, I'd certainly agree with that. You spend loads of money to
generate a collision, there's a reasonably high chance of detection, and
then as soon as one person detects it, your investment is lost.
According to the paper, the current cost of the computation for a single
collision is ~$670K.
At least for now, an attacker is much better off using that money to
break into your house and install a keylogger.
-Peff
^ permalink raw reply
* Re: SHA1 collisions found
From: Jeff King @ 2017-02-23 19:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <CA+55aFxmr6ntWGbJDa8tOyxXDX3H-yd4TQthgV_Tn1u91yyT8w@mail.gmail.com>
On Thu, Feb 23, 2017 at 11:47:16AM -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2017 at 11:32 AM, Jeff King <peff@peff.net> wrote:
> >
> > Yeah, they're not expensive. We've discussed enabling them by default.
> > The sticking point is that there is old history with minor bugs which
> > triggers some warnings (e.g., malformed committer names), and it would
> > be annoying to start rejecting that unconditionally.
> >
> > So I think we would need a good review of what is a "warning" versus an
> > "error", and to only reject on errors (right now the NUL thing is a
> > warning, and it should probably upgraded).
>
> I think even a warning (as opposed to failing the operation) is
> already a big deal.
>
> If people start saying "why do I get this odd warning", and start
> looking into it, that's going to be a pretty strong defense against
> bad behavior. SCM attacks depend on flying under the radar.
Sorry, I conflated two things there. I agree a warning is better than
nothing. But right now transfer.fsck croaks even for warnings, and there
are some warnings that it is not worth croaking for. So before we turn
it on, we need to stop croaking on warnings (and possibly bump up some
warnings to errors).
I think it _is_ important to have dangerous things as errors, though.
Because it helps an unattended server (where nobody would see the
warning) avoid being a vector for spreading malicious objects to older
clients which do not do the fsck.
> There's actually already code for that, pointed to by the shattered project:
>
> https://github.com/cr-marcstevens/sha1collisiondetection
>
> the "meat" of that check is in lib/ubc_check.c.
Thanks, I hadn't seen that yet. That doesn't look like it should be hard
to integrate into Git.
-Peff
^ permalink raw reply
* Re: SHA1 collisions found
From: Linus Torvalds @ 2017-02-23 19:47 UTC (permalink / raw)
To: Jeff King; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <20170223193210.munuqcjltwbrdy22@sigill.intra.peff.net>
On Thu, Feb 23, 2017 at 11:32 AM, Jeff King <peff@peff.net> wrote:
>
> Yeah, they're not expensive. We've discussed enabling them by default.
> The sticking point is that there is old history with minor bugs which
> triggers some warnings (e.g., malformed committer names), and it would
> be annoying to start rejecting that unconditionally.
>
> So I think we would need a good review of what is a "warning" versus an
> "error", and to only reject on errors (right now the NUL thing is a
> warning, and it should probably upgraded).
I think even a warning (as opposed to failing the operation) is
already a big deal.
If people start saying "why do I get this odd warning", and start
looking into it, that's going to be a pretty strong defense against
bad behavior. SCM attacks depend on flying under the radar.
>> So a very powerful defense is to just look for those bit patterns in
>> the objects, and just warn about them. Those patterns don't tend to
>> exist in normal inputs anyway, but particularly if you just warn, it's
>> a heads-ups that "ok, something iffy is going on"
>
> Yes, that would be a wonderful hardening to put into Git if we know what
> those patterns look like. That part isn't clear to me.
There's actually already code for that, pointed to by the shattered project:
https://github.com/cr-marcstevens/sha1collisiondetection
the "meat" of that check is in lib/ubc_check.c.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] http: add an "auto" mode for http.emptyauth
From: Jeff King @ 2017-02-23 19:44 UTC (permalink / raw)
To: David Turner
Cc: Junio C Hamano, git@vger.kernel.org, sandals@crustytoothpaste.net,
Johannes Schindelin, Eric Sunshine
In-Reply-To: <092a87cf9aa94d53aebf42facb75b985@exmbdft7.ad.twosigma.com>
On Thu, Feb 23, 2017 at 04:31:13PM +0000, David Turner wrote:
> > As somebody who is using non-Basic auth, can you apply these patches and
> > show us the output of:
> >
> > GIT_TRACE_CURL=1 \
> > git ls-remote https://your-server 2>&1 >/dev/null |
> > egrep '(Send|Recv) header: (GET|HTTP|Auth)'
> >
> > (without http.emptyauth turned on, obviously).
>
> The results appear to be identical with and without
> the patch. With http.emptyauth turned off,
> 16:27:28.208924 http.c:524 => Send header: GET /info/refs?service=git-upload-pack HTTP/1.1
> 16:27:28.212872 http.c:524 <= Recv header: HTTP/1.1 401 Authorization Required
> Username for 'http://git': [I just pressed enter]
> Password for 'http://git': [ditto]
> 16:27:29.928872 http.c:524 => Send header: GET /info/refs?service=git-upload-pack HTTP/1.1
> 16:27:29.929787 http.c:524 <= Recv header: HTTP/1.1 401 Authorization Required
Just to be sure: did you remove http.emptyauth config completely from
your config files, or did you turn it to "false"? Because the new
behavior only kicks in when it isn't configured at all (probably we
should respect "auto" as a user-provided name).
> (if someone else wants to replicate this, delete >/dev/null bit
> from Jeff's shell snippet)
Hrm, you shouldn't need to. The stderr redirection comes first, so it
should become the new stdout.
-Peff
^ permalink raw reply
* Re: [PATCH] http(s): automatically try NTLM authentication first
From: Jeff King @ 2017-02-23 19:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, David Turner, git@vger.kernel.org,
sandals@crustytoothpaste.net, Eric Sunshine
In-Reply-To: <alpine.DEB.2.20.1702231806340.3767@virtualbox>
On Thu, Feb 23, 2017 at 06:08:49PM +0100, Johannes Schindelin wrote:
> > I suspect the patch above could probably be generalized as:
> >
> > /* cut out methods we know the server doesn't support */
> > http_auth_methods &= results.auth_avail;
> >
> > and let curl figure it out from there.
>
> Maybe this patch (or a variation thereof) would also be able to fix this
> problem with the patch:
>
> https://github.com/git-for-windows/git/issues/1034
>
> Short version: for certain servers (that do *not* advertise Negotiate),
> setting emptyauth to true will result in a failed fetch, without letting
> the user type in their credentials.
I suspect it isn't enough to help without 2/2. This will tell curl that
the server does not do Negotiate, so it will skip the probe request. But
Git will still feed curl the bogus empty credential.
That's what 2/2 tries to fix: only kick in the emptyAuth hack when there
is something besides Basic[1] to try. The way it is written adds an
extra "auto" mode to emptyAuth, as I wanted to leave "emptyauth=true" as
a workaround in case the "auto" behavior does not work. And then I
turned on "auto" by default, since that was what the discussion was
shooting for.
But if we are worried about turning on emptyAuth everywhere, the auto
behavior could be tied to emptyauth=true (and have something like
"emptyauth=always" to _really_ force it). I don't have an opinion there.
It sounds like emptyauth has been enabled by default on Windows for a
while. It's not clear to me if that's a security problem or not.
-Peff
^ permalink raw reply
* Re: [PATCH] http(s): automatically try NTLM authentication first
From: Jeff King @ 2017-02-23 19:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, David Turner, git@vger.kernel.org,
Johannes Schindelin, Eric Sunshine
In-Reply-To: <xmqq1suo90za.fsf@gitster.mtv.corp.google.com>
On Thu, Feb 23, 2017 at 11:11:05AM -0800, Junio C Hamano wrote:
> >> As far as Kerberos, this is a desirable feature to have enabled, with
> >> little downside. I just don't know about the security of the NTLM part,
> >> and I don't think we should take this patch unless we're sure we know
> >> the consequences of it.
> >
> > Hmm. That would be a problem with my proposed patch 2 then, too, if only
> > because it turns the feature on by default in more places.
> >
> > If it _is_ dangerous to turn on all the time, I'd think we should
> > consider warning people in the http.emptyauth documentation.
>
> I presume that we have finished discussing the security
> ramification, and if I am not mistaken the conclusion was that it
> could leak information if we turned on emptyAuth unconditionally
> when talking to a wrong server, and that the documentation needs an
> update to recommend those who use emptyAuth because they want to
> talk to Negotiate servers to use the http.<site>.emptyAuth form,
> limited to such servers, not a more generic http.emptyAuth, to avoid
> information leakage?
I don't know enough to evaluate the claims of emptyAuth being dangerous
or not (nor do I use it myself or admin a server whose users need it).
So I will let interested parties hash out whether it is a good idea or
not, and I'm happy to drop my 2/2 for now.
If we are to make it more widely available, I would prefer something
more like my 2/2 than always turning on http.emptyAuth, if only because
it reduces the cost to people not using the feature. I'm happy to work
more on the patch if we decide to go that route.
> If that is the case, let's take your 1/2 in the near-by thread
> without 2/2 (auto-enable emptyAuth) for now, as Dscho seems to have
> a case that may be helped by it.
Yes, I think 1/2 stands on its own. Whether it helps Dscho's case or
not, it eliminates an HTTP round-trip for Basic-only servers, which I
think is worth it.
-Peff
^ permalink raw reply
* Fwd: Re: feature request: user email config per domain
From: Igor Djordjevic @ 2017-02-23 19:29 UTC (permalink / raw)
To: Tushar Kapila, git
In-Reply-To: <5e25e9d5-ca52-2b32-3701-4826599774ef@gmail.com>
Forwarding a message that ended on my end only, probably by accident.
-------- Forwarded Message --------
Subject: Re: feature request: user email config per domain
Date: Thu, 23 Feb 2017 13:32:56 +0530
From: Tushar Kapila <tgkprog@gmail.com>
To: Igor Djordjevic BugA <igor.d.djordjevic@gmail.com>
Hello All,
> I'd much rather see something based on the working tree path, like
Duy's conditional config includes. Then you write something in your
~/.gitconfig
> This would allow you to have two root directories, one for your work
projects and one for open source projects (for example).
I guess this can be extended for any number of root directories. Like,
when a consultant has multiple employer email ids.
This sounds great and it would enforce at commit time, which as
pointed out, is the correct time to do it. If for some reason it is
not adopted I at least hope that we have a simple global config which
specifies that user must set email for each repo and to ignore any
global config.
Am sure this can be done via hooks, but I would like something that is
really simple for newbies and companies to enforce with minimal
instruction.
* Will try what Igor and Grant Humphries suggests.
* Thank you all for your replies, and a big thank you for git - its a
great tool. I used to dream of something like it when I was stuck with
svn (pre 2010 I was introduced to git late.)
[1] http://stackoverflow.com/a/42354282
[2] http://stackoverflow.com/users/2167004
^ permalink raw reply
* Re: SHA1 collisions found
From: David Lang @ 2017-02-23 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <CAPc5daVZ79WWKSw76kxHgDra9a7fSR1AibZa_pvK9aUuuVawLQ@mail.gmail.com>
pointers to a little more info
https://shattered.it/static/
the two files are:
https://shattered.it/static/shattered-1.pdf
https://shattered.it/static/shattered-2.pdf
422435 shattered-2.pdf
422435 shattered-1.pdf
identical length and a lot smaller than I expected (~162K of the 413K file is
binary junk)
$ sha1sum shattered-*pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
$ sum shattered-*pdf
62721 413 shattered-1.pdf
41606 413 shattered-2.pdf
$ md5sum shattered-*pdf
ee4aa52b139d925f8d8884402b0a750c shattered-1.pdf
5bd9d8cabc46041579a311230539b8d1 shattered-2.pdf
David Lang
^ permalink raw reply
* usability bug: git-gui: keyboard shortcuts don't operate correctly on multi-file selections
From: peter fargas @ 2017-02-23 19:09 UTC (permalink / raw)
To: git
Ctrl+T/Ctrl+U add/remove only one file, not the whole selection - used
to work. Neither are access keys for menu underlined (Ease of access
center > underline keyboard shortcuts is on), so there is no way to
effectively work with keyb only.
git-gui verison 0.21 GITGUI
git version 2.11.1.windows.1
Tcl/Tk 8.6.6
64-bit installer
Windows 7 Professional
Originally posted at
https://github.com/git/git-scm.com/issues/939#issuecomment-276024341
peter.fargas @
informatik-handwerk.de
0176 / 458 67 358
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox