Junio C Hamano [Fri, 22 May 2015 19:41:52 +0000 (12:41 -0700)]
Merge branch 'mh/write-refs-sooner-2.4'
Multi-ref transaction support we merged a few releases ago
unnecessarily kept many file descriptors open, risking to fail with
resource exhaustion. This is for 2.4.x track.
* mh/write-refs-sooner-2.4:
ref_transaction_commit(): fix atomicity and avoid fd exhaustion
ref_transaction_commit(): remove the local flags variable
ref_transaction_commit(): inline call to write_ref_sha1()
rename_ref(): inline calls to write_ref_sha1() from this function
commit_ref_update(): new function, extracted from write_ref_sha1()
write_ref_to_lockfile(): new function, extracted from write_ref_sha1()
t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
update-ref: test handling large transactions properly
ref_transaction_commit(): fix atomicity and avoid fd exhaustion
ref_transaction_commit(): remove the local flags variable
ref_transaction_commit(): inline call to write_ref_sha1()
rename_ref(): inline calls to write_ref_sha1() from this function
commit_ref_update(): new function, extracted from write_ref_sha1()
write_ref_to_lockfile(): new function, extracted from write_ref_sha1()
t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
update-ref: test handling large transactions properly
Junio C Hamano [Fri, 22 May 2015 19:41:51 +0000 (12:41 -0700)]
Merge branch 'mg/log-decorate-HEAD'
The "log --decorate" enhancement in Git 2.4 that shows the commit
at the tip of the current branch e.g. "HEAD -> master", did not
work with --decorate=full.
* mg/log-decorate-HEAD:
log: do not shorten decoration names too early
log: decorate HEAD with branch name under --decorate=full, too
Junio C Hamano [Fri, 22 May 2015 19:41:50 +0000 (12:41 -0700)]
Merge branch 'jk/asciidoc-markup-fix'
Various documentation mark-up fixes to make the output more
consistent in general and also make AsciiDoctor (an alternative
formatter) happier.
* jk/asciidoc-markup-fix:
doc: convert AsciiDoc {?foo} to ifdef::foo[]
doc: put example URLs and emails inside literal backticks
doc: drop backslash quoting of some curly braces
doc: convert \--option to --option
doc/add: reformat `--edit` option
doc: fix length of underlined section-title
doc: fix hanging "+"-continuation
doc: fix unquoted use of "{type}"
doc: fix misrendering due to `single quote'
Junio C Hamano [Tue, 19 May 2015 20:17:59 +0000 (13:17 -0700)]
Merge branch 'sb/ref-lock-lose-lock-fd'
The refs API uses ref_lock struct which had its own "int fd", even
though the same file descriptor was in the lock struct it contains.
Clean-up the code to lose this redundant field.
* sb/ref-lock-lose-lock-fd:
refs.c: remove lock_fd from struct ref_lock
Junio C Hamano [Tue, 19 May 2015 20:17:58 +0000 (13:17 -0700)]
Merge branch 'kn/cat-file-literally'
Add the "--allow-unknown-type" option to "cat-file" to allow
inspecting loose objects of an experimental or a broken type.
* kn/cat-file-literally:
t1006: add tests for git cat-file --allow-unknown-type
cat-file: teach cat-file a '--allow-unknown-type' option
cat-file: make the options mutually exclusive
sha1_file: support reading from a loose object of unknown type
Junio C Hamano [Tue, 19 May 2015 20:17:57 +0000 (13:17 -0700)]
Merge branch 'nd/dwim-wildcards-as-pathspecs'
A heuristic to help the "git <cmd> <revs> <pathspec>" command line
convention to catch mistyped paths is to make sure all the non-rev
parameters in the later part of the command line are names of the
files in the working tree, but that means "git grep $str -- \*.c"
must always be disambiguated with "--", because nobody sane will
create a file whose name literally is asterisk-dot-see. Loosen the
heuristic to declare that with a wildcard string the user likely
meant to give us a pathspec.
* nd/dwim-wildcards-as-pathspecs:
pathspec: avoid the need of "--" when wildcard is used
Junio C Hamano [Tue, 19 May 2015 20:17:57 +0000 (13:17 -0700)]
Merge branch 'jc/merge'
"git merge FETCH_HEAD" learned that the previous "git fetch" could
be to create an Octopus merge, i.e. recording multiple branches
that are not marked as "not-for-merge"; this allows us to lose an
old style invocation "git merge <msg> HEAD $commits..." in the
implementation of "git pull" script; the old style syntax can now
be deprecated.
* jc/merge:
merge: deprecate 'git merge <message> HEAD <commit>' syntax
merge: handle FETCH_HEAD internally
merge: decide if we auto-generate the message early in collect_parents()
merge: make collect_parents() auto-generate the merge message
merge: extract prepare_merge_message() logic out
merge: narrow scope of merge_names
merge: split reduce_parents() out of collect_parents()
merge: clarify collect_parents() logic
merge: small leakfix and code simplification
merge: do not check argc to determine number of remote heads
merge: clarify "pulling into void" special case
t5520: test pulling an octopus into an unborn branch
t5520: style fixes
merge: simplify code flow
merge: test the top-level merge driver
Junio C Hamano [Tue, 19 May 2015 20:17:54 +0000 (13:17 -0700)]
Merge branch 'bc/connect-plink'
The connection initiation code for "ssh" transport tried to absorb
differences between the stock "ssh" and Putty-supplied "plink" and
its derivatives, but the logic to tell that we are using "plink"
variants were too loose and falsely triggered when "plink" appeared
anywhere in the path (e.g. "/home/me/bin/uplink/ssh").
* bc/connect-plink:
connect: improve check for plink to reduce false positives
t5601: fix quotation error leading to skipped tests
connect: simplify SSH connection code path
Junio C Hamano [Tue, 19 May 2015 20:17:52 +0000 (13:17 -0700)]
Merge branch 'jk/stash-require-clean-index'
"git stash pop/apply" forgot to make sure that not just the working
tree is clean but also the index is clean. The latter is important
as a stash application can conflict and the index will be used for
conflict resolution.
* jk/stash-require-clean-index:
stash: require a clean index to apply
t3903: avoid applying onto dirty index
t3903: stop hard-coding commit sha1s
Junio C Hamano [Tue, 19 May 2015 20:17:52 +0000 (13:17 -0700)]
Merge branch 'jk/git-no-more-argv0-path-munging'
We have prepended $GIT_EXEC_PATH and the path "git" is installed in
(typically "/usr/bin") to $PATH when invoking subprograms and hooks
for almost eternity, but the original use case the latter tried to
support was semi-bogus (i.e. install git to /opt/foo/git and run it
without having /opt/foo on $PATH), and more importantly it has
become less and less relevant as Git grew more mainstream (i.e. the
users would _want_ to have it on their $PATH). Stop prepending the
path in which "git" is installed to users' $PATH, as that would
interfere the command search order people depend on (e.g. they may
not like versions of programs that are unrelated to Git in /usr/bin
and want to override them by having different ones in /usr/local/bin
and have the latter directory earlier in their $PATH).
* jk/git-no-more-argv0-path-munging:
stop putting argv[0] dirname at front of PATH
Junio C Hamano [Tue, 19 May 2015 20:17:50 +0000 (13:17 -0700)]
Merge branch 'jc/gitignore-precedence'
core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed
to be overridden by repository-specific .git/info/exclude file, but
the order was swapped from the beginning. This belatedly fixes it.
* jc/gitignore-precedence:
ignore: info/exclude should trump core.excludesfile
Junio C Hamano [Tue, 19 May 2015 20:17:49 +0000 (13:17 -0700)]
Merge branch 'nd/diff-i-t-a'
After "git add -N", the path appeared in output of "git diff HEAD"
and "git diff --cached HEAD", leading "git status" to classify it
as "Changes to be committed". Such a path, however, is not yet to
be scheduled to be committed. "git diff" showed the change to the
path as modification, not as a "new file", in the header of its
output.
Treat such paths as "yet to be added to the index but Git already
know about them"; "git diff HEAD" and "git diff --cached HEAD"
should not talk about them, and "git diff" should show them as new
files yet to be added to the index.
* nd/diff-i-t-a:
diff-lib.c: adjust position of i-t-a entries in diff
Jeff King [Thu, 14 May 2015 04:34:48 +0000 (00:34 -0400)]
doc: convert AsciiDoc {?foo} to ifdef::foo[]
The former seems to just be syntactic sugar for the latter.
And as it's sugar that AsciiDoctor doesn't understand, it
would be nice to avoid it. Since there are only two spots,
and the resulting source is not significantly harder to
read, it's worth doing.
Note that this does slightly affect the generated HTML (it
has an extra newline), but the rendered result for both HTML
and docbook should be the same (since the newline is not
syntactically significant there).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 13 May 2015 21:05:51 +0000 (14:05 -0700)]
Merge branch 'cn/bom-in-gitignore' into maint
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
Junio C Hamano [Wed, 13 May 2015 21:05:50 +0000 (14:05 -0700)]
Merge branch 'jk/prune-mtime' into maint
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
Junio C Hamano [Wed, 13 May 2015 21:05:49 +0000 (14:05 -0700)]
Merge branch 'jk/init-core-worktree-at-root' into maint
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
Junio C Hamano [Wed, 13 May 2015 19:40:35 +0000 (12:40 -0700)]
log: do not shorten decoration names too early
The DECORATE_SHORT_REFS option given to load_ref_decorations()
affects the way a copy of the refname is stored for each decorated
commit, and this forces later steps like current_pointed_by_HEAD()
to adjust their behaviour based on this initial settings.
Instead, we can always store the full refname and then shorten them
when producing the output.
Junio C Hamano [Wed, 13 May 2015 17:25:18 +0000 (10:25 -0700)]
log: decorate HEAD with branch name under --decorate=full, too
The previous step to teach "log --decorate" to show "HEAD -> master"
instead of "HEAD, master" when showing the commit at the tip of the
'master' branch, when the 'master' branch is checked out, did not
work for "log --decorate=full".
The commands in the "log" family prepare commit decorations for all
refs upfront, and the actual string used in a decoration depends on
how load_ref_decorations() is called very early in the process. By
default, "git log --decorate" stores names with common prefixes such
as "refs/heads" stripped; "git log --decorate=full" stores the full
refnames.
When the current_pointed_by_HEAD() function has to decide if "HEAD"
points at the branch a decoration describes, however, what was
passed to load_ref_decorations() to decide to strip (or keep) such a
common prefix is long lost. This makes it impossible to reliably
tell if a decoration that stores "refs/heads/master", for example,
is the 'master' branch (under "--decorate" with prefix omitted) or
'refs/heads/master' branch (under "--decorate=full").
Keep what was passed to load_ref_decorations() in a global next to
the global variable name_decoration, and use that to decide how to
match what was read from "HEAD" and what is in a decoration.
Jeff King [Wed, 13 May 2015 05:02:22 +0000 (01:02 -0400)]
doc: drop backslash quoting of some curly braces
Text like "{foo}" triggers an AsciiDoc attribute; we have to
write "\{foo}" to suppress this. But when the "foo" is not a
syntactically valid attribute, we can skip the quoting. This
makes the source nicer to read, and looks better under
Asciidoctor. With AsciiDoc itself, this patch produces no
changes.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 13 May 2015 05:01:38 +0000 (01:01 -0400)]
doc: convert \--option to --option
Older versions of AsciiDoc would convert the "--" in
"--option" into an emdash. According to 565e135
(Documentation: quote double-dash for AsciiDoc, 2011-06-29),
this is fixed in AsciiDoc 8.3.0. According to bf17126, we
don't support anything older than 8.4.1 anyway, so we no
longer need to worry about quoting.
Even though this does not change the output at all, there
are a few good reasons to drop the quoting:
1. It makes the source prettier to read.
2. We don't quote consistently, which may be confusing when
reading the source.
3. Asciidoctor does not like the quoting, and renders a
literal backslash.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 13 May 2015 04:58:29 +0000 (00:58 -0400)]
doc: fix length of underlined section-title
In AsciiDoc, it is OK to say:
this is my title
-------------------------
but AsciiDoctor is more strict. Let's match the underline to
the title (which also makes the source prettier to read).
The output from AsciiDoc is the same either way.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 13 May 2015 04:58:16 +0000 (00:58 -0400)]
doc: fix hanging "+"-continuation
In list content that wants to continue to a second
paragraph, the "+" continuation and subsequent paragraph
need to be left-aligned. Otherwise AsciiDoc seems to insert
only a linebreak.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 13 May 2015 04:58:06 +0000 (00:58 -0400)]
doc: fix unquoted use of "{type}"
Curly braces open an "attribute" in AsciiDoc; if there's no
such attribute, strange things may happen. In this case, the
unquoted "{type}" causes AsciiDoc to omit an entire line of
text from the output. We can fix it by putting the whole
phrase inside literal backticks (which also lets us get rid
of ugly backslash escaping).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 13 May 2015 04:57:54 +0000 (00:57 -0400)]
doc: fix misrendering due to `single quote'
AsciiDoc misparses some text that contains a `literal`
word followed by a fancy `single quote' word, and treats
everything from the start of the literal to the end of the
quote as a single-quoted phrase.
We can work around this by switching the latter to be a
literal, as well. In the first case, this is perhaps what
was intended anyway, as it makes us consistent with the the
earlier literals in the same paragraph. In the second, the
output is arguably better, as we will format our commit
references as <code> blocks.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 13 May 2015 04:28:54 +0000 (21:28 -0700)]
Merge branch 'mh/write-refs-sooner-2.3' into mh/write-refs-sooner-2.4
* mh/write-refs-sooner-2.3:
ref_transaction_commit(): fix atomicity and avoid fd exhaustion
ref_transaction_commit(): remove the local flags variable
ref_transaction_commit(): inline call to write_ref_sha1()
rename_ref(): inline calls to write_ref_sha1() from this function
commit_ref_update(): new function, extracted from write_ref_sha1()
write_ref_to_lockfile(): new function, extracted from write_ref_sha1()
t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
update-ref: test handling large transactions properly
Michael Haggerty [Fri, 24 Apr 2015 11:35:49 +0000 (13:35 +0200)]
ref_transaction_commit(): fix atomicity and avoid fd exhaustion
The old code was roughly
for update in updates:
acquire locks and check old_sha
for update in updates:
if changing value:
write_ref_to_lockfile()
commit_ref_update()
for update in updates:
if deleting value:
unlink()
rewrite packed-refs file
for update in updates:
if reference still locked:
unlock_ref()
This has two problems.
Non-atomic updates
==================
The atomicity of the reference transaction depends on all pre-checks
being done in the first loop, before any changes have started being
committed in the second loop. The problem is that
write_ref_to_lockfile() (previously part of write_ref_sha1()), which
is called from the second loop, contains two more checks:
* It verifies that new_sha1 is a valid object
* If the reference being updated is a branch, it verifies that
new_sha1 points at a commit object (as opposed to a tag, tree, or
blob).
If either of these checks fails, the "transaction" is aborted during
the second loop. But this might happen after some reference updates
have already been permanently committed. In other words, the
all-or-nothing promise of "git update-ref --stdin" could be violated.
So these checks have to be moved to the first loop.
The old code locked all of the references in the first loop, leaving
all of the lockfiles open until later loops. Since we might be
updating a lot of references, this could result in file descriptor
exhaustion.
The solution
============
After this patch, the code looks like
for update in updates:
acquire locks and check old_sha
if changing value:
write_ref_to_lockfile()
else:
close_ref()
for update in updates:
if changing value:
commit_ref_update()
for update in updates:
if deleting value:
unlink()
rewrite packed-refs file
for update in updates:
if reference still locked:
unlock_ref()
This fixes both problems:
1. The pre-checks in write_ref_to_lockfile() are now done in the first
loop, before any changes have been committed. If any of the checks
fails, the whole transaction can now be rolled back correctly.
2. All lockfiles are closed in the first loop immediately after they
are created (either by write_ref_to_lockfile() or by close_ref()).
This means that there is never more than one open lockfile at a
time, preventing file descriptor exhaustion.
To simplify the bookkeeping across loops, add a new REF_NEEDS_COMMIT
bit to update->flags, which keeps track of whether the corresponding
lockfile needs to be committed, as opposed to just unlocked. (Since
"struct ref_update" is internal to the refs module, this change is not
visible to external callers.)
This change fixes two tests in t1400.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Fri, 24 Apr 2015 11:35:48 +0000 (13:35 +0200)]
ref_transaction_commit(): remove the local flags variable
Instead, work directly with update->flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the second
loop instead of having to be recomputed. Plus, it was potentially
confusing having both update->flags and flags, which sometimes had
different values.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stefan Beller [Tue, 14 Apr 2015 22:25:07 +0000 (15:25 -0700)]
t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
During creation of the patch series our discussion we could have a
more descriptive name for the prerequisite for the test so it stays
unique when other limits of ulimit are introduced.
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stefan Beller [Tue, 14 Apr 2015 22:25:06 +0000 (15:25 -0700)]
update-ref: test handling large transactions properly
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 13 May 2015 04:26:09 +0000 (21:26 -0700)]
Merge branch 'mh/write-refs-sooner-2.2' into mh/write-refs-sooner-2.3
* mh/write-refs-sooner-2.2:
ref_transaction_commit(): fix atomicity and avoid fd exhaustion
ref_transaction_commit(): remove the local flags variable
ref_transaction_commit(): inline call to write_ref_sha1()
rename_ref(): inline calls to write_ref_sha1() from this function
commit_ref_update(): new function, extracted from write_ref_sha1()
write_ref_to_lockfile(): new function, extracted from write_ref_sha1()
t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
update-ref: test handling large transactions properly
Michael Haggerty [Sun, 10 May 2015 02:45:37 +0000 (04:45 +0200)]
ref_transaction_commit(): fix atomicity and avoid fd exhaustion
The old code was roughly
for update in updates:
acquire locks and check old_sha
for update in updates:
if changing value:
write_ref_to_lockfile()
commit_ref_update()
for update in updates:
if deleting value:
unlink()
rewrite packed-refs file
for update in updates:
if reference still locked:
unlock_ref()
This has two problems.
Non-atomic updates
==================
The atomicity of the reference transaction depends on all pre-checks
being done in the first loop, before any changes have started being
committed in the second loop. The problem is that
write_ref_to_lockfile() (previously part of write_ref_sha1()), which
is called from the second loop, contains two more checks:
* It verifies that new_sha1 is a valid object
* If the reference being updated is a branch, it verifies that
new_sha1 points at a commit object (as opposed to a tag, tree, or
blob).
If either of these checks fails, the "transaction" is aborted during
the second loop. But this might happen after some reference updates
have already been permanently committed. In other words, the
all-or-nothing promise of "git update-ref --stdin" could be violated.
So these checks have to be moved to the first loop.
The old code locked all of the references in the first loop, leaving
all of the lockfiles open until later loops. Since we might be
updating a lot of references, this could result in file descriptor
exhaustion.
The solution
============
After this patch, the code looks like
for update in updates:
acquire locks and check old_sha
if changing value:
write_ref_to_lockfile()
else:
close_ref()
for update in updates:
if changing value:
commit_ref_update()
for update in updates:
if deleting value:
unlink()
rewrite packed-refs file
for update in updates:
if reference still locked:
unlock_ref()
This fixes both problems:
1. The pre-checks in write_ref_to_lockfile() are now done in the first
loop, before any changes have been committed. If any of the checks
fails, the whole transaction can now be rolled back correctly.
2. All lockfiles are closed in the first loop immediately after they
are created (either by write_ref_to_lockfile() or by close_ref()).
This means that there is never more than one open lockfile at a
time, preventing file descriptor exhaustion.
To simplify the bookkeeping across loops, add a new REF_NEEDS_COMMIT
bit to update->flags, which keeps track of whether the corresponding
lockfile needs to be committed, as opposed to just unlocked. (Since
"struct ref_update" is internal to the refs module, this change is not
visible to external callers.)
This change fixes two tests in t1400.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sun, 10 May 2015 02:45:36 +0000 (04:45 +0200)]
ref_transaction_commit(): remove the local flags variable
Instead, work directly with update->flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the second
loop instead of having to be recomputed. Plus, it was potentially
confusing having both update->flags and flags, which sometimes had
different values.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stefan Beller [Sun, 10 May 2015 02:45:31 +0000 (04:45 +0200)]
t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
During creation of the patch series, our discussion revealed that
we could have a more descriptive name for the prerequisite for the
test so it stays unique when other limits of ulimit are introduced.
Let's rename the existing ulimit about setting the stack size to
a more explicit ULIMIT_STACK_SIZE.
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 11 May 2015 21:34:00 +0000 (14:34 -0700)]
Merge branch 'jc/diff-no-index-d-f' into maint-2.3
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"
Junio C Hamano [Mon, 11 May 2015 21:24:01 +0000 (14:24 -0700)]
Merge branch 'pt/xdg-config-path'
Code clean-up for xdg configuration path support.
* pt/xdg-config-path:
path.c: remove home_config_paths()
git-config: replace use of home_config_paths()
git-commit: replace use of home_config_paths()
credential-store.c: replace home_config_paths() with xdg_config_home()
dir.c: replace home_config_paths() with xdg_config_home()
attr.c: replace home_config_paths() with xdg_config_home()
path.c: implement xdg_config_home()
Junio C Hamano [Mon, 11 May 2015 21:23:59 +0000 (14:23 -0700)]
Merge branch 'jc/hash-object'
"hash-object --literally" introduced in v2.2 was not prepared to
take a really long object type name.
* jc/hash-object:
write_sha1_file(): do not use a separate sha1[] array
t1007: add hash-object --literally tests
hash-object --literally: fix buffer overrun with extra-long object type
git-hash-object.txt: document --literally option
"filter-branch" corrupted commit log message that ends with an
incomplete line on platforms with some "sed" implementations that
munge such a line. Work it around by avoiding to use "sed".
* jk/filter-branch-use-of-sed-on-incomplete-line:
filter-branch: avoid passing commit message through sed
Junio C Hamano [Mon, 11 May 2015 21:23:52 +0000 (14:23 -0700)]
Merge branch 'tb/blame-resurrect-convert-to-git'
Some time ago, "git blame" (incorrectly) lost the convert_to_git()
call when synthesizing a fake "tip" commit that represents the
state in the working tree, which broke folks who record the history
with LF line ending to make their project portabile across
platforms while terminating lines in their working tree files with
CRLF for their platform.
* tb/blame-resurrect-convert-to-git:
blame: CRLF in the working tree and LF in the repo
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
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
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
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
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
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
...
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