* Re: [PATCH 0/4] Make other git commands use trailer layout
From: Junio C Hamano @ 2016-10-29 1:12 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <cover.1477698917.git.jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> This is built off jt/trailer-with-cruft (commit 60ef86a).
>
> This patch set makes "commit -s", "cherry-pick -x", and
> "format-patch --signoff" use the new trailer definition implemented in
> jt/trailer-with-cruft, with some refactoring along the way. With this
> patch set, the aforementioned commands would now handle trailers like
> those described in [1].
>
> [1] <84f28caa-2e4b-1231-1a76-3b7e765c0b61@google.com>
Ooooh. Looks delicious ;-)
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Junio C Hamano @ 2016-10-29 1:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Jeff King, Git Mailing List, Lars Schneider,
Eric Wong
In-Reply-To: <CA+55aFwUEzfvWVSZfhBi85QaKWSo-gVMOk1BJFrR0ZsdCRHRsg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Apparently windows doesn't even support it, at least not mingw....
Assuming that the above was a misunderstanding, assuming that we can
do O_CLOEXEC (but not FD_CLOEXEC) on Windows just fine, where stray
file descriptors held open in the children matter more, and ...
> In contrast, O_NOATIME isn't a maintenance problem, since it's purely
> an optimization and has no semantic difference, so it not existing on
> some platform is immaterial.
... assuming that I didn't screw up my use of fcntl() to set
O_NOATIME on a fd opened with O_CLOEXEC, are you OK with the
approach in patch *1*? We can drop *2* to keep O_NOATIME, which has
been working for those with old kernels with many loose objects, and
it is not too much code to keep.
*1* http://public-inbox.org/git/xmqqh97w38gj.fsf@gitster.mtv.corp.google.com
*2* http://public-inbox.org/git/xmqqd1ik38f4.fsf@gitster.mtv.corp.google.com
^ permalink raw reply
* Re: [PATCH v1 16/19] read-cache: unlink old sharedindex files
From: Duy Nguyen @ 2016-10-29 3:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Git Mailing List,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <xmqq4m3x93e1.fsf@gitster.mtv.corp.google.com>
On Thu, Oct 27, 2016 at 11:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> git-gc just can't match this because while it's running, somebody else
>> may be updating $GIT_DIR/index. Handling races would be a lot harder.
>
> It could attempt to take a lock on the primary index while it runs,
> and refrain to do anything if it can't take the lock ("gc --auto"
> may want to silently retry), and then the race is no longer an
> issue, no?
No, I thought of that. But if gc is holding the lock, another program
that wants to update the index may fail. And git-gc is supposed to be
non-intrusive
--
Duy
^ permalink raw reply
* Re: Fetch/push lets a malicious server steal the targets of "have" lines
From: Matt McCutchen @ 2016-10-29 3:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq7f8sx8lg.fsf@gitster.mtv.corp.google.com>
On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote:
> Ah, I see. My immediate reaction is that you can do worse things in
> the reverse direction compared to this, but your scenario does sound
> bad already.
Are you saying that clients connecting to untrusted servers already
face worse risks that people should know about, so there is no point in
documenting this one? I guess I don't know about the other risks aside
from accepting a corrupt object, which should be preventable by
enabling fetch.fsckObjects. It seems we need either a statement that
connecting to untrusted servers is officially unsupported or a
description of the specific risks.
Matt
^ permalink raw reply
* What's cooking in git.git (Oct 2016, #08; Fri, 28)
From: Junio C Hamano @ 2016-10-29 6:24 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Git v2.10.2, the second maintenance release for 2.10.x track, has
been tagged. On the master front, things are getting close for
v2.11.0-rc0, the preview snapshot for the upcoming 2.11.0 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"]
* jc/abbrev-auto (2016-10-22) 4 commits
(merged to 'next' on 2016-10-26 at 92fdb66807)
+ transport: compute summary-width dynamically
+ transport: allow summary-width to be computed dynamically
+ fetch: pass summary_width down the callchain
+ transport: pass summary_width down the callchain
(this branch uses jk/abbrev-auto and lt/abbrev-auto.)
"git push" and "git fetch" reports from what old object to what new
object each ref was updated, using abbreviated refnames, and they
attempt to align the columns for this and other pieces of
information. The way these codepaths compute how many display
columns to allocate for the object names portion of this output has
been updated to match the recent "auto scale the default
abbreviation length" change.
* jk/abbrev-auto (2016-10-03) 1 commit
(merged to 'next' on 2016-10-21 at 8aa3d760d8)
+ find_unique_abbrev: move logic out of get_short_sha1()
(this branch is used by jc/abbrev-auto; uses lt/abbrev-auto.)
Updates the way approximate count of total objects is computed
while attempting to come up with a unique abbreviated object name,
which in turn needs to estimate how many hexdigits are necessary to
ensure uniqueness.
* jk/daemon-path-ok-check-truncation (2016-10-24) 1 commit
(merged to 'next' on 2016-10-26 at 70c08241f6)
+ daemon: detect and reject too-long paths
"git daemon" used fixed-length buffers to turn URL to the
repository the client asked for into the server side directory
path, using snprintf() to avoid overflowing these buffers, but
allowed possibly truncated paths to the directory. This has been
tightened to reject such a request that causes overlong path to be
required to serve.
* jk/no-looking-at-dotgit-outside-repo (2016-10-26) 6 commits
(merged to 'next' on 2016-10-26 at 4aa877b578)
+ diff: handle sha1 abbreviations outside of repository
+ diff_aligned_abbrev: use "struct oid"
+ diff_unique_abbrev: rename to diff_aligned_abbrev
+ find_unique_abbrev: use 4-buffer ring
+ test-*-cache-tree: setup git dir
+ read info/{attributes,exclude} only when in repository
(this branch is used by jk/no-looking-at-dotgit-outside-repo-final.)
Update "git diff --no-index" codepath not to try to peek into .git/
directory that happens to be under the current directory, when we
know we are operating outside any repository.
* js/prepare-sequencer (2016-10-21) 27 commits
(merged to 'next' on 2016-10-26 at 12be8ebe90)
+ sequencer: mark all error messages for translation
+ sequencer: start error messages consistently with lower case
+ sequencer: quote filenames in error messages
+ sequencer: mark action_name() for translation
+ sequencer: remove overzealous assumption in rebase -i mode
+ sequencer: teach write_message() to append an optional LF
+ sequencer: refactor write_message() to take a pointer/length
+ sequencer: roll back lock file if write_message() failed
+ sequencer: stop releasing the strbuf in write_message()
+ sequencer: left-trim lines read from the script
+ sequencer: support cleaning up commit messages
+ sequencer: support amending commits
+ sequencer: allow editing the commit message on a case-by-case basis
+ sequencer: introduce a helper to read files written by scripts
+ sequencer: prepare for rebase -i's commit functionality
+ sequencer: remember the onelines when parsing the todo file
+ sequencer: get rid of the subcommand field
+ sequencer: avoid completely different messages for different actions
+ sequencer: strip CR from the todo script
+ sequencer: completely revamp the "todo" script parsing
+ sequencer: refactor the code to obtain a short commit name
+ sequencer: future-proof read_populate_todo()
+ sequencer: plug memory leaks for the option values
+ sequencer: future-proof remove_sequencer_state()
+ sequencer: avoid unnecessary indirection
+ sequencer: use memoized sequencer directory path
+ sequencer: use static initializers for replay_opts
Update of the sequencer codebase to make it reusable to reimplement
"rebase -i" continues.
* lt/abbrev-auto (2016-10-03) 3 commits
(merged to 'next' on 2016-10-03 at bb188d00f7)
+ abbrev: auto size the default abbreviation
+ abbrev: prepare for new world order
+ abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
(this branch is used by jc/abbrev-auto and jk/abbrev-auto.)
Allow the default abbreviation length, which has historically been
7, to scale as the repository grows. The logic suggests to use 12
hexdigits for the Linux kernel, and 9 to 10 for Git itself.
* nd/ita-empty-commit (2016-10-24) 4 commits
(merged to 'next' on 2016-10-26 at fb007cdae1)
+ commit: don't be fooled by ita entries when creating initial commit
+ commit: fix empty commit creation when there's no changes but ita entries
+ diff: add --ita-[in]visible-in-index
+ diff-lib: allow ita entries treated as "not yet exist in index"
When new paths were added by "git add -N" to the index, it was
enough to circumvent the check by "git commit" to refrain from
making an empty commit without "--allow-empty". The same logic
prevented "git status" to show such a path as "new file" in the
"Changes not staged for commit" section.
* rs/ring-buffer-wraparound (2016-10-26) 1 commit
(merged to 'next' on 2016-10-26 at d2da68a14a)
+ hex: make wraparound of the index into ring-buffer explicit
The code that we have used for the past 10+ years to cycle
4-element ring buffers turns out to be not quite portable in
theoretical world.
* sb/submodule-ignore-trailing-slash (2016-10-25) 3 commits
(merged to 'next' on 2016-10-26 at e56a8ebb38)
+ t0060: sidestep surprising path mangling results on Windows
(merged to 'next' on 2016-10-11 at e37425ed17)
+ submodule: ignore trailing slash in relative url
+ submodule: ignore trailing slash on superproject URL
A minor regression fix for "git submodule".
--------------------------------------------------
[New Topics]
* jk/common-main (2016-10-27) 1 commit
(merged to 'next' on 2016-10-28 at fcdd4f8a26)
+ git-compat-util: move content inside ifdef/endif guards
A trivial clean-up to a recently graduated topic.
Will merge to 'master'.
* ak/pre-receive-hook-template-modefix (2016-10-28) 1 commit
(merged to 'next' on 2016-10-28 at 86d95836a3)
+ pre-receive.sample: mark it executable
A trivial clean-up to a recently graduated topic.
Will merge to 'master'.
* nd/rebase-forget (2016-10-28) 1 commit
- rebase: add --forget to cleanup rebase, leave HEAD untouched
"git rebase" learned "--forget" option, which allows a user to
remove the metadata left by an earlier "git rebase" that was
manually aborted without using "git rebase --abort".
* jc/git-open-cloexec (2016-10-28) 2 commits
- sha1_file: stop opening files with O_NOATIME
- git_open(): untangle possible NOATIME and CLOEXEC interactions
(this branch uses ls/git-open-cloexec.)
The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
We probably want to drop the tip one.
--------------------------------------------------
[Stalled]
* hv/submodule-not-yet-pushed-fix (2016-10-10) 3 commits
- batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
Waiting for review.
cf. <cover.1475851621.git.hvoigt@hvoigt.net>
* sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
- push: change submodule default to check when submodules exist
- submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will hold to wait for hv/submodule-not-yet-pushed-fix
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- 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 `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and 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.
Rerolled.
Needs review.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* aw/numbered-stash (2016-10-26) 1 commit
(merged to 'next' on 2016-10-26 at 8d9325fa3a)
+ stash: allow stashes to be referenced by index only
The user always has to say "stash@{$N}" when naming a single
element in the default location of the stash, i.e. reflogs in
refs/stash. The "git stash" command learned to accept "git stash
apply 4" as a short-hand for "git stash apply stash@{4}".
Will merge to 'master'.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-10-26 at 220e160451)
+ setup_git_env: avoid blind fall-back to ".git"
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/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
* ls/git-open-cloexec (2016-10-25) 3 commits
(merged to 'next' on 2016-10-26 at f7259cbddb)
+ read-cache: make sure file handles are not inherited by child processes
+ sha1_file: open window into packfiles with O_CLOEXEC
+ sha1_file: rename git_open_noatime() to git_open()
(this branch is used by jc/git-open-cloexec.)
Git generally does not explicitly close file descriptors that were
open in the parent process when spawning a child process, but most
of the time the child does not want to access them. As Windows does
not allow removing or renaming a file that has a file descriptor
open, a slow-to-exit child can even break the parent process by
holding onto them. Use O_CLOEXEC flag to open files in various
codepaths.
Will merge to 'master'.
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
* tb/convert-stream-check (2016-10-27) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Waiting for review.
The tip seems to do too much in a single commit and may be better split.
cf. <20161012134724.28287-1-tboegi@web.de>
cf. <xmqqd1il5w4e.fsf@gitster.mtv.corp.google.com>
* jt/trailer-with-cruft (2016-10-21) 8 commits
(merged to 'next' on 2016-10-27 at b5d1a21811)
+ trailer: support values folded to multiple lines
+ trailer: forbid leading whitespace in trailers
+ trailer: allow non-trailers in trailer block
+ trailer: clarify failure modes in parse_trailer
+ trailer: make args have their own struct
+ trailer: streamline trailer item create and add
+ trailer: use list.h for doubly-linked list
+ trailer: improve const correctness
Update "interpret-trailers" machinery and teaches it that people in
real world write all sorts of crufts in the "trailer" that was
originally designed to have the neat-o "Mail-Header: like thing"
and nothing else.
Will merge to 'master'.
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Waiting for review.
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for a reroll.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* sb/attr (2016-10-28) 37 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
- attr: keep attr stack for each check
- SQUASH???
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- 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 git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- 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 attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
Waiting for review.
* va/i18n-perl-scripts (2016-10-20) 14 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark status words for translation
- i18n: add--interactive: remove %patch_modes entries
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark patch prompt for translation
- i18n: add--interactive: mark plural strings
- i18n: clean.c: match string with git-add--interactive.perl
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here-documents for translation
- i18n: add--interactive: mark strings for translation
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
cf. <20161010125449.7929-1-vascomalmeida@sapo.pt>
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will hold to see if people scream.
* ls/filter-process (2016-10-17) 14 commits
(merged to 'next' on 2016-10-19 at ffd0de042c)
+ contrib/long-running-filter: add long running filter example
+ convert: add filter.<driver>.process option
+ convert: prepare filter.<driver>.process option
+ convert: make apply_filter() adhere to standard Git error handling
+ pkt-line: add functions to read/write flush terminated packet streams
+ pkt-line: add packet_write_gently()
+ pkt-line: add packet_flush_gently()
+ pkt-line: add packet_write_fmt_gently()
+ pkt-line: extract set_packet_header()
+ pkt-line: rename packet_write() to packet_write_fmt()
+ run-command: add clean_on_exit_handler
+ run-command: move check_pipe() from write_or_die to run_command
+ convert: modernize tests
+ convert: quote filter names in error messages
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
Will merge to 'master'.
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-10-11 at 8928c8b9b3)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
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.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
Will cook in 'next'.
^ permalink raw reply
* [ANNOUNCE] Git v2.10.2
From: Junio C Hamano @ 2016-10-29 6:24 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v2.10.2 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.10.2'
tag and the 'maint' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Git v2.10.2 Release Notes
=========================
Fixes since v2.10.1
-------------------
* The code that parses the format parameter of for-each-ref command
has seen a micro-optimization.
* The "graph" API used in "git log --graph" miscounted the number of
output columns consumed so far when drawing a padding line, which
has been fixed; this did not affect any existing code as nobody
tried to write anything after the padding on such a line, though.
* Almost everybody uses DEFAULT_ABBREV to refer to the default
setting for the abbreviation, but "git blame" peeked into
underlying variable bypassing the macro for no good reason.
* Doc update to clarify what "log -3 --reverse" does.
* An author name, that spelled a backslash-quoted double quote in the
human readable part "My \"double quoted\" name", was not unquoted
correctly while applying a patch from a piece of e-mail.
* The original command line syntax for "git merge", which was "git
merge <msg> HEAD <parent>...", has been deprecated for quite some
time, and "git gui" was the last in-tree user of the syntax. This
is finally fixed, so that we can move forward with the deprecation.
* Codepaths that read from an on-disk loose object were too loose in
validating what they are reading is a proper object file and
sometimes read past the data they read from the disk, which has
been corrected. H/t to Gustavo Grieco for reporting.
* "git worktree", even though it used the default_abbrev setting that
ought to be affected by core.abbrev configuration variable, ignored
the variable setting. The command has been taught to read the
default set of configuration variables to correct this.
* A low-level function verify_packfile() was meant to show errors
that were detected without dying itself, but under some conditions
it didn't and died instead, which has been fixed.
* When "git fetch" tries to find where the history of the repository
it runs in has diverged from what the other side has, it has a
mechanism to avoid digging too deep into irrelevant side branches.
This however did not work well over the "smart-http" transport due
to a design bug, which has been fixed.
* When we started cURL to talk to imap server when a new enough
version of cURL library is available, we forgot to explicitly add
imap(s):// before the destination. To some folks, that didn't work
and the library tried to make HTTP(s) requests instead.
* The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.
* http.emptyauth configuration is a way to allow an empty username to
pass when attempting to authenticate using mechanisms like
Kerberos. We took an unspecified (NULL) username and sent ":"
(i.e. no username, no password) to CURLOPT_USERPWD, but did not do
the same when the username is explicitly set to an empty string.
* "git clone" of a local repository can be done at the filesystem
level, but the codepath did not check errors while copying and
adjusting the file that lists alternate object stores.
* Documentation for "git commit" was updated to clarify that "commit
-p <paths>" adds to the current contents of the index to come up
with what to commit.
* A stray symbolic link in $GIT_DIR/refs/ directory could make name
resolution loop forever, which has been corrected.
* The "submodule.<name>.path" stored in .gitmodules is never copied
to .git/config and such a key in .git/config has no meaning, but
the documentation described it and submodule.<name>.url next to
each other as if both belong to .git/config. This has been fixed.
* Recent git allows submodule.<name>.branch to use a special token
"." instead of the branch name; the documentation has been updated
to describe it.
* In a worktree connected to a repository elsewhere, created via "git
worktree", "git checkout" attempts to protect users from confusion
by refusing to check out a branch that is already checked out in
another worktree. However, this also prevented checking out a
branch, which is designated as the primary branch of a bare
reopsitory, in a worktree that is connected to the bare
repository. The check has been corrected to allow it.
* "git rebase" immediately after "git clone" failed to find the fork
point from the upstream.
* When fetching from a remote that has many tags that are irrelevant
to branches we are following, we used to waste way too many cycles
when checking if the object pointed at by a tag (that we are not
going to fetch!) exists in our repository too carefully.
* The Travis CI configuration we ship ran the tests with --verbose
option but this risks non-TAP output that happens to be "ok" to be
misinterpreted as TAP signalling a test that passed. This resulted
in unnecessary failure. This has been corrected by introducing a
new mode to run our tests in the test harness to send the verbose
output separately to the log file.
* Some AsciiDoc formatter mishandles a displayed illustration with
tabs in it. Adjust a few of them in merge-base documentation to
work around them.
Also contains minor documentation updates and code clean-ups.
----------------------------------------------------------------
Changes since v2.10.1 are as follows:
Anders Kaseorg (1):
imap-send: Tell cURL to use imap:// or imaps://
Brandon Williams (1):
submodules doc: update documentation for "." used for submodule branches
David Turner (2):
add David Turner's Two Sigma address
http: http.emptyauth should allow empty (not just NULL) usernames
Dennis Kaarsemaker (1):
worktree: allow the main brach of a bare repository to be checked out
Dimitriy Ryazantcev (1):
l10n: ru.po: update Russian translation
Jakub Narębski (1):
configure.ac: improve description of NO_REGEX test
Jeff King (11):
verify_packfile: check pack validity before accessing data
graph: fix extra spaces in graph_padding_line
clone: detect errors in normalize_path_copy
files_read_raw_ref: avoid infinite loop on broken symlinks
files_read_raw_ref: prevent infinite retry loops in general
merge-base: handle --fork-point without reflog
fetch: use "quick" has_sha1_file for tag following
test-lib: handle TEST_OUTPUT_DIRECTORY with spaces
test-lib: add --verbose-log option
travis: use --verbose-log test option
test-lib: bail out when "-v" used under "prove"
Johannes Schindelin (1):
reset: fix usage
Jonathan Tan (1):
fetch-pack: do not reset in_vain on non-novel acks
Junio C Hamano (9):
streaming: make sure to notice corrupt object
unpack_sha1_header(): detect malformed object header
worktree: honor configuration variables
blame: use DEFAULT_ABBREV macro
diff_unique_abbrev(): document its assumption and limitation
Start preparing for 2.10.2
cocci: refactor common patterns to use xstrdup_or_null()
t3700: fix broken test under !SANITY
Git 2.10.2
Kevin Daudt (2):
t5100-mailinfo: replace common path prefix with variable
mailinfo: unescape quoted-pair in header fields
Nguyễn Thái Ngọc Duy (1):
git-commit.txt: clarify --patch mode with pathspec
Philip Oakley (2):
doc: fix merge-base ASCII art tab spacing
doc: fix the 'revert a faulty merge' ASCII art tab spacing
Pranit Bauva (2):
rev-list-options: clarify the usage of --reverse
t0040: convert all possible tests to use `test-parse-options --expect`
Ralf Thielow (2):
l10n: de.po: fix translation of autostash
l10n: de.po: translate 260 new messages
René Scharfe (17):
contrib/coccinelle: fix semantic patch for oid_to_hex_r()
add coccicheck make target
use strbuf_addstr() for adding constant strings to a strbuf, part 2
pretty: let %C(auto) reset all attributes
add COPY_ARRAY
use COPY_ARRAY
git-gui: stop using deprecated merge syntax
gitignore: ignore output files of coccicheck make target
use strbuf_addstr() instead of strbuf_addf() with "%s", part 2
use strbuf_add_unique_abbrev() for adding short hashes, part 2
pretty: avoid adding reset for %C(auto) if output is empty
coccicheck: make transformation for strbuf_addf(sb, "...") more precise
remove unnecessary NULL check before free(3)
use strbuf_add_unique_abbrev() for adding short hashes, part 3
pretty: fix document link for color specification
avoid pointer arithmetic involving NULL in FLEX_ALLOC_MEM
inline xalloc_flex() into FLEXPTR_ALLOC_MEM
SZEDER Gábor (1):
ref-filter: strip format option after a field name only once while parsing
Stefan Beller (1):
documentation: improve submodule.<name>.{url, path} description
Younes Khoudli (1):
doc: remove reference to the traditional layout in git-tag.txt
Дилян Палаузов (1):
./configure.ac: detect SSL in libcurl using curl-config
^ permalink raw reply
* Re: [PATCHv2 27/36] attr: convert to new threadsafe API
From: Johannes Sixt @ 2016-10-29 7:10 UTC (permalink / raw)
To: Junio C Hamano, Stefan Beller; +Cc: bmwill, pclouds, git
In-Reply-To: <xmqqinscxh5g.fsf@gitster.mtv.corp.google.com>
Am 29.10.2016 um 00:06 schrieb Junio C Hamano:
> Probably this needs to be squashed in, now the MinGW discussion has
> settled.
Yes, this looks good. Thank you very much, both of you.
As I said, I won't be able to test this until late next week.
-- Hannes
>
> attr.c | 2 +-
> common-main.c | 2 ++
> compat/mingw.c | 4 ----
> 3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/attr.c b/attr.c
> index 082b5ed343..961218a0d5 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -50,7 +50,7 @@ static struct git_attr *(git_attr_hash[HASHSIZE]);
>
> #ifndef NO_PTHREADS
>
> -static pthread_mutex_t attr_mutex = PTHREAD_MUTEX_INITIALIZER;
> +static pthread_mutex_t attr_mutex;
> #define attr_lock() pthread_mutex_lock(&attr_mutex)
> #define attr_unlock() pthread_mutex_unlock(&attr_mutex)
> void attr_start(void) { pthread_mutex_init(&attr_mutex, NULL); }
> diff --git a/common-main.c b/common-main.c
> index 44a29e8b13..d4699cd404 100644
> --- a/common-main.c
> +++ b/common-main.c
> @@ -1,5 +1,6 @@
> #include "cache.h"
> #include "exec_cmd.h"
> +#include "attr.h"
>
> /*
> * Many parts of Git have subprograms communicate via pipe, expect the
> @@ -32,6 +33,7 @@ int main(int argc, const char **argv)
> sanitize_stdfds();
>
> git_setup_gettext();
> + attr_start();
>
> argv[0] = git_extract_argv0_path(argv[0]);
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 51ed76326b..3fbfda5978 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -5,7 +5,6 @@
> #include "../strbuf.h"
> #include "../run-command.h"
> #include "../cache.h"
> -#include "../attr.h"
>
> #define HCAST(type, handle) ((type)(intptr_t)handle)
>
> @@ -2233,9 +2232,6 @@ void mingw_startup(void)
> /* initialize critical section for waitpid pinfo_t list */
> InitializeCriticalSection(&pinfo_cs);
>
> - /* initialize critical sections in the attr code */
> - attr_start();
> -
> /* set up default file mode and file modes for stdin/out/err */
> _fmode = _O_BINARY;
> _setmode(_fileno(stdin), _O_BINARY);
>
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Johannes Schindelin @ 2016-10-29 8:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Jeff King, Git Mailing List, Lars Schneider,
Eric Wong
In-Reply-To: <xmqqr370vtba.fsf@gitster.mtv.corp.google.com>
Hi,
On Fri, 28 Oct 2016, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Apparently windows doesn't even support it, at least not mingw....
>
> Assuming that the above was a misunderstanding, assuming that we can
> do O_CLOEXEC (but not FD_CLOEXEC) on Windows just fine, where stray
> file descriptors held open in the children matter more, and ...
Correct. We cannot change an open file handle's state ("FD_CLOEXEC") on
Windows, but we can ask open() to open said file handle with the correct
flag ("O_CLOEXEC", which is mapped to O_NOINHERIT on Windows.
And for the record: I agree with Junio that we cannot simply drop this
O_CLOEXEC business.
Because it was introduced to fix bugs.
Thank you for your time,
Johannes
^ permalink raw reply
* Re: [ANNOUNCE] Git v2.10.2
From: Johannes Schindelin @ 2016-10-29 8:39 UTC (permalink / raw)
To: git-for-windows, Junio C Hamano; +Cc: git
In-Reply-To: <xmqqd1ijwu3s.fsf@gitster.mtv.corp.google.com>
Hi,
On Fri, 28 Oct 2016, Junio C Hamano wrote:
> The latest maintenance release Git v2.10.2 is now available at
> the usual places.
The corresponding Git for Windows version will be hopefully out on
Tuesday: https://github.com/git-for-windows/git/milestone/5
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] valgrind: support test helpers
From: René Scharfe @ 2016-10-29 9:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Duy Nguyen, Johannes Schindelin
In-Reply-To: <xmqqshrg3af4.fsf@gitster.mtv.corp.google.com>
Am 28.10.2016 um 14:50 schrieb Junio C Hamano:
> Hmph. I somehow thought this was supposed to have been fixed by
> 503e224180 ("t/test-lib.sh: fix running tests with --valgrind",
> 2016-07-11) already.
Its title seems to indicate that intention. Probably the quickest test
script that calls a helper is t0009-prio-queue.sh, and without my patch
it reports something like this, unfortunately:
expecting success:
test-prio-queue 2 6 3 10 9 5 7 4 5 8 1 dump >actual &&
test_cmp expect actual
./t0009-prio-queue.sh: 4: eval: test-prio-queue: not found
not ok 1 - basic ordering
#
# test-prio-queue 2 6 3 10 9 5 7 4 5 8 1 dump >actual &&
# test_cmp expect actual
#
René
^ permalink raw reply
* Re: [PATCH] valgrind: support test helpers
From: René Scharfe @ 2016-10-29 9:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git List, Duy Nguyen, Junio C Hamano
In-Reply-To: <alpine.DEB.2.20.1610281050220.3264@virtualbox>
Am 28.10.2016 um 10:51 schrieb Johannes Schindelin:
> On Fri, 28 Oct 2016, René Scharfe wrote:
>> Signed-off-by: Rene Scharfe <l.s.r@web.de>
>
> Apart from the missing accent ("é") in your SOB: ACK.
I sign off without accent out of habit, to avoid display problems --
better have a plain "e" than something like "<C3><A9>" or worse.
But only now I realized that I can fix at least my end by using an UTF-8
locale (e.g. LANG=C.UTF-8 instead of LANG=C) -- together with PuTTY and
its settings Window, Translation, Remote character set: UTF-8 and
Connection, Data, Terminal-type-string: linux, which I already had. My
terminal just got boosted into the 21st century, woohoo! ;)
René
^ permalink raw reply
* Re: Is the entire working copy “at one branch”?
From: Alexei Lozovsky @ 2016-10-29 9:47 UTC (permalink / raw)
To: Stefan Monov; +Cc: git
In-Reply-To: <CAJtFkWs4qYCqnbJD+zCRCAW3teczb4CdvncvYoMN_VvthJGr=w@mail.gmail.com>
Hi Stefan,
Generally with git, your entire working copy will have the same
revision (set to current branch, aka HEAD). The idea behind this
is that your working copy of a repository should always be in
consistent state.
You can check out specific files or directories from another
revision (mimicking "svn update -r1234 filename"):
$ git checkout branch-or-sha-hash -- filename
However, SVN tracks the 'revision' thing on per-file basis, while
in git this is a property of the working copy. So if you do like
above then git will be telling you that the 'filename' has been
changed (as it is certainly different from its pristine version
in HEAD):
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: filename
So it's generally not recommended to do such a thing.
Another thing that you _can do_ in git to mimick SVN is the
'standard layout'. There is a feature called "git worktree" which
allows you to have SVN-like directory structure with multiple
directories linked to different working copies:
$ mkdir my-project
$ cd my-project
$ git clone my-project-repository master
$ mkdir branches
$ cd master
$ git worktree add -b branch-1 ../branches/branch-1
$ git worktree add -b branch-2 ../branches/branch-2
After that you will have directory structure like this:
$ tree my-project
my-project
├── branches
│ ├── branch-1
│ │ ├── 1
│ │ ├── 2
│ │ └── 3
│ └── branch-2
│ ├── 1
│ ├── 2
│ └── banana
└── master
├── 1
└── 2
You can work with these working copies separately, like you
would be working with SVN. Commits in 'master' will go to the
'master' branch, commits made in 'branches/branch-1' will go
to the 'branch-1' branch.
^ permalink raw reply
* Re: [PATCH v2 2/2] convert.c: stream and fast search for binary
From: Duy Nguyen @ 2016-10-29 12:13 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Git Mailing List
In-Reply-To: <20161012134727.28365-1-tboegi@web.de>
On Wed, Oct 12, 2016 at 8:47 PM, <tboegi@web.de> wrote:
> From: Torsten Bögershausen <tboegi@web.de>
>
> When statistics are done for the autocrlf handling, the search in
> the content can be stopped, if e.g
> - a search for binary is done, and a NUL character is found
> - a search for CRLF is done, and the first CRLF is found.
>
> Similar when statistics for binary vs non-binary are gathered:
> Whenever a lone CR or NUL is found, the search can be aborted.
>
> When checking out files in "auto" mode, any file that has a "lone CR"
> or a CRLF will not be converted, so the search can be aborted early.
>
> Add the new bit, CONVERT_STAT_BITS_ANY_CR,
> which is set for either lone CR or CRLF.
>
> Many binary files have a NUL very early and it is often not necessary
> to load the whole content of a file or blob into memory.
>
> Split gather_stats() into gather_all_stats() and gather_stats_partly()
> to do a streaming handling for blobs and files in the worktree.
Maybe break this commit down a bit? the gather_all_stats and
gather_stats_partly() seem independent and can standalone. So is the
blob streaming, and get_convert_stats_wt.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 1/2] read-cache: factor out get_sha1_from_index() helper
From: Duy Nguyen @ 2016-10-29 12:22 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Git Mailing List
In-Reply-To: <20161012134726.28326-1-tboegi@web.de>
On Wed, Oct 12, 2016 at 8:47 PM, <tboegi@web.de> wrote:
> From: Torsten Bögershausen <tboegi@web.de>
>
> Factor out the retrieval of the sha1 for a given path in
> read_blob_data_from_index() into the function get_sha1_from_index().
>
> This will be used in the next commit, when convert.c can do the
> analyze for "text=auto" without slurping the whole blob into memory
> at once.
>
> Add a wrapper definition get_sha1_from_cache().
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> cache.h | 3 +++
> read-cache.c | 29 ++++++++++++++++++-----------
> 2 files changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 1604e29..04de209 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -380,6 +380,7 @@ extern void free_name_hash(struct index_state *istate);
> #define unmerge_cache_entry_at(at) unmerge_index_entry_at(&the_index, at)
> #define unmerge_cache(pathspec) unmerge_index(&the_index, pathspec)
> #define read_blob_data_from_cache(path, sz) read_blob_data_from_index(&the_index, (path), (sz))
> +#define get_sha1_from_cache(path) get_sha1_from_index (&the_index, (path))
> #endif
>
> enum object_type {
> @@ -1089,6 +1090,8 @@ static inline void *read_sha1_file(const unsigned char *sha1, enum object_type *
> return read_sha1_file_extended(sha1, type, size, LOOKUP_REPLACE_OBJECT);
> }
>
> +const unsigned char *get_sha1_from_index(struct index_state *istate, const char *path);
> +
> /*
> * This internal function is only declared here for the benefit of
> * lookup_replace_object(). Please do not call it directly.
> diff --git a/read-cache.c b/read-cache.c
> index 38d67fa..5a1df14 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -2290,13 +2290,27 @@ int index_name_is_other(const struct index_state *istate, const char *name,
>
> void *read_blob_data_from_index(struct index_state *istate, const char *path, unsigned long *size)
> {
> - int pos, len;
> + const unsigned char *sha1;
> unsigned long sz;
> enum object_type type;
> void *data;
>
> - len = strlen(path);
> - pos = index_name_pos(istate, path, len);
> + sha1 = get_sha1_from_index(istate, path);
> + if (!sha1)
> + return NULL;
> + data = read_sha1_file(sha1, &type, &sz);
> + if (!data || type != OBJ_BLOB) {
> + free(data);
> + return NULL;
> + }
> + if (size)
> + *size = sz;
> + return data;
> +}
> +
> +const unsigned char *get_sha1_from_index(struct index_state *istate, const char *path)
Let's try to embrace struct object_id to make our lives easier when
the time comes to convert to a new hash algorithm by returning struct
object_id * here instead of the internal hash.
> +{
> + int pos = index_name_pos(istate, path, strlen(path));
> if (pos < 0) {
> /*
> * We might be in the middle of a merge, in which
> @@ -2312,14 +2326,7 @@ void *read_blob_data_from_index(struct index_state *istate, const char *path, un
> }
> if (pos < 0)
> return NULL;
> - data = read_sha1_file(istate->cache[pos]->oid.hash, &type, &sz);
> - if (!data || type != OBJ_BLOB) {
> - free(data);
> - return NULL;
> - }
> - if (size)
> - *size = sz;
> - return data;
> + return istate->cache[pos]->oid.hash;
> }
>
> void stat_validity_clear(struct stat_validity *sv)
--
Duy
^ permalink raw reply
* Re: [PATCH 2/4] trailer: avoid unnecessary splitting on lines
From: Christian Couder @ 2016-10-29 12:25 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <db609e13740415ac4e5e357493661347b0f681f7.1477698917.git.jonathantanmy@google.com>
On Sat, Oct 29, 2016 at 2:05 AM, Jonathan Tan <jonathantanmy@google.com> wrote:
> trailer.c currently splits lines while processing a buffer (and also
> rejoins lines when needing to invoke ignore_non_trailer).
>
> Avoid such line splitting, except when generating the strings
> corresponding to trailers (for ease of use by clients - a subsequent
> patch will allow other components to obtain the layout of a trailer
> block in a buffer, including the trailers themselves). The main purpose
> of this is to make it easy to return pointers into the original buffer
> (for a subsequent patch), but this also significantly reduces the number
> of memory allocations required.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> trailer.c | 215 +++++++++++++++++++++++++++++++++-----------------------------
> 1 file changed, 116 insertions(+), 99 deletions(-)
IMHO it is telling that this needs 17 more lines.
> @@ -954,7 +971,7 @@ void process_trailers(const char *file, int in_place, int trim_empty, struct str
> {
> LIST_HEAD(head);
> LIST_HEAD(arg_head);
> - struct strbuf **lines;
> + struct strbuf sb = STRBUF_INIT;
We often use "sb" as the name of strbuf variables, but I think at
least here (and maybe in other places above) we could use something a
bit more telling, like "input_buf" perhaps.
> int trailer_end;
> FILE *outfile = stdout;
>
^ permalink raw reply
* Re: [PATCH 0/4] Make other git commands use trailer layout
From: Christian Couder @ 2016-10-29 12:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Tan, git
In-Reply-To: <xmqqzilovtye.fsf@gitster.mtv.corp.google.com>
On Sat, Oct 29, 2016 at 3:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> This is built off jt/trailer-with-cruft (commit 60ef86a).
>>
>> This patch set makes "commit -s", "cherry-pick -x", and
>> "format-patch --signoff" use the new trailer definition implemented in
>> jt/trailer-with-cruft, with some refactoring along the way. With this
>> patch set, the aforementioned commands would now handle trailers like
>> those described in [1].
>>
>> [1] <84f28caa-2e4b-1231-1a76-3b7e765c0b61@google.com>
>
> Ooooh. Looks delicious ;-)
Yeah, I am very happy with this goal being reached :-)
Thanks,
Christian.
^ permalink raw reply
* [PATCH] commit: simplify building parents list
From: René Scharfe @ 2016-10-29 12:55 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
Push pptr down into the FROM_MERGE branch of the if/else statement,
where it's actually used, and call commit_list_append() for appending
elements instead of playing tricks with commit_list_insert(). Call
copy_commit_list() in the amend branch instead of open-coding it. Don't
bother setting pptr in the final branch as it's not used thereafter.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
builtin/commit.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index a2baa6e..8976c3d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1642,7 +1642,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
const char *index_file, *reflog_msg;
char *nl;
unsigned char sha1[20];
- struct commit_list *parents = NULL, **pptr = &parents;
+ struct commit_list *parents = NULL;
struct stat statbuf;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1688,20 +1688,18 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!reflog_msg)
reflog_msg = "commit (initial)";
} else if (amend) {
- struct commit_list *c;
-
if (!reflog_msg)
reflog_msg = "commit (amend)";
- for (c = current_head->parents; c; c = c->next)
- pptr = &commit_list_insert(c->item, pptr)->next;
+ parents = copy_commit_list(current_head->parents);
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
FILE *fp;
int allow_fast_forward = 1;
+ struct commit_list **pptr = &parents;
if (!reflog_msg)
reflog_msg = "commit (merge)";
- pptr = &commit_list_insert(current_head, pptr)->next;
+ pptr = commit_list_append(current_head, pptr);
fp = fopen(git_path_merge_head(), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1712,7 +1710,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
parent = get_merge_parent(m.buf);
if (!parent)
die(_("Corrupt MERGE_HEAD file (%s)"), m.buf);
- pptr = &commit_list_insert(parent, pptr)->next;
+ pptr = commit_list_append(parent, pptr);
}
fclose(fp);
strbuf_release(&m);
@@ -1729,7 +1727,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = (whence == FROM_CHERRY_PICK)
? "commit (cherry-pick)"
: "commit";
- pptr = &commit_list_insert(current_head, pptr)->next;
+ commit_list_insert(current_head, &parents);
}
/* Finally, get the commit message */
--
2.10.2
^ permalink raw reply related
* Re: Fetch/push lets a malicious server steal the targets of "have" lines
From: Jeff King @ 2016-10-29 13:39 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git
In-Reply-To: <1477712029.2904.64.camel@mattmccutchen.net>
On Fri, Oct 28, 2016 at 11:33:49PM -0400, Matt McCutchen wrote:
> On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote:
> > Ah, I see. My immediate reaction is that you can do worse things in
> > the reverse direction compared to this, but your scenario does sound
> > bad already.
>
> Are you saying that clients connecting to untrusted servers already
> face worse risks that people should know about, so there is no point in
> documenting this one? I guess I don't know about the other risks aside
> from accepting a corrupt object, which should be preventable by
> enabling fetch.fsckObjects. It seems we need either a statement that
> connecting to untrusted servers is officially unsupported or a
> description of the specific risks.
I'm not sure I understand how connecting to a remote server to fetch is
a big problem. The server may learn about the existence of particular
sha1s in your repository, but cannot get their content.
It's the subsequent push that is a problem.
In the scenarios you've described, I'm mostly inclined to say that the
problem is not git or the protocol itself, but rather lax refspecs.
You mentioned earlier:
the server can just generate another ref 'xx' pointing to Y2, assuming
it can entice the victim to set up a corresponding local branch
refs/heads/for-server1/xx and push it back. Or if the victim is for
some reason just mirroring back and forth:
This sounds a lot like "I told git to push a bunch of things without
checking if they were really secret, and it turned out to push some
secret things". IOW I think the problem is not that the server may lie
about what it has, but that the user was not careful about what they
pushed. I dunno. I do not mind making a note in the documentation
explaining the implications of a server lying, but the scenarios seem
pretty contrived to me.
A much more interesting one, IMHO, is a server whose receive-pack lies
about which objects it has (possibly ones it found out about earlier via
fetch), which provokes the client to generate deltas against objects the
server doesn't have (and thereby leaking information about the base
objects).
That is a problem no matter how careful your refspecs are. I suspect it
would be a hard attack to pull off in practice, just because it's going
to depend heavily on the content of the specific objects, what kinds of
deltas you can convince the other side to generate, etc. That might
merit a mention in the git-push documentation.
-Peff
^ permalink raw reply
* Re: Fetch/push lets a malicious server steal the targets of "have" lines
From: Matt McCutchen @ 2016-10-29 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <CAPc5daVOxmowdiTU3ScFv6c_BRVEJ+G92gx_AmmKnR-WxUKv-Q@mail.gmail.com>
On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote:
> Not sending to the list, where mails from Gmail/phone is known to get
> rejected.
[I guess I can go ahead and quote this to the list.]
> No. I'm saying that the scenario you gave is bad and people should be
> taught not to connect to untrustworthy sites.
To clarify, are you saying:
(1) don't connect to an untrusted server ever (e.g., we don't promise
that the server can't execute arbitrary code on the client), or
(2) don't connect to an untrusted server if the client repository has
data that needs to be kept secret from the server?
The fetch/push attack relates only to #2. If #1, what are the other
risks you are thinking of?
Matt
^ permalink raw reply
* Re: Fetch/push lets a malicious server steal the targets of "have" lines
From: Matt McCutchen @ 2016-10-29 16:08 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20161029133959.kpkohjkku3jgwjql@sigill.intra.peff.net>
On Sat, 2016-10-29 at 09:39 -0400, Jeff King wrote:
> I'm not sure I understand how connecting to a remote server to fetch is
> a big problem. The server may learn about the existence of particular
> sha1s in your repository, but cannot get their content.
>
> It's the subsequent push that is a problem.
>
> In the scenarios you've described, I'm mostly inclined to say that the
> problem is not git or the protocol itself, but rather lax refspecs.
> You mentioned earlier:
>
> the server can just generate another ref 'xx' pointing to Y2, assuming
> it can entice the victim to set up a corresponding local branch
> refs/heads/for-server1/xx and push it back. Or if the victim is for
> some reason just mirroring back and forth:
>
> This sounds a lot like "I told git to push a bunch of things without
> checking if they were really secret, and it turned out to push some
> secret things". IOW I think the problem is not that the server may lie
> about what it has, but that the user was not careful about what they
> pushed. I dunno. I do not mind making a note in the documentation
> explaining the implications of a server lying, but the scenarios seem
> pretty contrived to me.
Let's focus on the first scenario. There the user is just pulling and
pushing a master branch. Are you saying that each time the user pulls,
they need to look over all the commits they pulled before pushing them
back? I think that's unrealistic, for example, on a busy project with
centralized code review or if the user is publishing a project-specific
modified version of an upstream library. The natural user expectation
is that anything pulled from a public repository is public.
But let's see what Junio says in the other subthread.
> A much more interesting one, IMHO, is a server whose receive-pack lies
> about which objects it has (possibly ones it found out about earlier via
> fetch), which provokes the client to generate deltas against objects the
> server doesn't have (and thereby leaking information about the base
> objects).
>
> That is a problem no matter how careful your refspecs are. I suspect it
> would be a hard attack to pull off in practice, just because it's going
> to depend heavily on the content of the specific objects, what kinds of
> deltas you can convince the other side to generate, etc. That might
> merit a mention in the git-push documentation.
Sure, if I end up doing a patch, I'll include this.
Matt
^ permalink raw reply
* Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC
From: Linus Torvalds @ 2016-10-29 17:06 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Git Mailing List, Lars Schneider,
Eric Wong
In-Reply-To: <alpine.DEB.2.20.1610291022120.3264@virtualbox>
On Sat, Oct 29, 2016 at 1:25 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Correct. We cannot change an open file handle's state ("FD_CLOEXEC") on
> Windows, but we can ask open() to open said file handle with the correct
> flag ("O_CLOEXEC", which is mapped to O_NOINHERIT on Windows.
Ok. So then I have no issues with it, and let's use O_CLOEXEC if it
exists and fcntl(FD_CLOEXEC) if O_CLOEXEC doesn't exist.
Linus
^ permalink raw reply
* Re: Fetch/push lets a malicious server steal the targets of "have" lines
From: Jon Loeliger @ 2016-10-29 17:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <xmqq7f8sx8lg.fsf@gitster.mtv.corp.google.com>
So, like, Junio C Hamano said:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>
> > Then the server generates a commit X3 that lists Y2 as a parent, even
> > though it doesn't have Y2, and advances 'x' to X3. The victim fetches
> > 'x':
> >
> > victim server
> >
> > Y1---Y2---- (Y2)
> > / \ \
> > ---O---O---X1---X2---X3 ---O---O---X1---X2---X3
> >
> > Then the server rolls back 'x' to X2:
> >
> > victim server
> >
> > Y1---Y2----
> > / \
> > ---O---O---X1---X2---X3 ---O---O---X1---X2
>
> Ah, I see. My immediate reaction is that you can do worse things in
> the reverse direction compared to this, but your scenario does sound
> bad already.
Is there an existing protocol provision, or an extension to
the protocol that would allow a distrustful client to say to
the server, "Really, you have Y2? Prove it." And expect the
server to respond with a SHA1 sequence back to a common SHA
(in this case the left-most O). If so, a user could designate
some branch (Y) as "sensitive". Or, a whole repo could be
so designated and the client then effectivey treats the server
as a semi-hostile witness.
Dunno.
jdl
^ permalink raw reply
* Re: Fetch/push lets a malicious server steal the targets of "have" lines
From: Jeff King @ 2016-10-29 19:10 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git
In-Reply-To: <1477757311.1524.21.camel@mattmccutchen.net>
On Sat, Oct 29, 2016 at 12:08:31PM -0400, Matt McCutchen wrote:
> Let's focus on the first scenario. There the user is just pulling and
> pushing a master branch. Are you saying that each time the user pulls,
> they need to look over all the commits they pulled before pushing them
> back? I think that's unrealistic, for example, on a busy project with
> centralized code review or if the user is publishing a project-specific
> modified version of an upstream library. The natural user expectation
> is that anything pulled from a public repository is public.
No, I'm saying if you are running "git push foo master", then you should
expect the contents of "master" to go to "foo". That _could_ have
security implications if you come up with a sequence of events where
secret things made it to "master". But it seems to me that "foo
previously lied to you about what it has" is not the weak link in that
chain. It is not thinking about what secret things are hitting the
master that you are pushing, no matter how they got there.
I agree there is a potential workflow (that you have laid out) where
such lying can cause an innocent-looking sequence of events to disclose
the secret commits. And again, I don't mind a note in the documentation
mentioning that. I just have trouble believing it's a common one in
practice.
The reason I brought up the delta thing, even though it's a much harder
attack to execute, is that it comes up in much more common workflows,
like simply fetching from a private security-sensitive repo into your
"main" public repo (which is an example you brought up, and something I
know that I have personally done in the past for git.git).
-Peff
^ permalink raw reply
* Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions
From: Christian Couder @ 2016-10-29 22:06 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CACsJy8DPt3EJoSTVEZFbH6xXbh78MbLZ4h+50K4eoFxPYSaN=Q@mail.gmail.com>
On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> +void remove_split_index(struct index_state *istate)
>> +{
>> + if (istate->split_index) {
>> + /*
>> + * can't discard_split_index(&the_index); because that
>> + * will destroy split_index->base->cache[], which may
>> + * be shared with the_index.cache[]. So yeah we're
>> + * leaking a bit here.
>
> In the context of update-index, this is a one-time thing and leaking
> is tolerable. But because it becomes a library function now, this leak
> can become more serious, I think.
>
> The only other (indirect) caller is read_index_from() so probably not
> bad most of the time (we read at the beginning of a command only).
> sequencer.c may discard and re-read the index many times though,
> leaking could be visible there.
So is it enough to check if split_index->base->cache[] is shared with
the_index.cache[] and then decide if discard_split_index(&the_index)
should be called?
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH v1 05/19] update-index: warn in case of split-index incoherency
From: Christian Couder @ 2016-10-29 22:19 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CACsJy8Br2q0aadTFjkNgb=oN8nSzbkWJEK7bCCgr7v-oOZtrSA@mail.gmail.com>
On Tue, Oct 25, 2016 at 12:00 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> When users are using `git update-index --(no-)split-index`, they
>> may expect the split-index feature to be used or not according to
>> the option they just used, but this might not be the case if the
>> new "core.splitIndex" config variable has been set. In this case
>> let's warn about what will happen and why.
>>
>> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>> ---
>> builtin/update-index.c | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/builtin/update-index.c b/builtin/update-index.c
>> index b75ea03..a14dbf2 100644
>> --- a/builtin/update-index.c
>> +++ b/builtin/update-index.c
>> @@ -1098,12 +1098,21 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
>> }
>>
>> if (split_index > 0) {
>> + if (git_config_get_split_index() == 0)
>> + warning("core.splitIndex is set to false; "
>> + "remove or change it, if you really want to "
>> + "enable split index");
>
> Wrap this string and the one below with _() so they can be translated.
Ok, it will be in the next version.
^ 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