git/git.git
6 years agoadd quieter versions of parse_{tree,commit}
Jeff King [Mon, 1 Jun 2015 09:56:26 +0000 (05:56 -0400)]
add quieter versions of parse_{tree,commit}

When we call parse_commit, it will complain to stderr if the
object does not exist or cannot be read. This means that we
may produce useless error messages if this situation is
expected (e.g., because the object is marked UNINTERESTING,
or because revs->ignore_missing_links is set).

We can fix this by adding a new "parse_X_gently" form that
takes a flag to suppress the messages. The existing
"parse_X" form is already gentle in the sense that it
returns an error rather than dying, and we could in theory
just add a "quiet" flag to it (with existing callers passing
"0"). But doing it this way means we do not have to disturb
existing callers.

Note also that the new flag is "quiet_on_missing", and not
just "quiet". We could add a flag to suppress _all_ errors,
but besides being a more invasive change (we would have to
pass the flag down to sub-functions, too), there is a good
reason not to: we would never want to use it. Missing a
linked object is expected in some circumstances, but it is
never expected to have a malformed commit, or to get a tree
when we wanted a commit.  We should always complain about
these corruptions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoglossary: add "remote", "submodule", "superproject"
Stefan Beller [Fri, 29 May 2015 18:23:56 +0000 (11:23 -0700)]
glossary: add "remote", "submodule", "superproject"

Noticed-by: Philip Oakley <philipoakley@iee.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agosetup_git_directory: delay core.bare/core.worktree errors
Jeff King [Fri, 29 May 2015 06:49:10 +0000 (02:49 -0400)]
setup_git_directory: delay core.bare/core.worktree errors

If both core.bare and core.worktree are set, we complain
about the bogus config and die. Dying is good, because it
avoids commands running and doing damage in a potentially
incorrect setup. But dying _there_ is bad, because it means
that commands which do not even care about the work tree
cannot run. This can make repairing the situation harder:

  [setup]
  $ git config core.bare true
  $ git config core.worktree /some/path

  [OK, expected.]
  $ git status
  fatal: core.bare and core.worktree do not make sense

  [Hrm...]
  $ git config --unset core.worktree
  fatal: core.bare and core.worktree do not make sense

  [Nope...]
  $ git config --edit
  fatal: core.bare and core.worktree do not make sense

  [Gaaah.]
  $ git help config
  fatal: core.bare and core.worktree do not make sense

Instead, let's issue a warning about the bogus config when
we notice it (i.e., for all commands), but only die when the
command tries to use the work tree (by calling setup_work_tree).
So we now get:

  $ git status
  warning: core.bare and core.worktree do not make sense
  fatal: unable to set up work tree using invalid config

  $ git config --unset core.worktree
  warning: core.bare and core.worktree do not make sense

We have to update t1510 to accomodate this; it uses
symbolic-ref to check whether the configuration works or
not, but of course that command does not use the working
tree. Instead, we switch it to use `git status`, as it
requires a work-tree, does not need any special setup, and
is read-only (so a failure will not adversely affect further
tests).

In addition, we add a new test that checks the desired
behavior (i.e., that running "git config" with the bogus
config does in fact work).

Reported-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMakefile: silence perl/PM.stamp recipe
Jeff King [Fri, 29 May 2015 07:26:48 +0000 (03:26 -0400)]
Makefile: silence perl/PM.stamp recipe

Every time we run "make", we update perl/PM.stamp, which
contains a list of all of the perl module files (if it's
updated, we need to rebuild perl/perl.mak, since the
Makefile will not otherwise know about the new files).

This means that every time "make" is run, we see:

      GEN perl/PM.stamp

in the output, even though it is not likely to have changed.
Let's make this recipe completely silent, as we do for other
auto-generated dependency files (e.g., GIT-CFLAGS).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMakefile: avoid timestamp updates to GIT-BUILD-OPTIONS
Jeff King [Fri, 29 May 2015 07:26:30 +0000 (03:26 -0400)]
Makefile: avoid timestamp updates to GIT-BUILD-OPTIONS

We force the GIT-BUILD-OPTIONS recipe to run every time
"make" is invoked. We must do this to catch new options
which may have come from the command-line or environment.

However, we actually update the file's timestamp each time
the recipe is run, whether anything changed or not. As a
result, any files which depend on it (for example, all of
the perl scripts, which need to know whether NO_PERL was
set) will be re-built every time.

Let's do our usual trick of writing to a tempfile, then
doing a "cmp || mv" to update the file only when something
changed.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMakefile: drop dependency between git-instaweb and gitweb
Jeff King [Fri, 29 May 2015 07:25:45 +0000 (03:25 -0400)]
Makefile: drop dependency between git-instaweb and gitweb

The rule for "git-instaweb" depends on "gitweb". This makes
no sense, because:

  1. git-instaweb has no build-time dependency on gitweb; it
     is a run-time dependency

  2. gitweb is a directory that we want to recursively make
     in. As a result, its recipe is marked .PHONY, which
     causes "make" to rebuild git-instaweb every time it is
     run.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agosubmodule doc: reorder introductory paragraphs
Stefan Beller [Wed, 27 May 2015 19:48:01 +0000 (12:48 -0700)]
submodule doc: reorder introductory paragraphs

It's better to start the man page with a description of what
submodules actually are, instead of saying what they are not.

Reorder the paragraphs such that

 - the first short paragraph introduces the submodule concept,
 - the second paragraph highlights the usage of the submodule command,
 - the third paragraph giving background information, and finally
 - the fourth paragraph discusing alternatives such as subtrees and
   remotes, which we don't want to be confused with.

This ordering deepens the knowledge on submodules with each paragraph.
First the basic questions like "How/what" will be answered, while the
underlying concepts will be taught at a later time.

Making sure it is not confused with subtrees and remotes is not really
enhancing knowledge of submodules itself, but rather painting the big
picture of git concepts, so you could also argue to have it as the second
paragraph. Personally I think this may confuse readers, specially
newcomers though.

Additionally to reordering the paragraphs, they have been slightly
reworded.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoDocumentation: include 'merge.branchdesc' for merge and config as well
SZEDER Gábor [Wed, 27 May 2015 21:52:23 +0000 (23:52 +0200)]
Documentation: include 'merge.branchdesc' for merge and config as well

'merge.branchdesc' is only mentioned in the docs of 'git fmt-merge-msg'.

The description of 'merge.log' is already duplicated between
'merge-config.txt' and 'git-fmt-merge-msg.txt'; instead of duplicating the
description of another config variable, extract the descriptions of both
of these variables from 'git-fmt-merge-msg.txt' into a separate file and
include it there and in 'merge-config.txt'.

Leave 'merge.summary' only in git-fmt-merge-msg.txt, as it is marked
as deprecated.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoxmmap(): drop "Out of memory?"
Junio C Hamano [Wed, 27 May 2015 20:30:29 +0000 (13:30 -0700)]
xmmap(): drop "Out of memory?"

We show that message with die_errno(), but the OS is ought to know
why mmap(2) failed much better than we do.  There is no reason for
us to say "Out of memory?" here.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoconfig.c: rewrite ENODEV into EISDIR when mmap fails
Jeff King [Thu, 28 May 2015 08:03:01 +0000 (04:03 -0400)]
config.c: rewrite ENODEV into EISDIR when mmap fails

If we try to mmap a directory, we'll get ENODEV. This
translates to "no such device" for the user, which is not
very helpful. Since we've just fstat()'d the file, we can
easily check whether the problem was a directory to give a
better message.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoconfig.c: avoid xmmap error messages
Jeff King [Thu, 28 May 2015 07:56:15 +0000 (03:56 -0400)]
config.c: avoid xmmap error messages

The config-writing code uses xmmap to map the existing
config file, which will die if the map fails. This has two
downsides:

  1. The error message is not very helpful, as it lacks any
     context about the file we are mapping:

       $ mkdir foo
       $ git config --file=foo some.key value
       fatal: Out of memory? mmap failed: No such device

  2. We normally do not die in this code path; instead, we'd
     rather report the error and return an appropriate exit
     status (which is part of the public interface
     documented in git-config.1).

This patch introduces a "gentle" form of xmmap which lets us
produce our own error message. We do not want to use mmap
directly, because we would like to use the other
compatibility elements of xmmap (e.g., handling 0-length
maps portably).

The end result is:

    $ git.compile config --file=foo some.key value
    error: unable to mmap 'foo': No such device
    $ echo $?
    3

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoconfig.c: fix mmap leak when writing config
Jeff King [Thu, 28 May 2015 07:54:43 +0000 (03:54 -0400)]
config.c: fix mmap leak when writing config

We mmap the existing config file, but fail to unmap it if we
hit an error. The function already has a shared exit path,
so we can fix this by moving the mmap pointer to the
function scope and clearing it in the shared exit.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoread-cache.c: drop PROT_WRITE from mmap of index
Jeff King [Thu, 28 May 2015 07:54:00 +0000 (03:54 -0400)]
read-cache.c: drop PROT_WRITE from mmap of index

Once upon a time, git's in-memory representation of a cache
entry actually pointed to the mmap'd on-disk data. So in
520fc24 (Allow writing to the private index file mapping.,
2005-04-26), we specified PROT_WRITE so that we could tweak
the entries while we run (in our own MAP_PRIVATE copy-on-write
version, of course).

Later, 7a51ed6 (Make on-disk index representation separate
from in-core one, 2008-01-14) stopped doing this; we copy
the data into our in-core representation, and then drop the
mmap immediately. We can therefore drop the PROT_WRITE flag.
It's probably not hurting anything as it is, but it's
potentially confusing.

Note that we could also mark the mapping as "const" to
verify that we never write to it. However, we don't
typically do that for our other maps, as it then requires
casting to munmap() it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodiff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT
Jeff King [Wed, 27 May 2015 20:48:46 +0000 (16:48 -0400)]
diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT

The latter is a much more descriptive name (and we support
"color.diff.context" now). This also updates the name of any
local variables which were used to store the color.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodiff: accept color.diff.context as a synonym for "plain"
Jeff King [Wed, 27 May 2015 07:22:19 +0000 (03:22 -0400)]
diff: accept color.diff.context as a synonym for "plain"

The term "plain" is a bit ambiguous; let's allow the more
specific "context", but keep "plain" around for
compatibility.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoclone: reorder --dissociate and --reference options
Jeff King [Thu, 21 May 2015 04:16:04 +0000 (00:16 -0400)]
clone: reorder --dissociate and --reference options

These options are intimately related, so it makes sense to
list them nearby in the "-h" output (they are already
adjacent in the manpage).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoclone: use OPT_STRING_LIST for --reference
Jeff King [Thu, 21 May 2015 04:15:19 +0000 (00:15 -0400)]
clone: use OPT_STRING_LIST for --reference

Not only does this save us having to implement a custom
callback, but it handles "--no-reference" in the usual way
(to clear the list).

The generic callback does copy the string, which we don't
technically need, but that should not hurt anything.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoGit 2.4.2 v2.4.2
Junio C Hamano [Tue, 26 May 2015 20:49:59 +0000 (13:49 -0700)]
Git 2.4.2

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'jk/still-interesting' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:26 +0000 (13:49 -0700)]
Merge branch 'jk/still-interesting' into maint

"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

6 years agoMerge branch 'jc/hash-object' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:24 +0000 (13:49 -0700)]
Merge branch 'jc/hash-object' into maint

"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

6 years agoMerge branch 'jk/rebase-quiet-noop' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:23 +0000 (13:49 -0700)]
Merge branch 'jk/rebase-quiet-noop' into maint

"git rebase --quiet" was not quite quiet when there is nothing to
do.

* jk/rebase-quiet-noop:
  rebase: silence "git checkout" for noop rebase

6 years agoMerge branch 'sg/complete-decorate-full-not-long' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:22 +0000 (13:49 -0700)]
Merge branch 'sg/complete-decorate-full-not-long' into maint

The completion for "log --decorate=" parameter value was incorrect.

* sg/complete-decorate-full-not-long:
  completion: fix and update 'git log --decorate=' options

6 years agoMerge branch 'jk/filter-branch-use-of-sed-on-incomplete-line' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:20 +0000 (13:49 -0700)]
Merge branch 'jk/filter-branch-use-of-sed-on-incomplete-line' into maint

"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

6 years agoMerge branch 'jc/daemon-no-ipv6-for-2.4.1' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:19 +0000 (13:49 -0700)]
Merge branch 'jc/daemon-no-ipv6-for-2.4.1' into maint

"git daemon" fails to build from the source under NO_IPV6
configuration (regression in 2.4).

* jc/daemon-no-ipv6-for-2.4.1:
  daemon: unbreak NO_IPV6 build regression

6 years agoMerge branch 'jk/stash-require-clean-index' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:19 +0000 (13:49 -0700)]
Merge branch 'jk/stash-require-clean-index' into maint

"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

6 years agoMerge branch 'jk/git-no-more-argv0-path-munging' into maint
Junio C Hamano [Tue, 26 May 2015 20:49:18 +0000 (13:49 -0700)]
Merge branch 'jk/git-no-more-argv0-path-munging' into maint

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

6 years agoMerge branch 'jk/http-backend-deadlock-2.3' into jk/http-backend-deadlock
Junio C Hamano [Tue, 26 May 2015 03:44:42 +0000 (20:44 -0700)]
Merge branch 'jk/http-backend-deadlock-2.3' into jk/http-backend-deadlock

* jk/http-backend-deadlock-2.3:
  http-backend: spool ref negotiation requests to buffer
  t5551: factor out tag creation
  http-backend: fix die recursion with custom handler

6 years agoMerge branch 'jk/http-backend-deadlock-2.2' into jk/http-backend-deadlock-2.3
Junio C Hamano [Tue, 26 May 2015 03:44:04 +0000 (20:44 -0700)]
Merge branch 'jk/http-backend-deadlock-2.2' into jk/http-backend-deadlock-2.3

* jk/http-backend-deadlock-2.2:
  http-backend: spool ref negotiation requests to buffer
  t5551: factor out tag creation
  http-backend: fix die recursion with custom handler

6 years agohttp-backend: spool ref negotiation requests to buffer
Jeff King [Wed, 20 May 2015 07:37:09 +0000 (03:37 -0400)]
http-backend: spool ref negotiation requests to buffer

When http-backend spawns "upload-pack" to do ref
negotiation, it streams the http request body to
upload-pack, who then streams the http response back to the
client as it reads. In theory, git can go full-duplex; the
client can consume our response while it is still sending
the request.  In practice, however, HTTP is a half-duplex
protocol. Even if our client is ready to read and write
simultaneously, we may have other HTTP infrastructure in the
way, including the webserver that spawns our CGI, or any
intermediate proxies.

In at least one documented case[1], this leads to deadlock
when trying a fetch over http. What happens is basically:

  1. Apache proxies the request to the CGI, http-backend.

  2. http-backend gzip-inflates the data and sends
     the result to upload-pack.

  3. upload-pack acts on the data and generates output over
     the pipe back to Apache. Apache isn't reading because
     it's busy writing (step 1).

This works fine most of the time, because the upload-pack
output ends up in a system pipe buffer, and Apache reads
it as soon as it finishes writing. But if both the request
and the response exceed the system pipe buffer size, then we
deadlock (Apache blocks writing to http-backend,
http-backend blocks writing to upload-pack, and upload-pack
blocks writing to Apache).

We need to break the deadlock by spooling either the input
or the output. In this case, it's ideal to spool the input,
because Apache does not start reading either stdout _or_
stderr until we have consumed all of the input. So until we
do so, we cannot even get an error message out to the
client.

The solution is fairly straight-forward: we read the request
body into an in-memory buffer in http-backend, freeing up
Apache, and then feed the data ourselves to upload-pack. But
there are a few important things to note:

  1. We limit the in-memory buffer to prevent an obvious
     denial-of-service attack. This is a new hard limit on
     requests, but it's unlikely to come into play. The
     default value is 10MB, which covers even the ridiculous
     100,000-ref negotation in the included test (that
     actually caps out just over 5MB). But it's configurable
     on the off chance that you don't mind spending some
     extra memory to make even ridiculous requests work.

  2. We must take care only to buffer when we have to. For
     pushes, the incoming packfile may be of arbitrary
     size, and we should connect the input directly to
     receive-pack. There's no deadlock problem here, though,
     because we do not produce any output until the whole
     packfile has been read.

     For upload-pack's initial ref advertisement, we
     similarly do not need to buffer. Even though we may
     generate a lot of output, there is no request body at
     all (i.e., it is a GET, not a POST).

[1] http://article.gmane.org/gmane.comp.version-control.git/269020

Test-adapted-from: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agotest_bitmap_walk: free bitmap with bitmap_free
Jeff King [Fri, 22 May 2015 00:53:36 +0000 (20:53 -0400)]
test_bitmap_walk: free bitmap with bitmap_free

Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
noticed that we leak the "result" bitmap. But we should use
"bitmap_free" rather than straight "free", as the former
remembers to free the bitmap array pointed to by the struct.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodoc: fix inconsistent spelling of "packfile"
Patrick Steinhardt [Fri, 22 May 2015 06:22:04 +0000 (08:22 +0200)]
doc: fix inconsistent spelling of "packfile"

Fix remaining instances where "pack-file" is used instead of
"packfile". Some places remain where we still use "pack-file",
This is the case when we explicitly refer to a file with a
".pack" extension as opposed to a data source providing a pack
data stream.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot5407: use <<- to align the expected output
Junio C Hamano [Fri, 22 May 2015 15:41:31 +0000 (08:41 -0700)]
t5407: use <<- to align the expected output

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorebase -i: fix post-rewrite hook with failed exec command
Matthieu Moy [Fri, 22 May 2015 13:15:49 +0000 (13:15 +0000)]
rebase -i: fix post-rewrite hook with failed exec command

Usually, when 'git rebase' stops before completing the rebase, it is to
give the user an opportunity to edit a commit (e.g. with the 'edit'
command). In such cases, 'git rebase' leaves the sha1 of the commit being
rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase
--continue' will call the post-rewrite hook with this sha1 as <old-sha1>
argument to the post-rewrite hook.

The case of 'git rebase' stopping because of a failed 'exec' command is
different: it gives the opportunity to the user to examine or fix the
failure, but does not stop saying "here's a commit to edit, use
--continue when you're done". So, there's no reason to call the
post-rewrite hook for 'exec' commands. If the user did rewrite the
commit, it would be with 'git commit --amend' which already called the
post-rewrite hook.

Fix the behavior to leave no stopped-sha file in case of failed exec
command, and teach 'git rebase --continue' to skip record_in_rewritten if
no stopped-sha file is found.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorebase -i: demonstrate incorrect behavior of post-rewrite
Matthieu Moy [Fri, 22 May 2015 13:15:50 +0000 (13:15 +0000)]
rebase -i: demonstrate incorrect behavior of post-rewrite

The 'exec' command is sending the current commit to stopped-sha, which is
supposed to contain the original commit (before rebase). As a result, if
an 'exec' command fails, the next 'git rebase --continue' will send the
current commit as <old-sha1> to the post-rewrite hook.

The test currently fails with :

  --- expected.data       2015-05-21 17:55:29.000000000 +0000
  +++ [...]post-rewrite.data      2015-05-21 17:55:29.000000000 +0000
  @@ -1,2 +1,3 @@
   2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab
  +488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab
   babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoDocumentation/log: clarify sha1 non-abbreviation in log --raw
Matthieu Moy [Mon, 18 May 2015 17:55:58 +0000 (19:55 +0200)]
Documentation/log: clarify sha1 non-abbreviation in log --raw

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodir: remove unused variable sb
René Scharfe [Tue, 19 May 2015 22:13:33 +0000 (00:13 +0200)]
dir: remove unused variable sb

It had never been used.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoclean: remove unused variable buf
René Scharfe [Tue, 19 May 2015 22:13:26 +0000 (00:13 +0200)]
clean: remove unused variable buf

It had never been used.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agouse file_exists() to check if a file exists in the worktree
René Scharfe [Tue, 19 May 2015 21:44:23 +0000 (23:44 +0200)]
use file_exists() to check if a file exists in the worktree

Call file_exists() instead of open-coding it.  That's shorter, simpler
and the intent becomes clearer.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agostash: recognize "--help" for subcommands
Jeff King [Wed, 20 May 2015 18:17:46 +0000 (14:17 -0400)]
stash: recognize "--help" for subcommands

If you run "git stash --help", you get the help for stash
(this magic is done by the git wrapper itself). But if you
run "git stash drop --help", you get an error. We
cannot show help specific to "stash drop", of course, but we
can at least give the user the normal stash manpage.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agostash: complain about unknown flags
Jeff King [Wed, 20 May 2015 18:01:32 +0000 (14:01 -0400)]
stash: complain about unknown flags

The option parser for git-stash stuffs unknown flags into
the $FLAGS variable, where they can be accessed by the
individual commands. However, most commands do not even look
at these extra flags, leading to unexpected results like
this:

  $ git stash drop --help
  Dropped refs/stash@{0} (e6cf6d80faf92bb7828f7b60c47fc61c03bd30a1)

We should notice the extra flags and bail. Rather than
annotate each command to reject a non-empty $FLAGS variable,
we can notice that "stash show" is the only command that
actually _wants_ arbitrary flags. So we switch the default
mode to reject unknown flags, and let stash_show() opt into
the feature.

Reported-by: Vincent Legoll <vincent.legoll@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot5551: factor out tag creation
Jeff King [Wed, 20 May 2015 07:36:43 +0000 (03:36 -0400)]
t5551: factor out tag creation

One of our tests in t5551 creates a large number of tags,
and jumps through some hoops to do it efficiently. Let's
factor that out into a function so we can make other similar
tests.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoDocumentation/git-commit: grammofix
Michael Coleman [Wed, 20 May 2015 02:41:17 +0000 (22:41 -0400)]
Documentation/git-commit: grammofix

Signed-off-by: Michael Coleman <michael.karl.coleman@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agopack-bitmaps: plug memory leak, fix allocation size for recent_bitmaps
René Scharfe [Mon, 18 May 2015 23:24:09 +0000 (01:24 +0200)]
pack-bitmaps: plug memory leak, fix allocation size for recent_bitmaps

Use an automatic variable for recent_bitmaps, an array of pointers.
This way we don't allocate too much and don't have to free the memory
at the end.  The old code over-allocated because it reserved enough
memory to store all of the structs it is only pointing to and never
freed it.  160 64-bit pointers take up 1280 bytes, which is not too
much to be placed on the stack.

MAX_XOR_OFFSET is turned into a preprocessor constant to make it
constant enough for use in an non-variable array declaration.

Noticed-by: Stefan Beller <stefanbeller@gmail.com>
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoclone: call transport_set_verbosity before anything else on the newly created transport
Mike Hommey [Tue, 12 May 2015 04:30:16 +0000 (13:30 +0900)]
clone: call transport_set_verbosity before anything else on the newly created transport

Commit 2879bc3 made the progress and verbosity options sent to remote helper
earlier than they previously were. But nothing else after that would send
updates if the value is changed later on with transport_set_verbosity.

While for fetch and push, transport_set_verbosity is the first thing that
is done after creating the transport, it was not the case for clone. So
commit 2879bc3 broke changing progress and verbosity for clone, for urls
requiring a remote helper only (so, not git:// urls, for instance).

Moving transport_set_verbosity to just after the transport is created
works around the issue.

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agosubdirectory tests: code cleanup, uncomment test
Stefan Beller [Mon, 18 May 2015 21:10:26 +0000 (14:10 -0700)]
subdirectory tests: code cleanup, uncomment test

Back when these tests were written, we wanted to make sure that Git
notices it is in a bare repository and "git show -s HEAD" would
refrain from complaining that HEAD might mean a file it sees in its
current working directory (because it does not).  But the version of
Git back then didn't behave well, without (doubly) being told that
it is inside a bare repository by exporting "GIT_DIR=.".  The form
of the test we originally wanted to have was left commented out as
a reminder.

Nowadays the test as originally intended works, so add it to the
test suite.  We'll keep the old test that explicitly sets GIT_DIR=.
to make sure that use case will not regress.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoclean: only lstat files in pathspec
David Turner [Mon, 18 May 2015 18:08:46 +0000 (14:08 -0400)]
clean: only lstat files in pathspec

Even though "git clean" takes pathspec to limit the part of the
working tree to be cleaned, it checked the paths it encounters
during its directory traversal with lstat(2), before checking if
the path is within the pathspec.

Ignore paths outside pathspec and proceed without checking with
lstat(2).  Even if such a path is unreadable due to e.g. EPERM,
"git clean" should not care.

Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoDocumentation/log: clarify what --raw means
Matthieu Moy [Mon, 18 May 2015 17:55:57 +0000 (19:55 +0200)]
Documentation/log: clarify what --raw means

There are several "raw formats", and describing --raw as "Generate the
raw format" in the documentation for git-log seems to imply that it
generates the raw *log* format.

Clarify the wording by saying "raw diff format" explicitly, and make a
special-case for "git log": "git log --raw" does not just change the
format, it shows something which is not shown by default.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agopull: parse pull.ff as a bool or string
Paul Tan [Mon, 18 May 2015 13:45:42 +0000 (21:45 +0800)]
pull: parse pull.ff as a bool or string

Since b814da8 (pull: add pull.ff configuration, 2014-01-15) git-pull
supported setting --(no-)ff via the pull.ff configuration value.
However, as it only matches the string values of "true" and "false", it
does not support other boolean aliases such as "on", "off", "1", "0".
This is inconsistent with the merge.ff setting, which supports these
aliases.

Fix this by using the bool_or_string_config function to retrieve the
value of pull.ff.

Signed-off-by: Paul Tan <pyokagan@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agopull: make pull.ff=true override merge.ff
Paul Tan [Mon, 18 May 2015 13:45:41 +0000 (21:45 +0800)]
pull: make pull.ff=true override merge.ff

Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running
git-pull with the configuration pull.ff=false or pull.ff=only is
equivalent to passing --no-ff and --ff-only to git-merge. However, if
pull.ff=true, no switch is passed to git-merge. This leads to the
confusing behavior where pull.ff=false or pull.ff=only is able to
override merge.ff, while pull.ff=true is unable to.

Fix this by adding the --ff switch if pull.ff=true, and add a test to
catch future regressions.

Furthermore, clarify in the documentation that pull.ff overrides
merge.ff.

Signed-off-by: Paul Tan <pyokagan@gmail.com>
Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agopull: handle --log=<n>
Paul Tan [Mon, 18 May 2015 13:39:56 +0000 (21:39 +0800)]
pull: handle --log=<n>

Since efb779f (merge, pull: add '--(no-)log' command line option,
2008-04-06) git-pull supported the (--no-)log switch and would pass it
to git-merge.

96e9420 (merge: Make '--log' an integer option for number of shortlog
entries, 2010-09-08) implemented support for the --log=<n> switch, which
would explicitly set the number of shortlog entries. However, git-pull
does not recognize this option, and will instead pass it to git-fetch,
leading to "unknown option" errors.

Fix this by matching --log=* in addition to --log and --no-log.

Implement a test for this use case.

Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agosha1_file: pass empty buffer to index empty file
Jim Hill [Mon, 18 May 2015 00:41:45 +0000 (17:41 -0700)]
sha1_file: pass empty buffer to index empty file

`git add` of an empty file with a filter pops complaints from
`copy_fd` about a bad file descriptor.

This traces back to these lines in sha1_file.c:index_core:

if (!size) {
ret = index_mem(sha1, NULL, size, type, path, flags);

The problem here is that content to be added to the index can be
supplied from an fd, or from a memory buffer, or from a pathname. This
call is supplying a NULL buffer pointer and a zero size.

Downstream logic takes the complete absence of a buffer to mean the
data is to be found elsewhere -- for instance, these, from convert.c:

if (params->src) {
write_err = (write_in_full(child_process.in, params->src, params->size) < 0);
} else {
write_err = copy_fd(params->fd, child_process.in);
}

~If there's a buffer, write from that, otherwise the data must be coming
from an open fd.~

Perfectly reasonable logic in a routine that's going to write from
either a buffer or an fd.

So change `index_core` to supply an empty buffer when indexing an empty
file.

There's a patch out there that instead changes the logic quoted above to
take a `-1` fd to mean "use the buffer", but it seems to me that the
distinction between a missing buffer and an empty one carries intrinsic
semantics, where the logic change is adapting the code to handle
incorrect arguments.

Signed-off-by: Jim Hill <gjthill@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agopack-protocol.txt: fix insconsistent spelling of "packfile"
Patrick Steinhardt [Sun, 17 May 2015 06:56:54 +0000 (08:56 +0200)]
pack-protocol.txt: fix insconsistent spelling of "packfile"

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agogit-unpack-objects.txt: fix inconsistent spelling of "packfile"
Patrick Steinhardt [Sun, 17 May 2015 06:56:53 +0000 (08:56 +0200)]
git-unpack-objects.txt: fix inconsistent spelling of "packfile"

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agogit-verify-pack.txt: fix inconsistent spelling of "packfile"
Patrick Steinhardt [Sun, 17 May 2015 06:56:52 +0000 (08:56 +0200)]
git-verify-pack.txt: fix inconsistent spelling of "packfile"

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agohttp-backend: fix die recursion with custom handler
Jeff King [Fri, 15 May 2015 06:29:27 +0000 (02:29 -0400)]
http-backend: fix die recursion with custom handler

When we die() in http-backend, we call a custom handler that
writes an HTTP 500 response to stdout, then reports the
error to stderr. Our routines for writing out the HTTP
response may themselves die, leading to us entering die()
again.

When it was originally written, that was OK; our custom
handler keeps a variable to notice this and does not
recurse. However, since cd163d4 (usage.c: detect recursion
in die routines and bail out immediately, 2012-11-14), the
main die() implementation detects recursion before we even
get to our custom handler, and bails without printing
anything useful.

We can handle this case by doing two things:

  1. Installing a custom die_is_recursing handler that
     allows us to enter up to one level of recursion. Only
     the first call to our custom handler will try to write
     out the error response. So if we die again, that is OK.
     If we end up dying more than that, it is a sign that we
     are in an infinite recursion.

  2. Reporting the error to stderr before trying to write
     out the HTTP response. In the current code, if we do
     die() trying to write out the response, we'll exit
     immediately from this second die(), and never get a
     chance to output the original error (which is almost
     certainly the more interesting one; the second die is
     just going to be along the lines of "I tried to write
     to stdout but it was closed").

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorerere: exit silently on "forget" when rerere is disabled
Jeff King [Thu, 14 May 2015 19:20:52 +0000 (15:20 -0400)]
rerere: exit silently on "forget" when rerere is disabled

If you run "git rerere forget foo" in a repository that does
not have rerere enabled, git hits an internal error:

  $ git init -q
  $ git rerere forget foo
  fatal: BUG: attempt to commit unlocked object

The problem is that setup_rerere() will not actually take
the lock if the rerere system is disabled. We should notice
this and return early. We can return with a success code
here, because we know there is nothing to forget.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agopull: remove --tags error in no merge candidates case
Paul Tan [Wed, 13 May 2015 10:06:47 +0000 (18:06 +0800)]
pull: remove --tags error in no merge candidates case

Since 441ed41 ("git pull --tags": error out with a better message.,
2007-12-28), git pull --tags would print a different error message if
git-fetch did not return any merge candidates:

   It doesn't make sense to pull all tags; you probably meant:
        git fetch --tags

This is because at that time, git-fetch --tags would override any
configured refspecs, and thus there would be no merge candidates. The
error message was thus introduced to prevent confusion.

However, since c5a84e9 (fetch --tags: fetch tags *in addition to*
other stuff, 2013-10-30), git fetch --tags would fetch tags in addition
to any configured refspecs. Hence, if any no merge candidates situation
occurs, it is not because --tags was set. As such, this special error
message is now irrelevant.

To prevent confusion, remove this error message.

Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodoc: convert AsciiDoc {?foo} to ifdef::foo[]
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>
6 years agoGit 2.4.1 v2.4.1
Junio C Hamano [Wed, 13 May 2015 21:11:43 +0000 (14:11 -0700)]
Git 2.4.1

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'sb/line-log-plug-pairdiff-leak' into maint
Junio C Hamano [Wed, 13 May 2015 21:05:56 +0000 (14:05 -0700)]
Merge branch 'sb/line-log-plug-pairdiff-leak' into maint

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

6 years agoMerge branch 'sb/test-bitmap-free-at-end' into maint
Junio C Hamano [Wed, 13 May 2015 21:05:55 +0000 (14:05 -0700)]
Merge branch 'sb/test-bitmap-free-at-end' into maint

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

6 years agoMerge branch 'nd/t1509-chroot-test' into maint
Junio C Hamano [Wed, 13 May 2015 21:05:55 +0000 (14:05 -0700)]
Merge branch 'nd/t1509-chroot-test' into maint

Correct test bitrot.

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

6 years agoMerge branch 'jk/type-from-string-gently' into maint
Junio C Hamano [Wed, 13 May 2015 21:05:54 +0000 (14:05 -0700)]
Merge branch 'jk/type-from-string-gently' into maint

"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

6 years agoMerge branch 'ep/fix-test-lib-functions-report' into maint
Junio C Hamano [Wed, 13 May 2015 21:05:52 +0000 (14:05 -0700)]
Merge branch 'ep/fix-test-lib-functions-report' into maint

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

6 years agoMerge branch 'cn/bom-in-gitignore' into maint
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

6 years agoMerge branch 'jk/prune-mtime' into maint
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

6 years agoMerge branch 'jk/init-core-worktree-at-root' into maint
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

6 years agolog: do not shorten decoration names too early
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.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agolog: decorate HEAD with branch name under --decorate=full, too
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.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodoc: put example URLs and emails inside literal backticks
Jeff King [Wed, 13 May 2015 05:06:21 +0000 (01:06 -0400)]
doc: put example URLs and emails inside literal backticks

This makes sure that AsciiDoc does not turn them into links.
Regular AsciiDoc does not catch these cases, but AsciiDoctor
does treat them as links.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodoc: drop backslash quoting of some curly braces
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>
6 years agodoc: convert \--option to --option
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>
6 years agodoc/add: reformat `--edit` option
Jeff King [Wed, 13 May 2015 04:58:51 +0000 (00:58 -0400)]
doc/add: reformat `--edit` option

All of the other options in the list put short and long as
two separate headings.

We can also drop the backslashing of `--`. It isn't used
elsewhere and is unnecessary for modern asciidoc (plus it
confuses asciidoctor).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodoc: fix length of underlined section-title
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>
6 years agodoc: fix hanging "+"-continuation
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>
6 years agodoc: fix unquoted use of "{type}"
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>
6 years agodoc: fix misrendering due to `single quote'
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>
6 years agodoc: fix unmatched code fences in git-stripspace
Jeff King [Wed, 13 May 2015 02:15:56 +0000 (22:15 -0400)]
doc: fix unmatched code fences in git-stripspace

The asciidoctor renderer is more picky than classic asciidoc,
and insists that the start and end of a code fence be the
same size.

Found with this hacky perl script:

    foreach my $fn (@ARGV) {
      open(my $fh, '<', $fn);
      my ($fence, $fence_lineno, $prev);
      while (<$fh>) {
        chomp;
        if (/^----+$/) {
          if ($fence_lineno) {
            if ($_ ne $fence) {
              print "$fn:$fence_lineno:mismatched fence: ",
                    length($fence), " != ", length($_), "\n";
            }
            $fence_lineno = undef;
          }
  # hacky check to avoid title-underlining
          elsif ($prev eq '' || $prev eq '+') {
            $fence = $_;
            $fence_lineno = $.;
          }
        }
        $prev = $_;
      }
    }

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'mh/write-refs-sooner-2.3' into mh/write-refs-sooner-2.4
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

6 years agoref_transaction_commit(): fix atomicity and avoid fd exhaustion
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.

File descriptor exhaustion
==========================

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>
6 years agoref_transaction_commit(): remove the local flags variable
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>
6 years agoref_transaction_commit(): inline call to write_ref_sha1()
Michael Haggerty [Sat, 9 May 2015 15:29:20 +0000 (17:29 +0200)]
ref_transaction_commit(): inline call to write_ref_sha1()

That was the last caller, so delete function write_ref_sha1().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorename_ref(): inline calls to write_ref_sha1() from this function
Michael Haggerty [Sat, 9 May 2015 15:20:39 +0000 (17:20 +0200)]
rename_ref(): inline calls to write_ref_sha1() from this function

Most of what it does is unneeded from these call sites.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agocommit_ref_update(): new function, extracted from write_ref_sha1()
Michael Haggerty [Sat, 9 May 2015 15:18:36 +0000 (17:18 +0200)]
commit_ref_update(): new function, extracted from write_ref_sha1()

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agowrite_ref_to_lockfile(): new function, extracted from write_ref_sha1()
Michael Haggerty [Fri, 24 Apr 2015 11:35:45 +0000 (13:35 +0200)]
write_ref_to_lockfile(): new function, extracted from write_ref_sha1()

This is the first step towards separating the checking and writing of
the new reference value to committing the change.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
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>
6 years agoupdate-ref: test handling large transactions properly
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>
6 years agoMerge branch 'mh/write-refs-sooner-2.2' into mh/write-refs-sooner-2.3
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

6 years agoref_transaction_commit(): fix atomicity and avoid fd exhaustion
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.

File descriptor exhaustion
==========================

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>
6 years agoref_transaction_commit(): remove the local flags variable
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>
6 years agoref_transaction_commit(): inline call to write_ref_sha1()
Michael Haggerty [Sun, 10 May 2015 02:45:35 +0000 (04:45 +0200)]
ref_transaction_commit(): inline call to write_ref_sha1()

And remove the function write_ref_sha1(), as it is no longer used.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorename_ref(): inline calls to write_ref_sha1() from this function
Michael Haggerty [Sun, 10 May 2015 02:45:34 +0000 (04:45 +0200)]
rename_ref(): inline calls to write_ref_sha1() from this function

Most of what it does is unneeded from these call sites.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agocommit_ref_update(): new function, extracted from write_ref_sha1()
Michael Haggerty [Sun, 10 May 2015 02:45:33 +0000 (04:45 +0200)]
commit_ref_update(): new function, extracted from write_ref_sha1()

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agowrite_ref_to_lockfile(): new function, extracted from write_ref_sha1()
Michael Haggerty [Sun, 10 May 2015 02:45:32 +0000 (04:45 +0200)]
write_ref_to_lockfile(): new function, extracted from write_ref_sha1()

This is the first step towards separating the checking and writing of
the new reference value to committing the change.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
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>
6 years agoadd: check return value of launch_editor
Jeff King [Wed, 13 May 2015 01:21:58 +0000 (21:21 -0400)]
add: check return value of launch_editor

When running "add -e", if launching the editor fails, we do
not notice and continue as if the output is what the user
asked for. The likely case is that the editor did not touch
the contents at all, and we end up adding everything.

Reported-by: Russ Cox <rsc@golang.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agodoc: fix unmatched code fences
Jean-Noel Avila [Tue, 12 May 2015 17:23:20 +0000 (19:23 +0200)]
doc: fix unmatched code fences

This mismatch upsets the renderer on git-scm.com.

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoSync with 2.3.8
Junio C Hamano [Mon, 11 May 2015 21:39:28 +0000 (14:39 -0700)]
Sync with 2.3.8

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoGit 2.3.8 v2.3.8
Junio C Hamano [Mon, 11 May 2015 21:36:31 +0000 (14:36 -0700)]
Git 2.3.8

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'mm/usage-log-l-can-take-regex' into maint-2.3
Junio C Hamano [Mon, 11 May 2015 21:34:01 +0000 (14:34 -0700)]
Merge branch 'mm/usage-log-l-can-take-regex' into maint-2.3

Documentation fix.

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