gitweb.git
Merge branch 'mm/add-p-split-error'Junio C Hamano Mon, 11 May 2015 21:23:47 +0000 (14:23 -0700)

Merge branch 'mm/add-p-split-error'

When "add--interactive" splits a hunk into two overlapping hunks
and then let the user choose only one, it sometimes feeds an
incorrect patch text to "git apply". Add tests to demonstrate
this.

I have a slight suspicion that this may be $gmane/87202 coming back
and biting us (I seem to have said "let's run with this and see
what happens" back then).

* mm/add-p-split-error:
stash -p: demonstrate failure of split with mixed y/n
t3904-stash-patch: factor PERL prereq at the top of the file
t3904-stash-patch: fix test description
add -p: demonstrate failure when running 'edit' after a split
t3701-add-interactive: simplify code

Merge branch 'tb/t0027-crlf'Junio C Hamano Mon, 11 May 2015 21:23:47 +0000 (14:23 -0700)

Merge branch 'tb/t0027-crlf'

More line-ending tests.

* tb/t0027-crlf:
t0027: Add repoMIX and LF_nul
t0027: support NATIVE_CRLF platforms
t0027: cleanup: rename functions; avoid non-leading TABs

Merge branch 'ls/p4-changes-block-size'Junio C Hamano Mon, 11 May 2015 21:23:46 +0000 (14:23 -0700)

Merge branch 'ls/p4-changes-block-size'

"git p4" learned "--changes-block-size <n>" to read the changes in
chunks from Perforce, instead of making one call to "p4 changes"
that may trigger "too many rows scanned" error from Perforce.

* ls/p4-changes-block-size:
git-p4: use -m when running p4 changes

Merge branch 'jc/plug-fmt-merge-msg-leak'Junio C Hamano Mon, 11 May 2015 21:23:45 +0000 (14:23 -0700)

Merge branch 'jc/plug-fmt-merge-msg-leak'

* jc/plug-fmt-merge-msg-leak:
fmt-merge-msg: plug small leak of commit buffer

Merge branch 'nd/slim-index-pack-memory-usage'Junio C Hamano Mon, 11 May 2015 21:23:44 +0000 (14:23 -0700)

Merge branch 'nd/slim-index-pack-memory-usage'

Memory usage of "git index-pack" has been trimmed by tens of
per-cent.

* nd/slim-index-pack-memory-usage:
index-pack: kill union delta_base to save memory
index-pack: reduce object_entry size to save memory

Merge branch 'jk/still-interesting'Junio C Hamano Mon, 11 May 2015 21:23:43 +0000 (14:23 -0700)

Merge branch 'jk/still-interesting'

"git rev-list --objects $old --not --all" to see if everything that
is reachable from $old is already connected to the existing refs
was very inefficient.

* jk/still-interesting:
limit_list: avoid quadratic behavior from still_interesting

Merge branch 'jk/reading-packed-refs'Junio C Hamano Mon, 11 May 2015 21:23:42 +0000 (14:23 -0700)

Merge branch 'jk/reading-packed-refs'

An earlier rewrite to use strbuf_getwholeline() instead of fgets(3)
to read packed-refs file revealed that the former is unacceptably
inefficient.

* jk/reading-packed-refs:
t1430: add another refs-escape test
read_packed_refs: avoid double-checking sane refs
strbuf_getwholeline: use getdelim if it is available
strbuf_getwholeline: avoid calling strbuf_grow
strbuf_addch: avoid calling strbuf_grow
config: use getc_unlocked when reading from file
strbuf_getwholeline: use getc_unlocked
git-compat-util: add fallbacks for unlocked stdio
strbuf_getwholeline: use getc macro

Merge branch 'lm/squelch-bg-progress'Junio C Hamano Mon, 11 May 2015 21:23:42 +0000 (14:23 -0700)

Merge branch 'lm/squelch-bg-progress'

Many long-running operations show progress eye-candy, even when
they are later backgrounded. Hide the eye-candy when the process
is sent to the background instead.

* lm/squelch-bg-progress:
compat/mingw: stubs for getpgid() and tcgetpgrp()
progress: no progress in background

Merge branch 'jk/sha1-file-reduce-useless-warnings'Junio C Hamano Mon, 11 May 2015 21:23:40 +0000 (14:23 -0700)

Merge branch 'jk/sha1-file-reduce-useless-warnings'

* jk/sha1-file-reduce-useless-warnings:
sha1_file: squelch "packfile cannot be accessed" warnings

Merge branch 'nd/multiple-work-trees'Junio C Hamano Mon, 11 May 2015 21:23:39 +0000 (14:23 -0700)

Merge branch 'nd/multiple-work-trees'

A replacement for contrib/workdir/git-new-workdir that does not
rely on symbolic links and make sharing of objects and refs safer
by making the borrowee and borrowers aware of each other.

* nd/multiple-work-trees: (41 commits)
prune --worktrees: fix expire vs worktree existence condition
t1501: fix test with split index
t2026: fix broken &&-chain
t2026 needs procondition SANITY
git-checkout.txt: a note about multiple checkout support for submodules
checkout: add --ignore-other-wortrees
checkout: pass whole struct to parse_branchname_arg instead of individual flags
git-common-dir: make "modules/" per-working-directory directory
checkout: do not fail if target is an empty directory
t2025: add a test to make sure grafts is working from a linked checkout
checkout: don't require a work tree when checking out into a new one
git_path(): keep "info/sparse-checkout" per work-tree
count-objects: report unused files in $GIT_DIR/worktrees/...
gc: support prune --worktrees
gc: factor out gc.pruneexpire parsing code
gc: style change -- no SP before closing parenthesis
checkout: clean up half-prepared directories in --to mode
checkout: reject if the branch is already checked out elsewhere
prune: strategies for linked checkouts
checkout: support checking out into a new working directory
...

Merge branch 'pt/credential-xdg'Junio C Hamano Mon, 11 May 2015 21:23:38 +0000 (14:23 -0700)

Merge branch 'pt/credential-xdg'

Tweak the sample "store" backend of the credential helper to honor
XDG configuration file locations when specified.

* pt/credential-xdg:
t0302: "unreadable" test needs POSIXPERM
t0302: test credential-store support for XDG_CONFIG_HOME
git-credential-store: support XDG_CONFIG_HOME
git-credential-store: support multiple credential files

First batch for 2.5 cycleJunio C Hamano Wed, 6 May 2015 04:13:30 +0000 (21:13 -0700)

First batch for 2.5 cycle

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/prune-mtime'Junio C Hamano Wed, 6 May 2015 04:00:37 +0000 (21:00 -0700)

Merge branch 'jk/prune-mtime'

Access to objects in repositories that borrow from another one on a
slow NFS server unnecessarily got more expensive due to recent code
becoming more cautious in a naive way not to lose objects to pruning.

* jk/prune-mtime:
sha1_file: only freshen packs once per run
sha1_file: freshen pack objects before loose
reachable: only mark local objects as recent

Merge branch 'mm/usage-log-l-can-take-regex'Junio C Hamano Wed, 6 May 2015 04:00:36 +0000 (21:00 -0700)

Merge branch 'mm/usage-log-l-can-take-regex'

Documentation fix.

* mm/usage-log-l-can-take-regex:
log -L: improve error message on malformed argument
Documentation: change -L:<regex> to -L:<funcname>

Merge branch 'ep/fix-test-lib-functions-report'Junio C Hamano Wed, 6 May 2015 04:00:35 +0000 (21:00 -0700)

Merge branch 'ep/fix-test-lib-functions-report'

* ep/fix-test-lib-functions-report:
test-lib-functions.sh: fix the second argument to some helper functions

Merge branch 'cn/bom-in-gitignore'Junio C Hamano Wed, 6 May 2015 04:00:34 +0000 (21:00 -0700)

Merge branch 'cn/bom-in-gitignore'

Teach the codepaths that read .gitignore and .gitattributes files
that these files encoded in UTF-8 may have UTF-8 BOM marker at the
beginning; this makes it in line with what we do for configuration
files already.

* cn/bom-in-gitignore:
attr: skip UTF8 BOM at the beginning of the input file
config: use utf8_bom[] from utf.[ch] in git_parse_source()
utf8-bom: introduce skip_utf8_bom() helper
add_excludes_from_file: clarify the bom skipping logic
dir: allow a BOM at the beginning of exclude files

Merge branch 'jc/epochtime-wo-tz'Junio C Hamano Wed, 6 May 2015 04:00:33 +0000 (21:00 -0700)

Merge branch 'jc/epochtime-wo-tz'

"git commit --date=now" or anything that relies on approxidate lost
the daylight-saving-time offset.

* jc/epochtime-wo-tz:
parse_date_basic(): let the system handle DST conversion
parse_date_basic(): return early when given a bogus timestamp

Merge branch 'nd/t1509-chroot-test'Junio C Hamano Wed, 6 May 2015 04:00:31 +0000 (21:00 -0700)

Merge branch 'nd/t1509-chroot-test'

Correct test bitrot.

* nd/t1509-chroot-test:
t1509: update prepare script to be able to run t1509 in chroot again

Merge branch 'oh/fix-config-default-user-name-section'Junio C Hamano Wed, 6 May 2015 04:00:30 +0000 (21:00 -0700)

Merge branch 'oh/fix-config-default-user-name-section'

The default $HOME/.gitconfig file created upon "git config --global"
that edits it had incorrectly spelled user.name and user.email
entries in it.

* oh/fix-config-default-user-name-section:
config: fix settings in default_user_config template

Merge branch 'jk/type-from-string-gently'Junio C Hamano Wed, 6 May 2015 04:00:29 +0000 (21:00 -0700)

Merge branch 'jk/type-from-string-gently'

"git cat-file bl $blob" failed to barf even though there is no
object type that is "bl".

* jk/type-from-string-gently:
type_from_string_gently: make sure length matches

Merge branch 'sb/test-bitmap-free-at-end'Junio C Hamano Wed, 6 May 2015 04:00:28 +0000 (21:00 -0700)

Merge branch 'sb/test-bitmap-free-at-end'

* sb/test-bitmap-free-at-end:
pack-bitmap.c: fix a memleak

Merge branch 'ld/p4-filetype-detection'Junio C Hamano Wed, 6 May 2015 04:00:27 +0000 (21:00 -0700)

Merge branch 'ld/p4-filetype-detection'

* ld/p4-filetype-detection:
git-p4: fix filetype detection on files opened exclusively
git-p4: small fix for locked-file-move-test
git-p4: fix small bug in locked test scripts

Merge branch 'ts/checkout-advice-plural'Junio C Hamano Wed, 6 May 2015 04:00:27 +0000 (21:00 -0700)

Merge branch 'ts/checkout-advice-plural'

* ts/checkout-advice-plural:
checkout: call a single commit "it" intead of "them"

Merge branch 'jk/init-core-worktree-at-root'Junio C Hamano Wed, 6 May 2015 04:00:26 +0000 (21:00 -0700)

Merge branch 'jk/init-core-worktree-at-root'

We avoid setting core.worktree when the repository location is the
".git" directory directly at the top level of the working tree, but
the code misdetected the case in which the working tree is at the
root level of the filesystem (which arguably is a silly thing to
do, but still valid).

* jk/init-core-worktree-at-root:
init: don't set core.worktree when initializing /.git

Merge branch 'mh/show-branch-topic'Junio C Hamano Wed, 6 May 2015 04:00:25 +0000 (21:00 -0700)

Merge branch 'mh/show-branch-topic'

"git show-branch --topics HEAD" (with no other arguments) did not
do anything interesting. Instead, contrast the given revision
against all the local branches by default.

* mh/show-branch-topic:
show-branch: show all local heads when only giving one rev along --topics

Merge branch 'sb/line-log-plug-pairdiff-leak'Junio C Hamano Wed, 6 May 2015 04:00:25 +0000 (21:00 -0700)

Merge branch 'sb/line-log-plug-pairdiff-leak'

* sb/line-log-plug-pairdiff-leak:
line-log.c: fix a memleak

Merge branch 'jc/diff-no-index-d-f'Junio C Hamano Wed, 6 May 2015 04:00:24 +0000 (21:00 -0700)

Merge branch 'jc/diff-no-index-d-f'

The usual "git diff" when seeing a file turning into a directory
showed a patchset to remove the file and create all files in the
directory, but "git diff --no-index" simply refused to work. Also,
when asked to compare a file and a directory, imitate POSIX "diff"
and compare the file with the file with the same name in the
directory, instead of refusing to run.

* jc/diff-no-index-d-f:
diff-no-index: align D/F handling with that of normal Git
diff-no-index: DWIM "diff D F" into "diff D/F F"

Merge branch 'bc/object-id'Junio C Hamano Wed, 6 May 2015 04:00:23 +0000 (21:00 -0700)

Merge branch 'bc/object-id'

Identify parts of the code that knows that we use SHA-1 hash to
name our objects too much, and use (1) symbolic constants instead
of hardcoded 20 as byte count and/or (2) use struct object_id
instead of unsigned char [20] for object names.

* bc/object-id:
apply: convert threeway_stage to object_id
patch-id: convert to use struct object_id
commit: convert parts to struct object_id
diff: convert struct combine_diff_path to object_id
bulk-checkin.c: convert to use struct object_id
zip: use GIT_SHA1_HEXSZ for trailers
archive.c: convert to use struct object_id
bisect.c: convert leaf functions to use struct object_id
define utility functions for object IDs
define a structure for object IDs

Git 2.4 v2.4.0Junio C Hamano Thu, 30 Apr 2015 18:25:06 +0000 (11:25 -0700)

Git 2.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mh/multimail-renewal'Junio C Hamano Tue, 28 Apr 2015 20:01:29 +0000 (13:01 -0700)

Merge branch 'mh/multimail-renewal'

* mh/multimail-renewal:
Update git-multimail to version 1.0.2

Merge branch 'mg/show-notes-doc'Junio C Hamano Tue, 28 Apr 2015 20:00:20 +0000 (13:00 -0700)

Merge branch 'mg/show-notes-doc'

Documentation fix.

* mg/show-notes-doc:
rev-list-options.txt: complete sentence about notes matching

Merge branch 'nd/versioncmp-prereleases'Junio C Hamano Tue, 28 Apr 2015 20:00:19 +0000 (13:00 -0700)

Merge branch 'nd/versioncmp-prereleases'

* nd/versioncmp-prereleases:
git tag: mention versionsort.prereleaseSuffix in manpage

Merge branch 'mg/status-v-v'Junio C Hamano Tue, 28 Apr 2015 20:00:18 +0000 (13:00 -0700)

Merge branch 'mg/status-v-v'

* mg/status-v-v:
status: document the -v/--verbose option

Update git-multimail to version 1.0.2Michael Haggerty Mon, 27 Apr 2015 11:17:25 +0000 (13:17 +0200)

Update git-multimail to version 1.0.2

The only changes are to the README files, most notably the list of
maintainers and the project URL.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with 2.3.7Junio C Hamano Mon, 27 Apr 2015 19:26:21 +0000 (12:26 -0700)

Sync with 2.3.7

Git 2.3.7 v2.3.7Junio C Hamano Mon, 27 Apr 2015 19:25:36 +0000 (12:25 -0700)

Git 2.3.7

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'tb/connect-ipv6-parse-fix' into maintJunio C Hamano Mon, 27 Apr 2015 19:23:53 +0000 (12:23 -0700)

Merge branch 'tb/connect-ipv6-parse-fix' into maint

An earlier update to the parser that disects a URL broke an
address, followed by a colon, followed by an empty string (instead
of the port number), e.g. ssh://example.com:/path/to/repo.

* tb/connect-ipv6-parse-fix:
connect.c: ignore extra colon after hostname

Merge branch 'ma/bash-completion-leaking-x' into maintJunio C Hamano Mon, 27 Apr 2015 19:23:51 +0000 (12:23 -0700)

Merge branch 'ma/bash-completion-leaking-x' into maint

The completion script (in contrib/) contaminated global namespace
and clobbered on a shell variable $x.

* ma/bash-completion-leaking-x:
completion: fix global bash variable leak on __gitcompappend

Merge branch 'jc/push-cert' into maintJunio C Hamano Mon, 27 Apr 2015 19:23:47 +0000 (12:23 -0700)

Merge branch 'jc/push-cert' into maint

The "git push --signed" protocol extension did not limit what the
"nonce" that is a server-chosen string can contain or how long it
can be, which was unnecessarily lax. Limit both the length and the
alphabet to a reasonably small space that can still have enough
entropy.

* jc/push-cert:
push --signed: tighten what the receiving end can ask to sign

t0027: Add repoMIX and LF_nulTorsten Bögershausen Sat, 25 Apr 2015 06:47:13 +0000 (08:47 +0200)

t0027: Add repoMIX and LF_nul

"new safer autocrlf handling":

- Check if eols in a file are converted at commit, when the file has
CR (or CRLF) in the repo (technically speaking in the index).
- Add a test-file repoMIX with mixed line-endings.
- When converting LF->CRLF or CRLF->LF: check the warnings

checkout_files():

- Checking out CRLF_nul and checking for eol coversion does not
make much sense (CRLF will stay CRLF).
- Use the file LF_nul instead: It is handled a binary in "auto" modes,
and when declared as text the LF may be replaced with CRLF, depending
on the configuration.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

status: document the -v/--verbose optionMichael Haggerty Thu, 23 Apr 2015 12:27:46 +0000 (14:27 +0200)

status: document the -v/--verbose option

Document `git status -v`, including its new doubled `-vv` form.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: wordsmithingMichael Haggerty Thu, 23 Apr 2015 12:27:50 +0000 (14:27 +0200)

RelNotes: wordsmithing

Make many textual tweaks to the 2.4.0 release notes.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: refer to the rebase -i "todo list", not ... Michael Haggerty Thu, 23 Apr 2015 12:27:49 +0000 (14:27 +0200)

RelNotes: refer to the rebase -i "todo list", not "insn sheet"

"Todo list" is the name that is used in the user-facing documentation.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: correct name of versionsort.prereleaseSuffixMichael Haggerty Thu, 23 Apr 2015 12:27:48 +0000 (14:27 +0200)

RelNotes: correct name of versionsort.prereleaseSuffix

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git tag: mention versionsort.prereleaseSuffix in manpageMichael Haggerty Thu, 23 Apr 2015 12:27:47 +0000 (14:27 +0200)

git tag: mention versionsort.prereleaseSuffix in manpage

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.4.0-rc3 v2.4.0-rc3Junio C Hamano Wed, 22 Apr 2015 20:52:43 +0000 (13:52 -0700)

Git 2.4.0-rc3

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with maintJunio C Hamano Tue, 21 Apr 2015 19:58:50 +0000 (12:58 -0700)

Sync with maint

Git 2.3.6 v2.3.6Junio C Hamano Tue, 21 Apr 2015 19:17:09 +0000 (12:17 -0700)

Git 2.3.6

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/colors' into maintJunio C Hamano Tue, 21 Apr 2015 19:12:25 +0000 (12:12 -0700)

Merge branch 'jk/colors' into maint

"diff-highlight" (in contrib/) used to show byte-by-byte
differences, which meant that multi-byte characters can be chopped
in the middle. It learned to pay attention to character boundaries
(assuming the UTF-8 payload).

* jk/colors:
diff-highlight: do not split multibyte characters

Merge branch 'jk/test-annoyances' into maintJunio C Hamano Tue, 21 Apr 2015 19:12:24 +0000 (12:12 -0700)

Merge branch 'jk/test-annoyances' into maint

Test fixes.

* jk/test-annoyances:
t5551: make EXPENSIVE test cheaper
t5541: move run_with_cmdline_limit to test-lib.sh
t: pass GIT_TRACE through Apache
t: redirect stderr GIT_TRACE to descriptor 4
t: translate SIGINT to an exit

Merge branch 'pt/enter-repo-comment-fix' into maintJunio C Hamano Tue, 21 Apr 2015 19:12:23 +0000 (12:12 -0700)

Merge branch 'pt/enter-repo-comment-fix' into maint

Documentation update.

* pt/enter-repo-comment-fix:
enter_repo(): fix docs to match code

Merge branch 'jz/gitweb-conf-doc-fix' into maintJunio C Hamano Tue, 21 Apr 2015 19:12:22 +0000 (12:12 -0700)

Merge branch 'jz/gitweb-conf-doc-fix' into maint

Documentation update.

* jz/gitweb-conf-doc-fix:
gitweb.conf.txt: say "build-time", not "built-time"

Merge branch 'jk/cherry-pick-docfix' into maintJunio C Hamano Tue, 21 Apr 2015 19:12:21 +0000 (12:12 -0700)

Merge branch 'jk/cherry-pick-docfix' into maint

* jk/cherry-pick-docfix:
cherry-pick: fix docs describing handling of empty commits

Merge branch 'iu/fix-parse-options-h-comment' into... Junio C Hamano Tue, 21 Apr 2015 19:12:20 +0000 (12:12 -0700)

Merge branch 'iu/fix-parse-options-h-comment' into maint

* iu/fix-parse-options-h-comment:
parse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval

Merge branch 'jg/cguide-we-cannot-count' into maintJunio C Hamano Tue, 21 Apr 2015 19:12:19 +0000 (12:12 -0700)

Merge branch 'jg/cguide-we-cannot-count' into maint

* jg/cguide-we-cannot-count:
CodingGuidelines: update 'rough' rule count

Merge branch 'jk/pack-corruption-post-mortem' into... Junio C Hamano Tue, 21 Apr 2015 19:12:18 +0000 (12:12 -0700)

Merge branch 'jk/pack-corruption-post-mortem' into maint

Documentation update.

* jk/pack-corruption-post-mortem:
howto: document more tools for recovery corruption

Merge branch 'jn/doc-fast-import-no-16-octopus-limit... Junio C Hamano Tue, 21 Apr 2015 19:12:17 +0000 (12:12 -0700)

Merge branch 'jn/doc-fast-import-no-16-octopus-limit' into maint

Documentation update.

* jn/doc-fast-import-no-16-octopus-limit:
fast-import doc: remove suggested 16-parent limit

RelNotes: "merge --quiet" change has been revertedJunio C Hamano Tue, 21 Apr 2015 18:09:19 +0000 (11:09 -0700)

RelNotes: "merge --quiet" change has been reverted

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Hopefully the last batch for 2.4Junio C Hamano Mon, 20 Apr 2015 22:30:13 +0000 (15:30 -0700)

Hopefully the last batch for 2.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ps/grep-help-all-callback-arg'Junio C Hamano Mon, 20 Apr 2015 22:28:34 +0000 (15:28 -0700)

Merge branch 'ps/grep-help-all-callback-arg'

Code clean-up.

* ps/grep-help-all-callback-arg:
grep: correctly initialize help-all option

Merge branch 'tb/connect-ipv6-parse-fix'Junio C Hamano Mon, 20 Apr 2015 22:28:33 +0000 (15:28 -0700)

Merge branch 'tb/connect-ipv6-parse-fix'

An earlier update to the parser that disects an address broke an
address, followed by a colon, followed by an empty string (instead
of the port number).

* tb/connect-ipv6-parse-fix:
connect.c: ignore extra colon after hostname

Merge branch 'va/fix-git-p4-tests'Junio C Hamano Mon, 20 Apr 2015 22:28:32 +0000 (15:28 -0700)

Merge branch 'va/fix-git-p4-tests'

Test fixes for git-p4.

* va/fix-git-p4-tests:
t9814: guarantee only one source exists in git-p4 copy tests
git-p4: fix copy detection test
t9814: fix broken shell syntax in git-p4 rename test

Merge branch 'jc/push-cert'Junio C Hamano Mon, 20 Apr 2015 22:28:31 +0000 (15:28 -0700)

Merge branch 'jc/push-cert'

The "git push --signed" protocol extension did not limit what the
"nonce" that is a server-chosen string can contain or how long it
can be, which was unnecessarily lax. Limit both the length and the
alphabet to a reasonably small space that can still have enough
entropy.

* jc/push-cert:
push --signed: tighten what the receiving end can ask to sign

Merge branch 'ma/bash-completion-leaking-x'Junio C Hamano Mon, 20 Apr 2015 22:28:29 +0000 (15:28 -0700)

Merge branch 'ma/bash-completion-leaking-x'

The completion script (in contrib/) contaminated global namespace
and clobbered on a shell variable $x.

* ma/bash-completion-leaking-x:
completion: fix global bash variable leak on __gitcompappend

fmt-merge-msg: plug small leak of commit bufferJunio C Hamano Wed, 15 Apr 2015 21:18:37 +0000 (14:18 -0700)

fmt-merge-msg: plug small leak of commit buffer

A broken or badly formatted commit might not record author or
committer lines or we may not find a valid name on them. The
function record_person() returned after calling get_commit_buffer()
without calling unuse_commit_buffer() on the memory it obtained in
such cases, potentially leaking it.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_file: only freshen packs once per runJeff King Mon, 20 Apr 2015 19:55:00 +0000 (15:55 -0400)

sha1_file: only freshen packs once per run

Since 33d4221 (write_sha1_file: freshen existing objects,
2014-10-15), we update the mtime of existing objects that we
would have written out (had they not existed). For the
common case in which many objects are packed, we may update
the mtime on a single packfile repeatedly. This can result
in a noticeable performance problem if calling utime() is
expensive (e.g., because your storage is on NFS).

We can fix this by keeping a per-pack flag that lets us
freshen only once per program invocation.

An alternative would be to keep the packed_git.mtime flag up
to date as we freshen, and freshen only once every N
seconds. In practice, it's not worth the complexity. We are
racing against prune expiration times here, which inherently
must be set to accomodate reasonable program running times
(because they really care about the time between an object
being written and it becoming referenced, and the latter is
typically the last step a program takes).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_file: freshen pack objects before looseJeff King Mon, 20 Apr 2015 19:54:03 +0000 (15:54 -0400)

sha1_file: freshen pack objects before loose

When writing out an object file, we first check whether it
already exists and if so optimize out the write. Prior to
33d4221, we did this by calling has_sha1_file(), which will
check for packed objects followed by loose. Since that
commit, we check loose objects first.

For the common case of a repository whose objects are mostly
packed, this means we will make a lot of extra access()
system calls checking for loose objects. We should follow
the same packed-then-loose order that all of our other
lookups use.

Reported-by: Stefan Saasen <ssaasen@atlassian.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reachable: only mark local objects as recentJeff King Fri, 27 Mar 2015 11:32:41 +0000 (07:32 -0400)

reachable: only mark local objects as recent

When pruning and repacking a repository that has an
alternate object store configured, we may traverse a large
number of objects in the alternate. This serves no purpose,
and may be expensive to do. A longer explanation is below.

Commits d3038d2 and abcb865 taught prune and pack-objects
(respectively) to treat "recent" objects as tips for
reachability, so that we keep whole chunks of history. They
built on the object traversal in 660c889 (sha1_file: add
for_each iterators for loose and packed objects,
2014-10-15), which covers both local and alternate objects.

In both cases, covering alternate objects is unnecessary, as
both commands can only drop objects from the local
repository. In the case of prune, we traverse only the local
object directory. And in the case of repacking, while we may
or may not include local objects in our pack, we will never
reach into the alternate with "repack -d". The "-l" option
is only a question of whether we are migrating objects from
the alternate into our repository, or leaving them
untouched.

It is possible that we may drop an object that is depended
upon by another object in the alternate. For example,
imagine two repositories, A and B, with A pointing to B as
an alternate. Now imagine a commit that is in B which
references a tree that is only in A. Traversing from recent
objects in B might prevent A from dropping that tree. But
this case isn't worth covering. Repo B should take
responsibility for its own objects. It would never have had
the commit in the first place if it did not also have the
tree, and assuming it is using the same "keep recent chunks
of history" scheme, then it would itself keep the tree, as
well.

So checking the alternate objects is not worth doing, and
come with a significant performance impact. In both cases,
we skip any recent objects that have already been marked
SEEN (i.e., that we know are already reachable for prune, or
included in the pack for a repack). So there is a slight
waste of time in opening the alternate packs at all, only to
notice that we have already considered each object. But much
worse, the alternate repository may have a large number of
objects that are not reachable from the local repository at
all, and we end up adding them to the traversal.

We can fix this by considering only local unseen objects.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: use -m when running p4 changesLex Spoon Mon, 20 Apr 2015 15:00:20 +0000 (11:00 -0400)

git-p4: use -m when running p4 changes

Simply running "p4 changes" on a large branch can result in a "too
many rows scanned" error from the Perforce server. It is better to
use a sequence of smaller calls to "p4 changes", using the "-m"
option to limit the size of each call.

Signed-off-by: Lex Spoon <lex@lexspoon.org>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log -L: improve error message on malformed argumentMatthieu Moy Mon, 20 Apr 2015 12:09:07 +0000 (14:09 +0200)

log -L: improve error message on malformed argument

The old message did not mention the :regex:file form.

To avoid overly long lines, split the message into two lines (in case
item->string is long, it will be the only part truncated in a narrow
terminal).

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: change -L:<regex> to -L:<funcname>Matthieu Moy Mon, 20 Apr 2015 12:09:06 +0000 (14:09 +0200)

Documentation: change -L:<regex> to -L:<funcname>

The old wording was somehow implying that <start> and <end> were not
regular expressions. Also, the common case is to use a plain function
name here so <funcname> makes sense (the fact that it is a regular
expression is documented in line-range-format.txt).

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge tag 'gitgui-0.20.0' of repo.or.cz/r/git-guiJunio C Hamano Sun, 19 Apr 2015 01:35:48 +0000 (18:35 -0700)

Merge tag 'gitgui-0.20.0' of repo.or.cz/r/git-gui

git-gui 0.20.0

* tag 'gitgui-0.20.0' of http://repo.or.cz/r/git-gui:
git-gui: set version 0.20
git-gui: sv.po: Update Swedish translation (547t0f0u)
git-gui i18n: Updated Bulgarian translation (547t,0f,0u)
git-gui: Makes chooser set 'gitdir' to the resolved path
git-gui: Fixes chooser not accepting gitfiles
git-gui: reinstate support for Tcl 8.4
git-gui: fix problem with gui.maxfilesdisplayed
git-gui: fix verbose loading when git path contains spaces.
git-gui/gitk: Do not depend on Cygwin's "kill" command on Windows
git-gui: add configurable tab size to the diff view
git-gui: Make git-gui lib dir configurable at runime
git-gui i18n: Updated Bulgarian translation (520t,0f,0u)
L10n: vi.po (543t): Init translation for Vietnamese
git-gui: align the new recursive checkbox with the radiobuttons.
git-gui: Add a 'recursive' checkbox in the clone menu.

t1509: update prepare script to be able to run t1509... Nguyễn Thái Ngọc Duy Sat, 18 Apr 2015 11:22:53 +0000 (18:22 +0700)

t1509: update prepare script to be able to run t1509 in chroot again

Tested on Gentoo and OpenSUSE 13.1, both x86-64

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

index-pack: kill union delta_base to save memoryNguyễn Thái Ngọc Duy Sat, 18 Apr 2015 10:47:05 +0000 (17:47 +0700)

index-pack: kill union delta_base to save memory

Once we know the number of objects in the input pack, we allocate an
array of nr_objects of struct delta_entry. On x86-64, this struct is
32 bytes long. The union delta_base, which is part of struct
delta_entry, provides enough space to store either ofs-delta (8 bytes)
or ref-delta (20 bytes).

Because ofs-delta encoding is more efficient space-wise and more
performant at runtime than ref-delta encoding, Git packers try to use
ofs-delta whenever possible, and it is expected that objects encoded
as ref-delta are minority.

In the best clone case where no ref-delta object is present, we waste
(20-8) * nr_objects bytes because of this union. That's about 38MB out
of 100MB for deltas[] with 3.4M objects, or 38%. deltas[] would be
around 62MB without the waste.

This patch attempts to eliminate that. deltas[] array is split into
two: one for ofs-delta and one for ref-delta. Many functions are also
duplicated because of this split. With this patch, ofs_deltas[] array
takes 51MB. ref_deltas[] should remain unallocated in clone case (0
bytes). This array grows as we see ref-delta. We save about half in
this case, or 25% of total bookkeeping.

The saving is more than the calculation above because some padding in
the old delta_entry struct is removed. ofs_delta_entry is 16 bytes,
including the 4 bytes padding. That's 13MB for padding, but packing
the struct could break platforms that do not support unaligned
access. If someone on 32-bit is really low on memory and only deals
with packs smaller than 2G, using 32-bit off_t would eliminate the
padding and save 27MB on top.

A note about ofs_deltas allocation. We could use ref_deltas memory
allocation strategy for ofs_deltas. But that probably just adds more
overhead on top. ofs-deltas are generally the majority (1/2 to 2/3) in
any pack. Incremental realloc may lead to too many memcpy. And if we
preallocate, say 1/2 or 2/3 of nr_objects initially, the growth rate
of ALLOC_GROW() could make this array larger than nr_objects, wasting
more memory.

Brought-up-by: Matthew Sporleder <msporleder@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0027: support NATIVE_CRLF platformsTorsten Bögershausen Fri, 17 Apr 2015 15:44:05 +0000 (17:44 +0200)

t0027: support NATIVE_CRLF platforms

t0027 expects the native end-of-lines to be a single line feed
character. On Windows, however, we set it to a carriage return
character followed by a line feed character. Thus, we have to
modify t0027 to expect different warnings depending on the
end-of-line markers.

Adjust the check of the warnings and use these macros:

WILC: Warn if LF becomes CRLF
WICL: Warn if CRLF becomes LF
WAMIX: Mixed line endings: either CRLF->LF or LF->CRLF

Improve the information given by check_warning().

Use test_cmp to show which warning is missing (or shouldn't be
there).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0027: cleanup: rename functions; avoid non-leading... Torsten Bögershausen Fri, 17 Apr 2015 15:43:43 +0000 (17:43 +0200)

t0027: cleanup: rename functions; avoid non-leading TABs

Make more clear what the tests are doing:

commit_check_warn():
Commit files and checks for conversion warnings.
Old name: create_file_in_repo()

checkout_files():
Checkout files from the repo and check if they have
the appropriate line endings in the work space.
Old name: check_files_in_ws()

Replace non-leading TABS with spaces

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: set version 0.20 gitgui-0.20.0Pat Thoyts Sat, 18 Apr 2015 11:15:32 +0000 (12:15 +0100)

git-gui: set version 0.20

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

git-gui: sv.po: Update Swedish translation (547t0f0u)Peter Krefting Fri, 27 Mar 2015 09:25:32 +0000 (10:25 +0100)

git-gui: sv.po: Update Swedish translation (547t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

git-gui i18n: Updated Bulgarian translation (547t,0f,0u)Alexander Shopov Tue, 7 Apr 2015 15:29:46 +0000 (18:29 +0300)

git-gui i18n: Updated Bulgarian translation (547t,0f,0u)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

limit_list: avoid quadratic behavior from still_interestingJeff King Fri, 17 Apr 2015 22:11:04 +0000 (18:11 -0400)

limit_list: avoid quadratic behavior from still_interesting

When we are limiting a rev-list traversal due to
UNINTERESTING refs, we have to walk down the tips (both
interesting and uninteresting) to find where they intersect.
We keep a queue of commits to examine, pop commits off
the queue one by one, and potentially add their parents. The
size of the queue will naturally fluctuate based on the
"width" of the history graph; i.e., the number of
simultaneous lines of development. But for the most part it
will stay in the same ballpark as the initial number of tips
we fed, shrinking over time (as we hit common ancestors of
the tips). So roughly speaking, if we start with `N` tips,
we'll spend much of the time with a queue around `N` items.

For each UNINTERESTING commit we pop, we call
still_interesting to check whether marking its parents as
UNINTERESTING has made the whole queue uninteresting (in
which case we can quit early). Because the queue is stored
as a linked list, this is `O(N)`, where `N` is the number of
items in the queue. So processing a queue with `N` commits
marked UNINTERESTING (and one or more interesting commits)
will take `O(N^2)`.

If you feed a lot of positive tips, this isn't a problem.
They aren't UNINTERESTING, so they don't incur the
still_interesting check. It also isn't a problem if you
traverse from an interesting tip to some UNINTERESTING
bases. We order the queue by recency, so the interesting
commits stay at the front of the queue as we walk down them.
The linear check can exit early as soon as it sees one
interesting commit left in the queue.

But if you want to know whether an older commit is reachable
from a set of newer tips, we end up processing in the
opposite direction: from the UNINTERESTING ones down to the
interesting one. This may happen when we call:

git rev-list $commits --not --all

in check_everything_connected after a fetch. If we fetched
something much older than most of our refs, and if we have a
large number of refs, the traversal cost is dominated by the
quadratic behavior.

These commands simulate the connectivity check of such a
fetch, when you have `$n` distinct refs in the receiver:

# positive ref is 100,000 commits deep
git rev-list --all | head -100000 | tail -1 >input

# huge number of more recent negative refs
git rev-list --all | head -$n | sed s/^/^/ >>input

time git rev-list --stdin <input

Here are timings for various `n` on the linux.git
repository. The `n=1` case provides a baseline for just
walking the commits, which lets us see the still_interesting
overhead. The times marked with `+` subtract that baseline
to show just the extra time growth due to the large number
of refs. The `x` numbers show the slowdown of the adjusted
time versus the prior trial.

n | before | after
--------------------------------------------------------
1 | 0.991s | 0.848s
10000 | 1.120s (+0.129s) | 0.885s (+0.037s)
20000 | 1.451s (+0.460s, 3.5x) | 0.923s (+0.075s, 2.0x)
40000 | 2.731s (+1.740s, 3.8x) | 0.994s (+0.146s, 1.9x)
80000 | 8.235s (+7.244s, 4.2x) | 1.123s (+0.275s, 1.9x)

Each trial doubles `n`, so you can see the quadratic (`4x`)
behavior before this patch. Afterwards, we have a roughly
linear relationship.

The implementation is fairly straightforward. Whenever we do
the linear search, we cache the interesting commit we find,
and next time check it before doing another linear search.
If that commit is removed from the list or becomes
UNINTERESTING itself, then we fall back to the linear
search. This is very similar to the trick used by fce87ae
(Fix quadratic performance in rewrite_one., 2008-07-12).

I considered and rejected several possible alternatives:

1. Keep a count of UNINTERESTING commits in the queue.
This requires managing the count not only when removing
an item from the queue, but also when marking an item
as UNINTERESTING. That requires touching the other
functions which mark commits, and would require knowing
quickly which commits are in the queue (lookup in the
queue is linear, so we would need an auxiliary
structure or to also maintain an IN_QUEUE flag in each
commit object).

2. Keep a separate list of interesting commits. Drop items
from it when they are dropped from the queue, or if
they become UNINTERESTING. This again suffers from
extra complexity to maintain the list, not to mention
CPU and memory.

3. Use a better data structure for the queue. This is
something that could help the fix in fce87ae, because
we order the queue by recency, and it is about
inserting quickly in recency order. So a normal
priority queue would help there. But here, we cannot
disturb the order of the queue, which makes things
harder. We really do need an auxiliary index to track
the flag we care about, which is basically option (2)
above.

The "cache" trick is simple, and the numbers above show that
it works well in practice. This is because the length of
time it takes to find an interesting commit is proportional
to the length of time it will remain cached (i.e., if we
have to walk a long way to find it, it also means we have to
pop a lot of elements in the queue until we get rid of it
and have to find another interesting commit).

The worst case is still quadratic, though. We could have `N`
uninteresting commits at the front of the queue, followed by
`N` interesting commits, where commit `i` has parent `i+N`.
When we pop commit `i`, we will notice that the parent of
the next commit, `i+1+N` is still interesting and cache it.
But then handling commit `i+1`, we will mark its parent
`i+1+N` uninteresting, and immediately invalidate our cache.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

type_from_string_gently: make sure length matchesJeff King Fri, 17 Apr 2015 14:52:48 +0000 (10:52 -0400)

type_from_string_gently: make sure length matches

When commit fe8e3b7 refactored type_from_string to allow
input that was not NUL-terminated, it switched to using
strncmp instead of strcmp. But this means we check only the
first "len" bytes of the strings, and ignore any remaining
bytes in the object_type_string. We should make sure that it
is also "len" bytes, or else we would accept "comm" as
"commit", and so forth.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: fix settings in default_user_config templateOssi Herrala Fri, 17 Apr 2015 14:50:10 +0000 (17:50 +0300)

config: fix settings in default_user_config template

The name (not user) and email setting should be in config section
"user" and not in "core" as documented in Documentation/config.txt.

Signed-off-by: Ossi Herrala <oherrala@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-list-options.txt: complete sentence about notes... Michael J Gruber Fri, 17 Apr 2015 14:28:56 +0000 (16:28 +0200)

rev-list-options.txt: complete sentence about notes matching

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash -p: demonstrate failure of split with mixed y/nMatthieu Moy Thu, 16 Apr 2015 07:02:31 +0000 (09:02 +0200)

stash -p: demonstrate failure of split with mixed y/n

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3904-stash-patch: factor PERL prereq at the top of... Matthieu Moy Thu, 16 Apr 2015 07:02:30 +0000 (09:02 +0200)

t3904-stash-patch: factor PERL prereq at the top of the file

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3904-stash-patch: fix test descriptionMatthieu Moy Thu, 16 Apr 2015 07:02:29 +0000 (09:02 +0200)

t3904-stash-patch: fix test description

The old description is rather clearly a wrong cut-and-paste from
t2016-checkout-patch.sh.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add -p: demonstrate failure when running 'edit' after... Matthieu Moy Thu, 16 Apr 2015 07:02:28 +0000 (09:02 +0200)

add -p: demonstrate failure when running 'edit' after a split

The test passes if one replaces the 'e' command with a 'y' command in
the 'add -p' session.

Reported-by: Tanky Woo <wtq1990@gmail.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3701-add-interactive: simplify codeMatthieu Moy Thu, 16 Apr 2015 07:02:27 +0000 (09:02 +0200)

t3701-add-interactive: simplify code

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib-functions.sh: fix the second argument to some... Elia Pinto Thu, 16 Apr 2015 14:12:07 +0000 (07:12 -0700)

test-lib-functions.sh: fix the second argument to some helper functions

The second argument to test_path_is_file and test_path_is_dir
must be $2 and not $*, which instead would repeat the file
name in the error message.

Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

attr: skip UTF8 BOM at the beginning of the input fileJunio C Hamano Thu, 16 Apr 2015 17:48:58 +0000 (10:48 -0700)

attr: skip UTF8 BOM at the beginning of the input file

Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: use utf8_bom[] from utf.[ch] in git_parse_source()Junio C Hamano Thu, 16 Apr 2015 17:47:45 +0000 (10:47 -0700)

config: use utf8_bom[] from utf.[ch] in git_parse_source()

Because the function reads one character at the time, unfortunately
we cannot use the easier skip_utf8_bom() helper, but at least we do
not have to duplicate the constant string this way.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

utf8-bom: introduce skip_utf8_bom() helperJunio C Hamano Thu, 16 Apr 2015 17:45:29 +0000 (10:45 -0700)

utf8-bom: introduce skip_utf8_bom() helper

With the recent change to ignore the UTF8 BOM at the beginning of
.gitignore files, we now have two codepaths that do such a skipping
(the other one is for reading the configuration files).

Introduce utf8_bom[] constant string and skip_utf8_bom() helper
and teach .gitignore code how to use it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

add_excludes_from_file: clarify the bom skipping logicJunio C Hamano Thu, 16 Apr 2015 18:26:29 +0000 (11:26 -0700)

add_excludes_from_file: clarify the bom skipping logic

Even though the previous step shifts where the "entry" begins, we
still iterate over the original buf[], which may begin with the
UTF-8 BOM we are supposed to be skipping. At the end of the first
line, the code grabs the contents of it starting at "entry", so
there is nothing wrong per-se, but the logic looks really confused.

Instead, move the buf pointer and shrink its size, to truly
pretend that UTF-8 BOM did not exist in the input.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir: allow a BOM at the beginning of exclude filesCarlos Martín Nieto Thu, 16 Apr 2015 14:05:12 +0000 (16:05 +0200)

dir: allow a BOM at the beginning of exclude files

Some text editors like Notepad or LibreOffice write an UTF-8 BOM in
order to indicate that the file is Unicode text rather than whatever the
current locale would indicate.

If someone uses such an editor to edit a gitignore file, we are left
with those three bytes at the beginning of the file. If we do not skip
them, we will attempt to match a filename with the BOM as prefix, which
won't match the files the user is expecting.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1430: add another refs-escape testJeff King Thu, 16 Apr 2015 09:04:44 +0000 (05:04 -0400)

t1430: add another refs-escape test

In t1430, we check whether deleting the branch "../../foo"
will delete ".git/foo". However, this is not that
interesting a test; the precious file ".git/foo" does not
look like a ref, so even if we did not notice the "escape"
from the "refs/" hierarchy, we would fail for that reason
(i.e., if you turned refname_is_safe into a noop, the test
still passes).

Let's add an additional test for the same thing, but with a
file that actually looks like a ref. That will make sure we
are exercising the refname_is_safe code. While we're at it,
let's also make the code work a little harder by adding some
extra paths and some empty path components.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

read_packed_refs: avoid double-checking sane refsJeff King Thu, 16 Apr 2015 09:03:26 +0000 (05:03 -0400)

read_packed_refs: avoid double-checking sane refs

Prior to d0f810f (refs.c: allow listing and deleting badly
named refs, 2014-09-03), read_packed_refs would barf on any
malformed refnames by virtue of calling create_ref_entry
with the "check" parameter set to 1. That commit loosened
our reading so that we call check_refname_format ourselves
and just set a REF_BAD_NAME flag.

We then call create_ref_entry with the check parameter set
to 0. That function learned to do an extra safety check even
when the check parameter is 0, so that we don't load any
dangerous refnames (like "../../../etc/passwd"). This is
implemented by calling refname_is_safe() in
create_ref_entry().

However, we can observe that refname_is_safe() can only be
true if check_refname_format() also failed. So in the common
case of a sanely named ref, we perform _both_ checks, even
though we know that the latter will never trigger. This has
a noticeable performance impact when the packed-refs file is
large.

Let's drop the refname_is_safe check from create_ref_entry(),
and make it the responsibility of the caller. Of the three
callers that pass a check parameter of "0", two will have
just called check_refname_format(), and can check the
refname-safety only when it fails. The third case,
pack_if_possible_fn, is copying from an existing ref entry,
which must have previously passed our safety check.

With this patch, running "git rev-parse refs/heads/does-not-exist"
on a repo with a large (1.6GB) packed-refs file went from:

real 0m6.768s
user 0m6.340s
sys 0m0.432s

to:

real 0m5.703s
user 0m5.276s
sys 0m0.432s

for a wall-clock speedup of 15%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf_getwholeline: use getdelim if it is availableJeff King Thu, 16 Apr 2015 09:01:38 +0000 (05:01 -0400)

strbuf_getwholeline: use getdelim if it is available

We spend a lot of time in strbuf_getwholeline in a tight
loop reading characters from a stdio handle into a buffer.
The libc getdelim() function can do this for us with less
overhead. It's in POSIX.1-2008, and was a GNU extension
before that. Therefore we can't rely on it, but can fall
back to the existing getc loop when it is not available.

The HAVE_GETDELIM knob is turned on automatically for Linux,
where we have glibc. We don't need to set any new
feature-test macros, because we already define _GNU_SOURCE.
Other systems that implement getdelim may need to other
macros (probably _POSIX_C_SOURCE >= 200809L), but we can
address that along with setting the Makefile knob after
testing the feature on those systems.

Running "git rev-parse refs/heads/does-not-exist" on a repo
with an extremely large (1.6GB) packed-refs file went from
(best-of-5):

real 0m8.601s
user 0m8.084s
sys 0m0.524s

to:

real 0m6.768s
user 0m6.340s
sys 0m0.432s

for a wall-clock speedup of 21%.

Based on a patch from Rasmus Villemoes <rv@rasmusvillemoes.dk>.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf_getwholeline: avoid calling strbuf_growJeff King Thu, 16 Apr 2015 08:58:54 +0000 (04:58 -0400)

strbuf_getwholeline: avoid calling strbuf_grow

As with the recent speedup to strbuf_addch, we can avoid
calling strbuf_grow() in a tight loop of single-character
adds by instead checking strbuf_avail.

Note that we would instead call strbuf_addch directly here,
but it does more work than necessary: it will NUL-terminate
the result for each character read. Instead, in this loop we
read the characters one by one and then add the terminator
manually at the end.

Running "git rev-parse refs/heads/does-not-exist" on a repo
with an extremely large (1.6GB) packed-refs file went from
(best-of-5):

real 0m10.948s
user 0m10.548s
sys 0m0.412s

to:

real 0m8.601s
user 0m8.084s
sys 0m0.524s

for a wall-clock speedup of 21%.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf_addch: avoid calling strbuf_growJeff King Thu, 16 Apr 2015 08:53:56 +0000 (04:53 -0400)

strbuf_addch: avoid calling strbuf_grow

We mark strbuf_addch as inline, because we expect it may be
called from a tight loop. However, the first thing it does
is call the non-inline strbuf_grow(), which can handle
arbitrary-sized growth. Since we know that we only need a
single character, we can use the inline strbuf_avail() to
quickly check whether we need to grow at all.

Our check is redundant when we do call strbuf_grow(), but
that's OK. The common case is that we avoid calling it at
all, and we have made that case faster.

On a silly pathological case:

perl -le '
print "[core]";
print "key$_ = value$_" for (1..1000000)
' >input
git config -f input core.key1

this dropped the time to run git-config from:

real 0m0.159s
user 0m0.152s
sys 0m0.004s

to:

real 0m0.140s
user 0m0.136s
sys 0m0.004s

for a savings of 12%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: use getc_unlocked when reading from fileJeff King Thu, 16 Apr 2015 08:51:18 +0000 (04:51 -0400)

config: use getc_unlocked when reading from file

We read config files character-by-character from a stdio
handle using fgetc(). This incurs significant locking
overhead, even though we know that only one thread can
possibly access the handle. We can speed this up by taking
the lock ourselves, and then using getc_unlocked to read
each character.

On a silly pathological case:

perl -le '
print "[core]";
print "key$_ = value$_" for (1..1000000)
' >input
git config -f input core.key1

this dropped the time to run git-config from:

real 0m0.263s
user 0m0.260s
sys 0m0.000s

to:

real 0m0.159s
user 0m0.152s
sys 0m0.004s

for a savings of 39%. Most config files are not this big,
but the savings should be proportional to the size of the
file (i.e., we always save 39%, just of a much smaller
number).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>