* What's cooking in git.git (Feb 2017, #08; Fri, 24)
From: Junio C Hamano @ 2017-02-24 19:29 UTC (permalink / raw)
To: git
What's cooking in git.git (Feb 2017, #08; Fri, 24)
--------------------------------------------------
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.
v2.12 has been tagged. Special thanks go to Dscho, who (among other
things) laid the groundwork for speeding up "rebase -i" (which I am
hoping to be finalized in the upcoming cycle) and rewrote "difftool"
in C and to Peff who was all over the place cleaning the code up,
fixing surfaced and unsurfaced bugs. Thanks for everybody else,
too, who worked hard on the release.
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"]
* 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.
* 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.
* 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.
* 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.
* ps/doc-gc-aggressive-depth-update (2017-02-24) 1 commit
(merged to 'next' on 2017-02-24 at f023322bbb)
+ docs/git-gc: fix default value for `--aggressiveDepth`
Doc update.
* 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.
--------------------------------------------------
[New Topics]
* dp/filter-branch-prune-empty (2017-02-23) 4 commits
- p7000: add test for filter-branch with --prune-empty
- filter-branch: fix --prune-empty on parentless commits
- t7003: ensure --prune-empty removes entire branch when applicable
- t7003: ensure --prune-empty can prune root commit
"git filter-branch --prune-empty" drops a single-parent commit that
becomes a no-op, but did not drop a root commit whose tree is empty.
Needs review.
* jc/config-case-cmdline-take-2 (2017-02-23) 2 commits
- config: use git_config_parse_key() in git_config_parse_parameter()
- config: move a few helper functions up
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 merge to and then cook in 'next'.
This supersedes jc/config-case-cmdline topic.
--------------------------------------------------
[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]
* 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>
* 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'.
* 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>
* 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 discard.
* 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-23) 15 commits
- builtin/checkout: add --recurse-submodules switch
- entry.c: update submodules when interesting
- read-cache, remove_marked_cache_entries: 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_move_head
- 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
* A note from the maintainer
From: Junio C Hamano @ 2017-02-24 19:29 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://public-inbox.org/git/
http://marc.info/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.public-inbox.org/inbox.comp.version-control.git
nntp://news.gmane.org/gmane.comp.version-control.git
are available.
When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:
http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel
There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).
Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>. This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:
- people triaging and fixing reported vulnerabilities
- people operating major git hosting sites with many users
- people packaging and distributing git to large numbers of people
where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.
* Repositories and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/cgit/git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:
https://git.github.io/htmldocs/git.html
* How various branches are used.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
The last such release was 2.12 done on Feb 24th, 2017. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it. Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues. The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release). These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.11.1"
was the first maintenance release for the "2.11" series).
New features never go to the 'maint' branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master". Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".
The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen. There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch. This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more. The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work. When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as
incremental patches, pointing out what was wrong in the previous
patches and how the problem was corrected.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".
* Other people's trees.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: add USE_SHA1DC knob
From: HW42 @ 2017-02-24 18:36 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Joey Hess, Git Mailing List
In-Reply-To: <20170223230621.43anex65ndoqbgnf@sigill.intra.peff.net>
[-- Attachment #1.1: Type: text/plain, Size: 1226 bytes --]
Jeff King:
> diff --git a/Makefile b/Makefile
> index 8e4081e06..7c4906250 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1386,6 +1390,11 @@ ifdef APPLE_COMMON_CRYPTO
> SHA1_MAX_BLOCK_SIZE = 1024L*1024L*1024L
> endif
>
> +ifdef USE_SHA1DC
> + SHA1_HEADER = "sha1dc/sha1.h"
> + LIB_OBJS += sha1dc/sha1.o
> + LIB_OBJS += sha1dc/ubc_check.o
> +else
> ifdef BLK_SHA1
> SHA1_HEADER = "block-sha1/sha1.h"
> LIB_OBJS += block-sha1/sha1.o
> @@ -1403,6 +1412,7 @@ else
> endif
> endif
> endif
> +endif
This sets SHA1_MAX_BLOCK_SIZE and the compiler flags for Apple
CommonCrypto even if the user selects USE_SHA1DC. The same happens for
BLK_SHA1. Is this intended?
> +void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *vdata, unsigned long len)
> +{
> + const char *data = vdata;
> + /* We expect an unsigned long, but sha1dc only takes an int */
> + while (len > INT_MAX) {
> + SHA1DCUpdate(ctx, data, INT_MAX);
> + data += INT_MAX;
> + len -= INT_MAX;
> + }
> + SHA1DCUpdate(ctx, data, len);
> +}
I think you can simply change the len parameter from unsigned into
size_t (or unsigned long) in SHA1DCUpdate().
https://github.com/cr-marcstevens/sha1collisiondetection/pull/6
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* Re: [PATCH 15/15] builtin/checkout: add --recurse-submodules switch
From: Stefan Beller @ 2017-02-24 19:20 UTC (permalink / raw)
To: Ramsay Jones
Cc: git@vger.kernel.org, brian m. carlson, Jonathan Nieder,
Brandon Williams, Junio C Hamano, David Turner
In-Reply-To: <db5cfde2-a769-d786-8846-a5a526194b69@ramsayjones.plus.com>
On Thu, Feb 23, 2017 at 5:25 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>> +int option_parse_recurse_submodules(const struct option *opt,
>> + const char *arg, int unset)
>
> Again, this function should be marked static.
>
> [I also noted _two_ other local functions with the same name
> in builtin/fetch.c and builtin/push.c]
fixed in a reroll.
Yes there is a pattern here. But as both fetch and push accept different
options (not just boolean, but strings) these have to be different.
I thought about unifying them, but I do not think we can do so easily.
Thanks,
Stefan
^ permalink raw reply
* Re: SHA1 collisions found
From: Junio C Hamano @ 2017-02-24 19:20 UTC (permalink / raw)
To: Stefan Beller; +Cc: David Lang, Ian Jackson, Joey Hess, git@vger.kernel.org
In-Reply-To: <CAGZ79kaZWe-8pMZnQv7uZtr8wXWawFeJjUa68-b0oa4yFo-HcA@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> you are inviting people to start using
>>
>> md5,54ddf8d47340e048166c45f439ce65fd
>>
>> as object names.
>
> which might even be okay for specific subsets of operations.
> (e.g. all local work including staging things, making local "fixup" commits)
>
> The addressing scheme should not be too hardcoded, we should rather
> treat it similar to the cipher schemes in pgp. The additional complexity that
> we have is the longevity of existence of things, though.
The not-so-well-hidden agenda was exactly that we _SHOULD_ not
mimick PGP. They do not have a requirement to encourage everybody
to use the same thing because each message is encrypted/signed
independently, i.e. they do not have to chain things like we do.
^ permalink raw reply
* Re: [PATCH 10/15] update submodules: add submodule_move_head
From: Stefan Beller @ 2017-02-24 19:08 UTC (permalink / raw)
To: Ramsay Jones
Cc: git@vger.kernel.org, brian m. carlson, Jonathan Nieder,
Brandon Williams, Junio C Hamano, David Turner
In-Reply-To: <7e920dd5-3638-57d9-0ca1-3f8aed4d700b@ramsayjones.plus.com>
On Thu, Feb 23, 2017 at 5:21 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>
>
> On 23/02/17 22:57, Stefan Beller wrote:
>> In later patches we introduce the options and flag for commands
>> that modify the working directory, e.g. git-checkout.
>>
>> This piece of code will be used universally for
>> all these working tree modifications as it
>> * supports dry run to answer the question:
>> "Is it safe to change the submodule to this new state?"
>> e.g. is it overwriting untracked files or are there local
>> changes that would be overwritten?
>> * supports a force flag that can be used for resetting
>> the tree.
>>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>> submodule.c | 135 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> submodule.h | 7 ++++
>> 2 files changed, 142 insertions(+)
>>
>> diff --git a/submodule.c b/submodule.c
>> index 0b2596e88a..a2cf8c9376 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -1239,6 +1239,141 @@ int bad_to_remove_submodule(const char *path, unsigned flags)
>> return ret;
>> }
>>
>> +static int submodule_has_dirty_index(const struct submodule *sub)
>> +{
>> + struct child_process cp = CHILD_PROCESS_INIT;
>> +
>> + prepare_submodule_repo_env_no_git_dir(&cp.env_array);
>> +
>> + cp.git_cmd = 1;
>> + argv_array_pushl(&cp.args, "diff-index", "--quiet", \
>> + "--cached", "HEAD", NULL);
>> + cp.no_stdin = 1;
>> + cp.no_stdout = 1;
>> + cp.dir = sub->path;
>> + if (start_command(&cp))
>> + die("could not recurse into submodule '%s'", sub->path);
>> +
>> + return finish_command(&cp);
>> +}
>> +
>> +void submodule_reset_index(const char *path)
>
> I was just about to send a patch against the previous series
> (in pu branch last night), but since you have sent another
> version ...
>
> In the last series this was called 'submodule_clean_index()'
> and, since it is a file-local symbol, should be marked with
> static. I haven't applied these patches to check, but the
> interdiff in the cover letter leads me to believe that this
> will also apply to the renamed function.
>
> [The patch subject was also slightly different.]
>
good catch. Yes submodule_reset_index
ought to be static.
fixed in a reroll.
^ permalink raw reply
* Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)
From: Jeff King @ 2017-02-24 18:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg KH, Linus Torvalds, Simon Sandström, Andrew Morton,
Git Mailing List, Linux Kernel Mailing List, Linux Driver Project
In-Reply-To: <CAMuHMdX+xGUD+K16VCE=ywRgN1Zd4MzSr=NJ=2xz+8e_ixyGKQ@mail.gmail.com>
On Fri, Feb 24, 2017 at 12:03:45PM +0100, Geert Uytterhoeven wrote:
> > The problem isn't on the applying end, but rather on the generating end.
> > The From header in the attached mbox is:
> >
> > From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?= <simon@nikanor.nu>
>
> Slightly related, once in a while I get funny emails through
> git-commits-head@vger.kernel.org, where the subject is completely screwed up:
>
> Subject: \x64\x72\x6D\x2F\x74\x69\x6E\x79\x64\x72\x6D\x3A
> \x6D\x69\x70\x69\x2D\x64\x62\x69\x3A \x53\x69\x6C\x65\x6E\x63\x65\x3A
> ‘\x63\x6D\x64’ \x6D\x61\x79 \x62\x65
Sorry, I don't have a clue on that one.
If you have UTF-8 or other non-ASCII characters in your subject,
format-patch will correctly do the rfc2047 encoding (and it should
always use QP). And that would kick in here because of the UTF-8 quotes.
But that weird "\x" encoding is not in any mail standard I know of (and
certainly Git would never do it).
The odd thing is that the quotes themselves _aren't_ encoded. Just
everything else.
One other feature is that subject line is long enough (especially
QP-encoded) that it spans two lines:
$ git format-patch --stdout -1 b401f34314d | grep -A1 ^Subject
Subject: [PATCH] =?UTF-8?q?drm/tinydrm:=20mipi-dbi:=20Silence:=20=E2=80=98?=
=?UTF-8?q?cmd=E2=80=99=20may=20be=20used=20uninitialized?=
It's possible that something along the way is mis-handling subjects with
line-continuation (though why it would escape those characters, I don't
know).
> and some of the mail headers end up in the body as well:
>
> =?UTF-8?Q?\x75\x73\x65\x64_\x75\x6E\x69\x6E\x69\x74\x69\x61\x6C\x69\x7A\x65\x64?=
That might be related to the whitespace continuation (the first line
after the break is the second line of the subject).
-Peff
^ permalink raw reply
* Re: SHA1 collisions found
From: Stefan Beller @ 2017-02-24 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Lang, Ian Jackson, Joey Hess, git@vger.kernel.org
In-Reply-To: <xmqqk28f4fti.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> you are inviting people to start using
>
> md5,54ddf8d47340e048166c45f439ce65fd
>
> as object names.
which might even be okay for specific subsets of operations.
(e.g. all local work including staging things, making local "fixup" commits)
The addressing scheme should not be too hardcoded, we should rather
treat it similar to the cipher schemes in pgp. The additional complexity that
we have is the longevity of existence of things, though.
^ permalink raw reply
* Re: [PATCH 3/3] Makefile: add USE_SHA1DC knob
From: Jeff King @ 2017-02-24 18:57 UTC (permalink / raw)
To: HW42; +Cc: Linus Torvalds, Joey Hess, Git Mailing List
In-Reply-To: <16c6d843-a516-9265-d3e7-61b110acbdcf@ipsumj.de>
On Fri, Feb 24, 2017 at 06:36:00PM +0000, HW42 wrote:
> > +ifdef USE_SHA1DC
> > + SHA1_HEADER = "sha1dc/sha1.h"
> > + LIB_OBJS += sha1dc/sha1.o
> > + LIB_OBJS += sha1dc/ubc_check.o
> > +else
> > ifdef BLK_SHA1
> > SHA1_HEADER = "block-sha1/sha1.h"
> > LIB_OBJS += block-sha1/sha1.o
> > @@ -1403,6 +1412,7 @@ else
> > endif
> > endif
> > endif
> > +endif
>
> This sets SHA1_MAX_BLOCK_SIZE and the compiler flags for Apple
> CommonCrypto even if the user selects USE_SHA1DC. The same happens for
> BLK_SHA1. Is this intended?
No, it's not. I suspect that setting BLK_SHA1 has the same problem in
the current code, then.
> > +void git_SHA1DCUpdate(SHA1_CTX *ctx, const void *vdata, unsigned long len)
> > +{
> > + const char *data = vdata;
> > + /* We expect an unsigned long, but sha1dc only takes an int */
> > + while (len > INT_MAX) {
> > + SHA1DCUpdate(ctx, data, INT_MAX);
> > + data += INT_MAX;
> > + len -= INT_MAX;
> > + }
> > + SHA1DCUpdate(ctx, data, len);
> > +}
>
> I think you can simply change the len parameter from unsigned into
> size_t (or unsigned long) in SHA1DCUpdate().
> https://github.com/cr-marcstevens/sha1collisiondetection/pull/6
Yeah, I agree that is a cleaner solution. My focus was on changing the
(presumably tested) sha1dc code as little as possible.
-Peff
^ permalink raw reply
* Re: [PATCH v6 1/1] config: add conditional include
From: Junio C Hamano @ 2017-02-24 18:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jeff King, sschuberth, Matthieu Moy
In-Reply-To: <20170224131425.32409-2-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +Conditional includes
> +~~~~~~~~~~~~~~~~~~~~
> +
> +You can include one config file from another conditionally by setting
> +a `includeIf.<condition>.path` variable to the name of the file to be
> +included. The variable's value is treated the same way as `include.path`.
> +
> +The condition starts with a keyword followed by a colon and some data
> +whose format and meaning depends on the keyword. Supported keywords
> +are:
> +
> +`gitdir`::
> +
> + The data that follows the keyword `gitdir:` is used as a glob
> + pattern. If the location of the .git directory match the
> + pattern, the include condition is met.
s/match/&es/, I think.
> ++
> +The .git location which may be auto-discovered, or come from
s/ which//?
> +`$GIT_DIR` environment variable. If the repository auto discovered via
s/If the /In a/?
> +a .git file (e.g. from submodules, or a linked worktree), the .git
> +location would be the final location, not where the .git file is.
OK.
> @@ -170,9 +171,99 @@ static int handle_path_include(const char *path, struct config_include_data *inc
> return ret;
> }
>
> +static int prepare_include_condition_pattern(struct strbuf *pat)
> +{
> + ...
> + /* TODO: escape wildcards */
> + strbuf_add_absolute_path(&path, cf->path);
Is this still TODO? As this one returns the prefix length (which
probably wants to be commented before the function) and this codepath
computes the prefix to cover the path to here, doesn't caller already
do the right thing?
> +static int include_condition_is_true(const char *cond, size_t cond_len)
> +{
> + /* no condition (i.e., "include.path") is always true */
Does this want to say "includeIf.path" instead? "include.path" is
done by handle_path_include() without involving a call to this
function.
> + 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);
> +
> + error(_("unrecognized include condition: %.*s"), (int)cond_len, cond);
> + /* unknown conditionals are always false */
> + return 0;
> +}
Thanks.
^ permalink raw reply
* [PATCH] submodule init: warn about falling back to a local path
From: Stefan Beller @ 2017-02-24 18:22 UTC (permalink / raw)
To: j6t; +Cc: git, philipoakley, gitster, sop, Stefan Beller
In-Reply-To: <ae377bda-0776-f98b-5b6f-afa198647400@kdbg.org>
When a submodule is initialized, the config variable 'submodule.<name>.url'
is set depending on the value of the same variable in the .gitmodules
file. When the URL indicates to be relative, then the url is computed
relative to its default remote. The default remote cannot be determined
accurately in all cases, such that it falls back to 'origin'.
The 'origin' remote may not exist, though. In that case we give up looking
for a suitable remote and we'll just assume it to be a local relative path.
This can be confusing to users as there is a lot of guessing involved,
which is not obvious to the user.
So in the corner case of assuming a local autoritative truth, warn the
user to lessen the confusion.
This behavior was introduced in 4d6893200 (submodule add: allow relative
repository path even when no url is set, 2011-06-06), which shared the
code with submodule-init and then ported to C in 3604242f080a (submodule:
port init from shell to C, 2016-04-15).
In case of submodule-add, this behavior makes sense in some use cases[1],
however for submodule-init there does not seem to be an immediate obvious
use case to fall back to a local submodule. However there might be, so
warn instead of die here.
While adding the warning, also clarify the behavior of relative URLs in
the documentation.
[1] e.g. http://stackoverflow.com/questions/8721984/git-ignore-files-for-public-repository-but-not-for-private
"store a secret locally in a submodule, with no intention to publish it"
Reported-by: Shawn Pearce <spearce@spearce.org>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
* reworded sentence to not omit half of it.
* tested rendering to be correct
* warn before xgetcwd
Thanks,
Stefan
Documentation/git-submodule.txt | 36 ++++++++++++++++++++++--------------
builtin/submodule--helper.c | 8 +++-----
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 8acc72ebb8..b810d37aa2 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -73,13 +73,17 @@ configuration entries unless `--name` is used to specify a logical name.
+
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
-or ../), the location relative to the superproject's origin
+or ../), the location relative to the superproject's default remote
repository (Please note that to specify a repository 'foo.git'
which is located right next to a superproject 'bar.git', you'll
have to use '../foo.git' instead of './foo.git' - as one might expect
when following the rules for relative URLs - because the evaluation
of relative URLs in Git is identical to that of relative directories).
-If the superproject doesn't have an origin configured
++
+The default remote is the remote of the remote tracking branch
+of the current branch. If no such remote tracking branch exists or
+the HEAD is detached, "origin" is assumed to be the default remote.
+If the superproject doesn't have a default remote configured
the superproject is its own authoritative upstream and the current
working directory is used instead.
+
@@ -118,18 +122,22 @@ too (and can also report changes to a submodule's work tree).
init [--] [<path>...]::
Initialize the submodules recorded in the index (which were
- added and committed elsewhere) by copying submodule
- names and urls from .gitmodules to .git/config.
- Optional <path> arguments limit which submodules will be initialized.
- It will also copy the value of `submodule.$name.update` into
- .git/config.
- The key used in .git/config is `submodule.$name.url`.
- This command does not alter existing information in .git/config.
- You can then customize the submodule clone URLs in .git/config
- for your local setup and proceed to `git submodule update`;
- you can also just use `git submodule update --init` without
- the explicit 'init' step if you do not intend to customize
- any submodule locations.
+ added and committed elsewhere) by copying `submodule.$name.url`
+ from .gitmodules to .git/config, resolving relative urls to be
+ relative to the default remote.
++
+Optional <path> arguments limit which submodules will be initialized.
+If no path is specified all submodules are initialized.
++
+When present, it will also copy the value of `submodule.$name.update`.
+This command does not alter existing information in .git/config.
+You can then customize the submodule clone URLs in .git/config
+for your local setup and proceed to `git submodule update`;
+you can also just use `git submodule update --init` without
+the explicit 'init' step if you do not intend to customize
+any submodule locations.
++
+See the add subcommand for the defintion of default remote.
deinit [-f|--force] (--all|[--] <path>...)::
Unregister the given submodules, i.e. remove the whole
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 899dc334e3..15a5430c00 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -356,12 +356,10 @@ static void init_submodule(const char *path, const char *prefix, int quiet)
strbuf_addf(&remotesb, "remote.%s.url", remote);
free(remote);
- if (git_config_get_string(remotesb.buf, &remoteurl))
- /*
- * The repository is its own
- * authoritative upstream
- */
+ if (git_config_get_string(remotesb.buf, &remoteurl)) {
+ warning(_("could not lookup configuration '%s'. Assuming this repository is its own authoritative upstream."), remotesb.buf);
remoteurl = xgetcwd();
+ }
relurl = relative_url(remoteurl, url, NULL);
strbuf_release(&remotesb);
free(remoteurl);
--
2.12.0.rc1.16.ge4278d41a0.dirty
^ permalink raw reply related
* Re: SHA1 collisions found
From: Junio C Hamano @ 2017-02-24 18:14 UTC (permalink / raw)
To: David Lang; +Cc: Ian Jackson, Joey Hess, git
In-Reply-To: <nycvar.QRO.7.75.62.1702240943540.6590@qynat-yncgbc>
David Lang <david@lang.hm> writes:
> On Fri, 24 Feb 2017, Junio C Hamano wrote:
>
>> *1* In the above toy example, length being 40 vs 64 is used as a
>> sign between SHA-1 and the new hash, and careful readers may
>> wonder if we should use sha-3,20769079d22... or something like
>> that that more explicity identifies what hash is used, so that
>> we can pick a hash whose length is 64 when we transition again.
>>
>> I personally do not think such a prefix is necessary during the
>> first transition; we will likely to adopt a new hash again, and
>> at that point that third one can have a prefix to differenciate
>> it from the second one.
>
> as the saying goes "in computer science the interesting numbers are 0,
> 1, and many", does it really simplify things much to support 2 hashes
> vs supporting more so that this issue doesn't have to be revisited?
> (other than selecting new hashes over time)
It seems that I wasn't clear enough, perhaps? The scheme I outlined
does not have to revisit this issue at all. It already declares what
you need to do when you add the third one.
If it is not 40 or 64 bytes long, you just write it out. If it is
one of these length, then you add some identifying prefix or
postfix. IOW, if the second one is sha-3 and the third one is blake
(both used at 256-bit), then we would have three kinds of names,
written like so:
20769079d22a9f8010232bdf6131918c33a1bf69
20769079d22a9f8010232bdf6131918c33a1bf6910232bdf6131918c33a1bf69
3,20769079d22a9f8010232bdf6131918c33a1bf6910232bdf6131918c33a1bf69
and the readers can well tell that the first one, being 40-chars
long, is SHA-1, the second one, being 64-chars long, is SHA-3, and
the last one, with the prefix '3' (only because that is the third
one officially supported by Git) and being 64-chars long, is blake,
for example.
I do not particularly care if it is prefix or postfix or something
else. A not-so-well-hidden agenda is to avoid inviting people into
thinking that they can use their choice of random hash functions and
and claim that their hacked version is still a Git, as long as they
follow the object naming convention. IOW, if you said something
like:
* 40-hex is SHA-1 for historical reasons;
* Others use hash-name, colon, and then N-hex.
you are inviting people to start using
md5,54ddf8d47340e048166c45f439ce65fd
as object names.
^ permalink raw reply
* Re: [GIT PULL] l10n updates for 2.12.0
From: Junio C Hamano @ 2017-02-24 17:57 UTC (permalink / raw)
To: Jiang Xin
Cc: Alexander Shopov, Jordi Mas, Ralf Thielow, Jean-Noël Avila,
Marco Paolone, Changwoo Ryu, Vasco Almeida, Dimitriy Ryazantcev,
Peter Krefting, Trần Ngọc Quân, Git List
In-Reply-To: <CANYiYbHPahB6CAUMWTRL19SfG2eYqEq7vqH8SzAPjUSV_qiNiw@mail.gmail.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> Hi Junio,
>
> Please pull l10n updates for Git 2.12.0:
>
> The following changes since commit 076c05393a047247ea723896289b48d6549ed7d0:
>
> Hopefully the final batch of mini-topics before the final
> (2017-02-16 14:46:35 -0800)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po tags/l10n-2.12.0-rnd2
>
> for you to fetch changes up to 1a79b2f1795a6ec4c70674ce930843aa59bff859:
>
> l10n: zh_CN: for git v2.12.0 l10n round 2 (2017-02-25 00:19:14 +0800)
Will pull. Thanks, all.
^ permalink raw reply
* Re: [PATCH v5 1/1] config: add conditional include
From: Junio C Hamano @ 2017-02-24 17:46 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Jeff King, Sebastian Schuberth, Matthieu Moy
In-Reply-To: <CACsJy8CerU-=PF6wqzUAM02jkrVVGJ5MA0NgL6z9bHn5KM6jiw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>>> + 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.
>
> Yeah I don't see a third include coming soon and did not go with that.
> Let's way for it and refactor then.
I would have said exactly that in my message if you already had
include_by_gitdir() and include_by_gitdir_i() as separate functions.
But I didn't, because the above code gives an excuse to the person
who adds the third one to be lazy and add another "else if" for
expediency, because making it table-driven would require an extra
work to add two wrapper functions that do not have anything to do
with the third one being added.
^ permalink raw reply
* Re: fatal error when diffing changed symlinks
From: Junio C Hamano @ 2017-02-24 17:53 UTC (permalink / raw)
To: Christophe Macabiau; +Cc: git, Johannes Schindelin
In-Reply-To: <CAC0icTZ87yeYndPFyjD4nkJBcw5SC-bgUJYbEzYqH7YhSFZvuQ@mail.gmail.com>
Christophe Macabiau <christophemacabiau@gmail.com> writes:
> with the commands below, you will get :
>
>> fatal: bad object 0000000000000000000000000000000000000000
>> show 0000000000000000000000000000000000000000: command returned error: 128
>>
>
> I am using version 2.5.5 fedora 23
>
> cd /tmp
> mkdir a
> cd a
> git init
> touch b
> ln -s b c
> git add .
> git commit -m 'first'
> touch d
> rm c
> ln -s d c
> git difftool --dir-diff
A slightly worse is that the upcoming Git will ship with a rewritten
"difftool" that makes the above sequence segfault. As either way is
bad, I do not particularly think the rewritten one needs to be
reverted (it would give "fatal: bad object" then, and would not fix
your problem), but it needs to be looked at.
Thanks for a report.
^ permalink raw reply
* Re: SHA1 collisions found
From: David Lang @ 2017-02-24 17:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ian Jackson, Joey Hess, git
In-Reply-To: <xmqq60jz5wbm.fsf@gitster.mtv.corp.google.com>
On Fri, 24 Feb 2017, Junio C Hamano wrote:
> *1* In the above toy example, length being 40 vs 64 is used as a
> sign between SHA-1 and the new hash, and careful readers may
> wonder if we should use sha-3,20769079d22... or something like
> that that more explicity identifies what hash is used, so that
> we can pick a hash whose length is 64 when we transition again.
>
> I personally do not think such a prefix is necessary during the
> first transition; we will likely to adopt a new hash again, and
> at that point that third one can have a prefix to differenciate
> it from the second one.
as the saying goes "in computer science the interesting numbers are 0, 1, and
many", does it really simplify things much to support 2 hashes vs supporting
more so that this issue doesn't have to be revisited? (other than selecting new
hashes over time)
David Lang
^ permalink raw reply
* Re: [PATCH] docs/git-gc: fix default value for `--aggressiveDepth`
From: Junio C Hamano @ 2017-02-24 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
In-Reply-To: <20170224090035.ju7evvro7mixc52w@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 24, 2017 at 09:46:45AM +0100, Patrick Steinhardt wrote:
>
>> In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11),
>> the default aggressive depth of git-gc has been changed to 50. While
>> git-config(1) has been updated to represent the new default value,
>> git-gc(1) still mentions the old value. This patch fixes it.
>
> Thanks, this is obviously an improvement.
>
> (I also grepped for "250" in Documentation; the results are thankfully
> short, and the only other mentions I saw were referring to the window
> size).
Thanks, both. Will queue.
^ permalink raw reply
* Re: SHA1 collisions found
From: Jason Cooper @ 2017-02-24 17:23 UTC (permalink / raw)
To: Ian Jackson; +Cc: Joey Hess, git
In-Reply-To: <22704.19873.860148.22472@chiark.greenend.org.uk>
Hi Ian,
On Fri, Feb 24, 2017 at 03:13:37PM +0000, Ian Jackson wrote:
> Joey Hess writes ("SHA1 collisions found"):
> > https://shattered.io/static/shattered.pdf
> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
> >
> > IIRC someone has been working on parameterizing git's SHA1 assumptions
> > so a repository could eventually use a more secure hash. How far has
> > that gotten? There are still many "40" constants in git.git HEAD.
>
> I have been thinking about how to do a transition from SHA1 to another
> hash function.
>
> I have concluded that:
>
> * We can should avoid expecting everyone to rewrite all their
> history.
Agreed.
> * Unfortunately, because the data formats (particularly, the commit
> header) are not in practice extensible (because of the way existing
> code parses them), it is not useful to try generate new data (new
> commits etc.) containing both new hashes and old hashes: old
> clients will mishandle the new data.
My thought here is:
a) re-hash blobs with sha256, hardlink to sha1 objects
b) create new tree objects which are mirrors of each sha1 tree object,
but purely sha256
c) mirror commits, but they are also purely sha256
d) future PGP signed tags would sign both hashes (or include both?)
Which would end up something like:
.git/
\... #usual files
\objects
\ef
\3c39f7522dc55a24f64da9febcfac71e984366
\objects-sha2_256
\72
\604fd2de5f25c89d692b01081af93bcf00d2af34549d8d1bdeb68bc048932
\info
\...
\info-sha2_256
\refs #uses sha256 commit identifiers
Basically, keep the sha256 stuff out of the way for legacy clients, and
new clients will still be able to use it.
There shouldn't be a need to re-sign old signed tags if the underlying
objects are counter-hashed. There might need to be some transition
info, though.
Say a new client does 'git tag -v tags/v3.16' in the kernel tree. I would
expect it to check the sha1 hashes, verify the PGP signed tag, and then
also check the sha256 counter-hashes of the relevant objects.
thx,
Jason.
^ permalink raw reply
* [PATCH] travis-ci: run scan-build every time
From: Samuel Lijin @ 2017-02-24 17:29 UTC (permalink / raw)
To: git@vger.kernel.org
Introduces the scan-build static code analysis tool from the Clang
project to all Travis CI builds. Installs clang (since scan-build
needs clang as a dependency) to make this possible (on macOS, also
updates PATH to allow scan-build to be invoked without referencing the
full path).
---
A build with this patch can be found at [1]. Note that if reports *are*
generated, this doesn't allow us to access them, and if we dumped
the reports as build artifacts, I'm not sure where we would want to
dump them to.
It's worth noting that there seems to be a weird issue with scan-build
where it *will* generate a report for something locally, but won't do it
on Travis. See [2] for an example where I have a C program with a
very obvious memory leak but scan-build on Travis doesn't generate
a report (despite complaining about it in stdout), even though it does
on my local machine.
[1] https://travis-ci.org/sxlijin/git/builds/204853233
[2] https://travis-ci.org/sxlijin/travis-testing/jobs/205025319#L331-L342
.travis.yml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 9c63c8c3f..1038b1b3d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -20,6 +20,7 @@ addons:
- language-pack-is
- git-svn
- apache2
+ - clang
env:
global:
@@ -78,9 +79,8 @@ before_install:
brew update --quiet
# Uncomment this if you want to run perf tests:
# brew install gnu-time
- brew install git-lfs gettext
- brew link --force gettext
- brew install caskroom/cask/perforce
+ brew install git-lfs gettext caskroom/cask/perforce llvm
+ brew link --force gettext llvm
;;
esac;
echo "$(tput setaf 6)Perforce Server Version$(tput sgr0)";
@@ -92,9 +92,9 @@ before_install:
mkdir -p $HOME/travis-cache;
ln -s $HOME/travis-cache/.prove t/.prove;
-before_script: make --jobs=2
+before_script: scan-build make --jobs=2
-script: make --quiet test
+script: scan-build make --quiet test
after_failure:
- >
--
2.11.1
^ permalink raw reply related
* Re: SHA1 collisions found
From: Junio C Hamano @ 2017-02-24 17:32 UTC (permalink / raw)
To: Ian Jackson; +Cc: Joey Hess, git
In-Reply-To: <22704.19873.860148.22472@chiark.greenend.org.uk>
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> I have been thinking about how to do a transition from SHA1 to another
> hash function.
Good. I think many of us have also been, too, not necessarily just
in the past few days in response to shattered, but over the last 10
years, yet without coming to a consensus design ;-)
> I have concluded that:
>
> * We can should avoid expecting everyone to rewrite all their
> history.
Yes.
> * Unfortunately, because the data formats (particularly, the commit
> header) are not in practice extensible (because of the way existing
> code parses them), it is not useful to try generate new data (new
> commits etc.) containing both new hashes and old hashes: old
> clients will mishandle the new data.
Yes.
> * Therefore the transition needs to be done by giving every object
> two names (old and new hash function). Objects may refer to each
> other by either name, but must pick one. The usual shape of
I do not think it is necessrily so. Existing code may not be able
to read anything new, but you can make the new code understand
object names in both formats, and for a smooth transition, I think
the new code needs to.
For example, a new commit that records a merge of an old and a new
commit whose resulting tree happens to be the same as the tree of
the old commit may begin like so:
tree 21b97d4c4f968d1335f16292f954dfdbb91353f0
parent 20769079d22a9f8010232bdf6131918c33a1bf6910232bdf6131918c33a1bf69
parent 22af6fef9b6538c9e87e147a920be9509acf1ddd
naming the only object whose name was done with new hash with the
new longer hash, while recording the names of the other existing
objects with SHA-1. We would need to extend the object format for
tag (which would be trivial as the object reference is textual and
similar to a commit) and tree (much harder), of course.
As long as the reader can tell from the format of object names
stored in the "new object format" object from what era is being
referred to in some way [*1*], we can name new objects with only new
hash, I would think. "new refers only to new" that stratifies
objects into older and newer may make things simpler, but I am not
convinced yet that it would give our users a smooth enough
transition path (but I am open to be educated and pursuaded the
other way).
[Footnote]
*1* In the above toy example, length being 40 vs 64 is used as a
sign between SHA-1 and the new hash, and careful readers may
wonder if we should use sha-3,20769079d22... or something like
that that more explicity identifies what hash is used, so that
we can pick a hash whose length is 64 when we transition again.
I personally do not think such a prefix is necessary during the
first transition; we will likely to adopt a new hash again, and
at that point that third one can have a prefix to differenciate
it from the second one.
^ permalink raw reply
* Re: SHA1 collisions found
From: ankostis @ 2017-02-24 17:04 UTC (permalink / raw)
To: Ian Jackson; +Cc: git
In-Reply-To: <22704.19873.860148.22472@chiark.greenend.org.uk>
On 24 February 2017 at 16:13, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
>
> Joey Hess writes ("SHA1 collisions found"):
> > https://shattered.io/static/shattered.pdf
> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
> >
> > IIRC someone has been working on parameterizing git's SHA1 assumptions
> > so a repository could eventually use a more secure hash. How far has
> > that gotten? There are still many "40" constants in git.git HEAD.
>
> I have been thinking about how to do a transition from SHA1 to another
> hash function.
>
> I have concluded that:
>
> * We can should avoid expecting everyone to rewrite all their
> history.
>
> * Unfortunately, because the data formats (particularly, the commit
> header) are not in practice extensible (because of the way existing
> code parses them), it is not useful to try generate new data (new
> commits etc.) containing both new hashes and old hashes: old
> clients will mishandle the new data.
>
> * Therefore the transition needs to be done by giving every object
> two names (old and new hash function). Objects may refer to each
> other by either name, but must pick one. The usual shape of
> project histories will be a pile of old commits referring to each
> other by old names, surmounted by new commits referrring to each
> other by new names.
>
> * It is not possible to solve this problem without extending the
> object name format. Therefore all software which calls git and
> expects to handle object names will need to be updated.
>
> I have been writing a more detailed transition plan. I hope to post
> this within a few days.
It would be great to have a rough plan of the transition to a new hash
function.
We are writing a git-based application to store electronic-files for
legislative purposes for EU.
And one of the great questions we face is about git's SHA-1 validity in 5
or 20 years of time from now.
Is it possible to have an assessment of the situation for this transition?
Best regards for your efforts,
Kostis
^ permalink raw reply
* Re: git bugs
From: Johannes Schindelin @ 2017-02-24 16:52 UTC (permalink / raw)
To: Sean Hunt; +Cc: git
In-Reply-To: <CAHikyLoK-h4tY_rxGikaSSv6AmcrBAXiayDFTtLa44A9qMZDqA@mail.gmail.com>
Hi,
On Thu, 23 Feb 2017, Sean Hunt wrote:
> 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.
It appears this was reported as
https://github.com/git-for-windows/git/issues/1072, too.
I asked for clarification there, as I am quite confused by the
description.
Ciao,
Johannes
^ permalink raw reply
* [GIT PULL] l10n updates for 2.12.0
From: Jiang Xin @ 2017-02-24 16:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alexander Shopov, Jordi Mas, Ralf Thielow, Jean-Noël Avila,
Marco Paolone, Changwoo Ryu, Vasco Almeida, Dimitriy Ryazantcev,
Peter Krefting, Trần Ngọc Quân, Jiang Xin,
Git List
Hi Junio,
Please pull l10n updates for Git 2.12.0:
The following changes since commit 076c05393a047247ea723896289b48d6549ed7d0:
Hopefully the final batch of mini-topics before the final
(2017-02-16 14:46:35 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.12.0-rnd2
for you to fetch changes up to 1a79b2f1795a6ec4c70674ce930843aa59bff859:
l10n: zh_CN: for git v2.12.0 l10n round 2 (2017-02-25 00:19:14 +0800)
----------------------------------------------------------------
l10n-2.12.0-rnd2
----------------------------------------------------------------
Alexander Shopov (1):
l10n: bg: Updated Bulgarian translation (2913t+0f+0u)
Anthony Ramine (1):
l10n: fr.po: Fix a typo in the French translation
Changwoo Ryu (2):
l10n: ko.po: Update Korean translation
l10n: ko.po: Update Korean translation
Jean-Noel Avila (2):
l10n: fr.po: v2.11-rc0 first round
l10n: fr.po: v2.12.0 round 2 3139t
Jiang Xin (14):
Merge branch 'master' of https://github.com/Softcatala/git-po
Merge branch 'master' of https://github.com/Softcatala/git-po
Merge branch 'master' of git://github.com/git-l10n/git-po
l10n: git.pot: v2.12.0 round 1 (239 new, 15 removed)
Merge branch 'fr_v2.11.0_rnd1' of git://github.com/jnavila/git
Merge branch 'master' of git://github.com/nafmo/git-l10n-sv
Merge branch 'master' of https://github.com/Softcatala/git-po
Merge branch 'master' of https://github.com/vnwildman/git
Merge branch 'master' of git://github.com/git-l10n/git-po
l10n: git.pot: v2.12.0 round 2 (2 new)
Merge branch 'master' of https://github.com/vnwildman/git
Merge branch 'ko/merge-l10n' of https://github.com/changwoo/git-l10n-ko
Merge branch 'master' of git://github.com/nafmo/git-l10n-sv
l10n: zh_CN: for git v2.12.0 l10n round 2
Joachim Jablon (2):
l10n: fr.po: Fix typos
l10n: fr.po: Remove gender specific adjectives
Jordi Mas (4):
l10n: New Catalan translation maintainer
l10n: fixes to Catalan translation
l10n: update Catalan translation
l10n: Update Catalan translation
Peter Krefting (2):
l10n: sv.po: Update Swedish translation (3137t0f0u)
l10n: sv.po: Update Swedish translation (3139t0f0u)
Ralf Thielow (1):
l10n: de.po: translate 241 messages
Ray Chen (1):
l10n: zh_CN: review for git v2.11.0 l10n
Trần Ngọc Quân (2):
l10n: vi.po: Updated Vietnamese translation (3137t)
l10n: vi.po (3139t): Updated 2 new messages for rc1
Vasco Almeida (1):
l10n: pt_PT: update Portuguese tranlation
po/TEAMS | 5 +-
po/bg.po | 10422 ++++++++++++++++++++++++++++++++++------------------------
po/ca.po | 4894 +++++++++++++++++----------
po/de.po | 4331 +++++++++++++++---------
po/fr.po | 4293 +++++++++++++++---------
po/git.pot | 3997 ++++++++++++++--------
po/ko.po | 4221 ++++++++++++++++--------
po/pt_PT.po | 4562 ++++++++++++++++---------
po/sv.po | 4275 +++++++++++++++---------
po/vi.po | 4275 +++++++++++++++---------
po/zh_CN.po | 4258 +++++++++++++++---------
11 files changed, 31663 insertions(+), 17870 deletions(-)
^ permalink raw reply
* Re: SHA1 collisions found
From: Ian Jackson @ 2017-02-24 15:13 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20170223164306.spg2avxzukkggrpb@kitenet.net>
Joey Hess writes ("SHA1 collisions found"):
> https://shattered.io/static/shattered.pdf
> https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
>
> IIRC someone has been working on parameterizing git's SHA1 assumptions
> so a repository could eventually use a more secure hash. How far has
> that gotten? There are still many "40" constants in git.git HEAD.
I have been thinking about how to do a transition from SHA1 to another
hash function.
I have concluded that:
* We can should avoid expecting everyone to rewrite all their
history.
* Unfortunately, because the data formats (particularly, the commit
header) are not in practice extensible (because of the way existing
code parses them), it is not useful to try generate new data (new
commits etc.) containing both new hashes and old hashes: old
clients will mishandle the new data.
* Therefore the transition needs to be done by giving every object
two names (old and new hash function). Objects may refer to each
other by either name, but must pick one. The usual shape of
project histories will be a pile of old commits referring to each
other by old names, surmounted by new commits referrring to each
other by new names.
* It is not possible to solve this problem without extending the
object name format. Therefore all software which calls git and
expects to handle object names will need to be updated.
I have been writing a more detailed transition plan. I hope to post
this within a few days.
Ian.
^ permalink raw reply
* Re: SHA1 collisions found
From: Geert Uytterhoeven @ 2017-02-24 15:52 UTC (permalink / raw)
To: Morten Welinder; +Cc: Joey Hess, Linus Torvalds, Git Mailing List
In-Reply-To: <CANv4PNmSjJUhFgC7GhpuBjiSQhwfAhrP8WxiP_siP2AjjXnrnw@mail.gmail.com>
On Thu, Feb 23, 2017 at 8:13 PM, Morten Welinder <mwelinder@gmail.com> wrote:
> The attack seems to generate two 64-bytes blocks, one quarter of which
> is repeated data. (Table-1 in the paper.)
>
> Assuming the result of that is evenly distributed and that bytes are
> independent, we can estimate the chances that the result is NUL-free
> as (255/256)^192 = 47% and the probability that the result is NUL and
> newline free as (254/256)^192 = 22%. Clearly one should not rely of
> NULs or newlines to save the day. On the other hand, the chances of
> an ascii result is something like (95/256)^192 = 10^-83.
Good. So they can replace linux/Documentation/logo.gif, but not actual source
files, not even if they contain hex arrays with "device parameters" ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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