6 years agodaemon: remove write-only variable maxfd
René Scharfe [Wed, 1 Oct 2014 10:21:57 +0000 (12:21 +0200)]
daemon: remove write-only variable maxfd

It became unused when 6573faff (NO_IPV6 support for git daemon) replaced
select() with poll().

Signed-off-by: Rene Scharfe <>
Signed-off-by: Junio C Hamano <>
6 years agodaemon: fix error message after bind()
René Scharfe [Wed, 1 Oct 2014 10:18:15 +0000 (12:18 +0200)]
daemon: fix error message after bind()

Signed-off-by: Rene Scharfe <>
Signed-off-by: Junio C Hamano <>
6 years agodaemon: handle gethostbyname() error
René Scharfe [Wed, 1 Oct 2014 10:16:17 +0000 (12:16 +0200)]
daemon: handle gethostbyname() error

If the user-supplied hostname can't be found then we should not use it.
We already avoid doing that in the non-NO_IPV6 case by checking if the
return value of getaddrinfo() is zero (success).  Do the same in the
NO_IPV6 case and make sure the return value of gethostbyname() isn't
NULL before dereferencing this pointer.

Signed-off-by: Rene Scharfe <>
Signed-off-by: Junio C Hamano <>
6 years agoDocumentation: fix missing text for rev-parse --verify
brian m. carlson [Mon, 21 Jul 2014 23:00:35 +0000 (23:00 +0000)]
Documentation: fix missing text for rev-parse --verify

The caret (^) is used as a markup symbol in AsciiDoc.  Due to the
inability of AsciiDoc to parse a line containing an unmatched caret, it
omitted the line from the output, resulting in the man page missing the
end of a sentence.  Escape this caret so that the man page ends up with
the complete text.

Signed-off-by: brian m. carlson <>
Signed-off-by: Junio C Hamano <>
6 years agoannotate: use argv_array
René Scharfe [Wed, 16 Jul 2014 08:51:33 +0000 (10:51 +0200)]
annotate: use argv_array

Simplify the code and get rid of some magic constants by using
argv_array to build the argument list for cmd_blame.  Be lazy and let
the OS release our allocated memory, as before.

Signed-off-by: Rene Scharfe <>
Signed-off-by: Junio C Hamano <>
6 years agot7300: repair filesystem permissions with test_when_finished
Jeff King [Wed, 2 Jul 2014 18:44:30 +0000 (14:44 -0400)]
t7300: repair filesystem permissions with test_when_finished

We create a directory that cannot be removed, confirm that
it cannot be removed, and then fix it like:

  chmod 0 foo &&
  test_must_fail git clean -d -f &&
  chmod 755 foo

If the middle step fails but leaves the directory (e.g., the
bug is that clean does not notice the failure), this
pollutes the test repo with an unremovable directory. Not
only does this cause further tests to fail, but it means
that "rm -rf" fails on the whole trash directory, and the
user has to intervene manually to even re-run the test script.

We can bump the "chmod 755" recovery to a test_when_finished
block to be sure that it always runs.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
6 years agoenums: remove trailing ',' after last item in enum
Ronnie Sahlberg [Wed, 2 Jul 2014 18:24:05 +0000 (11:24 -0700)]
enums: remove trailing ',' after last item in enum

Signed-off-by: Ronnie Sahlberg <>
Signed-off-by: Junio C Hamano <>
7 years agoGit v1.8.5.5
Junio C Hamano [Thu, 13 Feb 2014 21:40:47 +0000 (13:40 -0800)]

Signed-off-by: Junio C Hamano <>
7 years agoMerge branch 'bm/merge-base-octopus-dedup' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:38:59 +0000 (13:38 -0800)]
Merge branch 'bm/merge-base-octopus-dedup' into maint

"git merge-base --octopus" used to leave cleaning up suboptimal
result to the caller, but now it does the clean-up itself.

* bm/merge-base-octopus-dedup:
  merge-base --octopus: reduce the result from get_octopus_merge_bases()
  merge-base: separate "--independent" codepath into its own helper

7 years agoMerge branch 'jc/revision-range-unpeel' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:38:47 +0000 (13:38 -0800)]
Merge branch 'jc/revision-range-unpeel' into maint

"git log --left-right A...B" lost the "leftness" of commits
reachable from A when A is a tag as a side effect of a recent
bugfix.  This is a regression in 1.8.4.x series.

* jc/revision-range-unpeel:
  revision: propagate flag bits from tags to pointees
  revision: mark contents of an uninteresting tree uninteresting

7 years agoMerge branch 'jk/allow-fetch-onelevel-refname' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:38:34 +0000 (13:38 -0800)]
Merge branch 'jk/allow-fetch-onelevel-refname' into maint

"git clone" would fail to clone from a repository that has a ref
directly under "refs/", e.g. "refs/stash", because different
validation paths do different things on such a refname.  Loosen the
client side's validation to allow such a ref.

* jk/allow-fetch-onelevel-refname:
  fetch-pack: do not filter out one-level refs

7 years agoMerge branch 'jk/interpret-branch-name-fix' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:38:25 +0000 (13:38 -0800)]
Merge branch 'jk/interpret-branch-name-fix' into maint

A handful of bugs around interpreting $branch@{upstream} notation
and its lookalike, when $branch part has interesting characters,
e.g. "@", and ":", have been fixed.

* jk/interpret-branch-name-fix:
  interpret_branch_name: find all possible @-marks
  interpret_branch_name: avoid @{upstream} past colon
  interpret_branch_name: always respect "namelen" parameter
  interpret_branch_name: rename "cp" variable to "at"
  interpret_branch_name: factor out upstream handling

7 years agoMerge branch 'rk/send-email-ssl-cert' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:38:19 +0000 (13:38 -0800)]
Merge branch 'rk/send-email-ssl-cert' into maint

A recent update to "git send-email" broke platforms where
/etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path
(e.g. Fedora rawhide).

* rk/send-email-ssl-cert:
  send-email: /etc/ssl/certs/ directory may not be usable as ca_path

7 years agoMerge branch 'sb/repack-in-c' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:38:09 +0000 (13:38 -0800)]
Merge branch 'sb/repack-in-c' into maint

"git repack --max-pack-size=8g" stopped being parsed correctly when
the command was reimplemented in C.

* sb/repack-in-c:
  repack: propagate pack-objects options as strings
  repack: make parsed string options const-correct
  repack: fix typo in max-pack-size option

7 years agoMerge branch 'as/tree-walk-fix-aggressive-short-cut' into maint
Junio C Hamano [Thu, 13 Feb 2014 21:37:53 +0000 (13:37 -0800)]
Merge branch 'as/tree-walk-fix-aggressive-short-cut' into maint

The pathspec matching code, while comparing two trees (e.g. "git
diff A B -- path1 path2") was too aggressive and failed to match
some paths when multiple pathspecs were involved.

* as/tree-walk-fix-aggressive-short-cut:
  tree_entry_interesting: match against all pathspecs

7 years agoGit v1.8.5.4
Junio C Hamano [Wed, 5 Feb 2014 22:05:31 +0000 (14:05 -0800)]

Signed-off-by: Junio C Hamano <>
7 years agoMerge branch 'jc/maint-pull-docfix' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:03:47 +0000 (14:03 -0800)]
Merge branch 'jc/maint-pull-docfix' into maint

The documentation to "git pull" hinted there is an "-m" option
because it incorrectly shared the documentation with "git merge".

* jc/maint-pull-docfix:
  Documentation: "git pull" does not have the "-m" option
  Documentation: exclude irrelevant options from "git pull"

7 years agoMerge branch 'ow/stash-with-ifs' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:03:20 +0000 (14:03 -0800)]
Merge branch 'ow/stash-with-ifs' into maint

The implementation of 'git stash $cmd "stash@{...}"' did not quote
the stash argument properly and left it split at IFS whitespace.

* ow/stash-with-ifs:
  stash: handle specifying stashes with $IFS

7 years agoMerge branch 'js/lift-parent-count-limit' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:03:01 +0000 (14:03 -0800)]
Merge branch 'js/lift-parent-count-limit' into maint

There is no reason to have a hardcoded upper limit of the number of
parents for an octopus merge, created via the graft mechanism, but
there was.

* js/lift-parent-count-limit:
  Remove the line length limit for graft files

7 years agoMerge branch 'nd/add-empty-fix' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:02:44 +0000 (14:02 -0800)]
Merge branch 'nd/add-empty-fix' into maint

"git add -A" (no other arguments) in a totally empty working tree
used to emit an error.

* nd/add-empty-fix:
  add: don't complain when adding empty project root

7 years agoMerge branch 'bc/log-decoration' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:02:05 +0000 (14:02 -0800)]
Merge branch 'bc/log-decoration' into maint

"git log --decorate" did not handle a tag pointed by another tag

* bc/log-decoration:
  log: properly handle decorations with chained tags

7 years agoMerge branch 'jh/rlimit-nofile-fallback' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:01:23 +0000 (14:01 -0800)]
Merge branch 'jh/rlimit-nofile-fallback' into maint

When we figure out how many file descriptors to allocate for
keeping packfiles open, a system with non-working getrlimit() could
cause us to die(), but because we make this call only to get a
rough estimate of how many is available and we do not even attempt
to use up all file descriptors available ourselves, it is nicer to
fall back to a reasonable low value rather than dying.

* jh/rlimit-nofile-fallback:
  get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure

7 years agoMerge branch 'jl/commit-v-strip-marker' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:01:09 +0000 (14:01 -0800)]
Merge branch 'jl/commit-v-strip-marker' into maint

"git commit -v" appends the patch to the log message before
editing, and then removes the patch when the editor returned
control. However, the patch was not stripped correctly when the
first modified path was a submodule.

* jl/commit-v-strip-marker:
  commit -v: strip diffs and submodule shortlogs from the commit message

7 years agoMerge branch 'tr/send-email-ssl' into maint
Junio C Hamano [Wed, 5 Feb 2014 22:00:18 +0000 (14:00 -0800)]
Merge branch 'tr/send-email-ssl' into maint

SSL-related options were not passed correctly to underlying socket
layer in "git send-email".

* tr/send-email-ssl:
  send-email: set SSL options through IO::Socket::SSL::set_client_defaults
  send-email: --smtp-ssl-cert-path takes an argument
  send-email: pass Debug to Net::SMTP::SSL::new

7 years agoMerge branch 'tb/clone-ssh-with-colon-for-port' into maint
Junio C Hamano [Wed, 5 Feb 2014 21:59:16 +0000 (13:59 -0800)]
Merge branch 'tb/clone-ssh-with-colon-for-port' into maint

Remote repository URL expressed in scp-style host:path notation are
parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks
to connect to user's home directory on host at address ::1.

* tb/clone-ssh-with-colon-for-port:
  git_connect(): use common return point
  connect.c: refactor url parsing
  git_connect(): refactor the port handling for ssh
  git fetch: support host:/~repo
  t5500: add test cases for diag-url
  git fetch-pack: add --diag-url
  git_connect: factor out discovery of the protocol and its parts
  git_connect: remove artificial limit of a remote command
  t5601: add tests for ssh
  t5601: remove clear_ssh, refactor setup_ssh_wrapper

7 years agoMerge branch 'nd/transport-positive-depth-only' into maint
Junio C Hamano [Wed, 5 Feb 2014 21:58:51 +0000 (13:58 -0800)]
Merge branch 'nd/transport-positive-depth-only' into maint

"git fetch --depth=0" was a no-op, and was silently ignored.
Diagnose it as an error.

* nd/transport-positive-depth-only:
  clone,fetch: catch non positive --depth option value

7 years agotree_entry_interesting: match against all pathspecs
Andy Spencer [Sat, 25 Jan 2014 22:06:46 +0000 (22:06 +0000)]
tree_entry_interesting: match against all pathspecs

The current basedir compare aborts early in order to avoid futile
recursive searches. However, a match may still be found by another
pathspec. This can cause an error while checking out files from a branch
when using multiple pathspecs:

$ git checkout master -- 'a/*.txt' 'b/*.txt'
error: pathspec 'a/*.txt' did not match any file(s) known to git.

Signed-off-by: Andy Spencer <>
Acked-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
7 years agorepack: propagate pack-objects options as strings
Jeff King [Thu, 23 Jan 2014 01:30:13 +0000 (20:30 -0500)]
repack: propagate pack-objects options as strings

In the original shell version of git-repack, any options
destined for pack-objects were left as strings, and passed
as a whole. Since the C rewrite in commit a1bbc6c (repack:
rewrite the shell script in C, 2013-09-15), we now parse
these values to integers internally, then reformat the
integers when passing the option to pack-objects.

This has the advantage that we catch format errors earlier
(i.e., when repack is invoked, rather than when pack-objects
is invoked).

It has three disadvantages, though:

  1. Our internal data types may not be the right size. In
     the case of "--window-memory" and "--max-pack-size",
     these are "unsigned long" in pack-objects, but we can
     only represent a regular "int".

  2. Our parsing routines might not be the same as those of
     pack-objects. For the two options above, pack-objects
     understands "100m" to mean "100 megabytes", but repack
     does not.

  3. We have to keep a sentinel value to know whether it is
     worth passing the option along. In the case of
     "--window-memory", we currently do not pass it if the
     value is "0". But that is a meaningful value to
     pack-objects, where it overrides any configured value.

We can fix all of these by simply passing the strings from
the user along to pack-objects verbatim. This does not
actually fix anything for "--depth" or "--window", but these
are converted, too, for consistency.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agorepack: make parsed string options const-correct
Jeff King [Thu, 23 Jan 2014 01:28:30 +0000 (20:28 -0500)]
repack: make parsed string options const-correct

When we use OPT_STRING to parse an option, we get back a
pointer into the argv array, which should be "const char *".
The compiler doesn't notice because it gets passed through a
"void *" in the option struct.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agorepack: fix typo in max-pack-size option
Jeff King [Thu, 23 Jan 2014 01:27:52 +0000 (20:27 -0500)]
repack: fix typo in max-pack-size option

When we see "--max-pack-size", we accidentally propagated
this to pack-objects as "--max_pack_size", which does not
work at all.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agogit-svn: workaround for a bug in svn serf backend
Roman Kagan [Fri, 27 Dec 2013 08:05:15 +0000 (12:05 +0400)]
git-svn: workaround for a bug in svn serf backend

Subversion serf backend in versions 1.8.5 and below has a bug(*) that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when storing it on the
returned descriptor.  As a result, by the time this field is used (in
transactions of file copying or renaming) it may well be released, and
the memory reused.

One of its possible manifestations is the svn assertion triggering on an
invalid path, with a message

svn_fspath__skip_ancestor: Assertion
`svn_fspath__is_canonical(child_fspath)' failed.

This patch works around this bug, by storing the value to be passed as
the third argument to add_file() in a local variable with the same scope
as the file change descriptor, making sure their lifetime is the same.

* [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder]

Cc: Benjamin Pabst <>
Signed-off-by: Eric Wong <>
Reviewed-by: Jonathan Nieder <>
Signed-off-by: Roman Kagan <>
7 years agosend-email: /etc/ssl/certs/ directory may not be usable as ca_path
Ruben Kerkhof [Wed, 15 Jan 2014 17:31:11 +0000 (21:31 +0400)]
send-email: /etc/ssl/certs/ directory may not be usable as ca_path

When sending patches on Fedora rawhide with
git- and perl-IO-Socket-SSL-1.962-1.fc21.noarch,
with the following

    smtpencryption = tls
    smtpserver =
    smtpuser =
    smtpserverport = 587

git-send-email fails with:

    STARTTLS failed! SSL connect attempt failed with unknown error
    error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
    verify failed at /usr/libexec/git-core/git-send-email line 1236.

The current code detects the presence of /etc/ssl/certs directory
(it actually is a symlink to another directory, but that does not
matter) and uses SSL_ca_path to point at it when initializing the
connection with IO::Socket::SSL or Net::SMTP::SSL.  However, on the
said platform, it seems that this directory is not designed to be
used as SSL_ca_path.  Using a single file inside that directory
(cert.pem, which is a Mozilla CA bundle) with SSL_ca_file does work,
and also not specifying any SSL_ca_file/SSL_ca_path (and letting the
library use its own default) and asking for peer verification does

By removing the code that blindly defaults $smtp_ssl_cert_path to
"/etc/ssl/certs", we can prevent the codepath that treats any
directory specified with that variable as usable for SSL_ca_path
from incorrectly triggering.

This change could introduce a regression for people on a platform
whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL
somehow fails to use it as SSL_ca_path without being told.  Using
/etc/ssl/certs directory as SSL_ca_path by default like the current
code does would have been hiding such a broken installation without
its user needing to do anything.  These users can still work around
such a platform bug by setting the configuration variable explicitly
to point at /etc/ssl/certs.

This change should not negate what 35035bbf (send-email: be explicit
with SSL certificate verification, 2013-07-18), which was the
original change that introduced the defaulting to /etc/ssl/certs/,
attempted to do, which is to make sure we do not communicate over
insecure connection by default, triggering warning from the library.


Tested-by: Igor Gnatenko <>
Signed-off-by: Ruben Kerkhof <>
Signed-off-by: Junio C Hamano <>
7 years agorevision: propagate flag bits from tags to pointees
Junio C Hamano [Wed, 15 Jan 2014 20:26:13 +0000 (12:26 -0800)]
revision: propagate flag bits from tags to pointees

With the previous fix 895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the "git log" family of commands no
longer directly places the object pointed by the tag in the pending
object array when it sees a tag object.  We used to place pointee
there after copying the flag bits like UNINTERESTING and

This change meant that any flag that is relevant to later history
traversal must now be propagated to the pointed objects (most often
these are commits) while starting the traversal, which is partly
done by handle_commit() that is called from prepare_revision_walk().
We did propagate UNINTERESTING, but did not do so for others, most
notably SYMMETRIC_LEFT.  This caused "git log --left-right v1.0..."
(where "v1.0" is a tag) to start losing the "leftness" from the
commit the tag points at.

Signed-off-by: Junio C Hamano <>
7 years agorevision: mark contents of an uninteresting tree uninteresting
Junio C Hamano [Wed, 15 Jan 2014 23:38:01 +0000 (15:38 -0800)]
revision: mark contents of an uninteresting tree uninteresting

"git rev-list --objects ^A^{tree} B^{tree}" ought to mean "I want a
list of objects inside B's tree, but please exclude the objects that
appear inside A's tree".

we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
unfortunately prevents us from recursing into the tree and marking
the objects in the tree as uninteresting.

The reason why "git log ^A A" yields an empty set of commits,
i.e. we do not have a similar issue for commits, is because we call
mark_parents_uninteresting() after seeing an uninteresting commit.
The uninteresting-ness of the commit itself does not prevent its
parents from being marked as uninteresting.

Introduce mark_tree_contents_uninteresting() and structure the code
in handle_commit() in such a way that it makes it the responsibility
of the callchain leading to this function to mark commits, trees and
blobs as uninteresting, and also make it the responsibility of the
helpers called from this function to mark objects that are reachable
from them.

Note that this is a very old bug that probably dates back to the day
when "rev-list --objects" was introduced.  The line to clear
tree->object.parsed at the end of mark_tree_contents_uninteresting()
can be removed when this fix is merged to the codebase after
6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05).

Signed-off-by: Junio C Hamano <>
7 years agointerpret_branch_name: find all possible @-marks
Jeff King [Wed, 15 Jan 2014 08:40:46 +0000 (03:40 -0500)]
interpret_branch_name: find all possible @-marks

When we parse a string like "foo@{upstream}", we look for
the first "@"-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see "@foo@{upstream}". In this case, we check only the
first @, and ignore the second. As a result, we do not find
the upstream.

We can solve this by iterating through all @-marks in the
string, and seeing if any is a legitimate upstream or
empty-at mark.

Another strategy would be to parse from the right-hand side
of the string. However, that does not work for the
"empty_at" case, which allows "@@{upstream}". We need to
find the left-most one in this case (and we then recurse as

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agointerpret_branch_name: avoid @{upstream} past colon
Jeff King [Wed, 15 Jan 2014 08:37:23 +0000 (03:37 -0500)]
interpret_branch_name: avoid @{upstream} past colon

get_sha1() cannot currently parse a valid object name like
"HEAD:@{upstream}" (assuming that such an oddly named file
exists in the HEAD commit). It takes two passes to parse the

  1. It first considers the whole thing as a ref, which
     results in looking for the upstream of "HEAD:".

  2. It finds the colon, parses "HEAD" as a tree-ish, and then
     finds the path "@{upstream}" in the tree.

For a path that looks like a normal reflog (e.g.,
"HEAD:@{yesterday}"), the first pass is a no-op. We try to
dwim_ref("HEAD:"), that returns zero refs, and we proceed
with colon-parsing.

For "HEAD:@{upstream}", though, the first pass ends up in
interpret_upstream_mark, which tries to find the branch
"HEAD:". When it sees that the branch does not exist, it
actually dies rather than returning an error to the caller.
As a result, we never make it to the second pass.

One obvious way of fixing this would be to teach
interpret_upstream_mark to simply report "no, this isn't an
upstream" in such a case. However, that would make the
error-reporting for legitimate upstream cases significantly
worse. Something like "bogus@{upstream}" would simply report
"unknown revision: bogus@{upstream}", while the current code
diagnoses a wide variety of possible misconfigurations (no
such branch, branch exists but does not have upstream, etc).

However, we can take advantage of the fact that a branch
name cannot contain a colon. Therefore even if we find an
upstream mark, any prefix with a colon must mean that
the upstream mark we found is actually a pathname, and
should be disregarded completely. This patch implements that

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agointerpret_branch_name: always respect "namelen" parameter
Jeff King [Wed, 15 Jan 2014 08:31:57 +0000 (03:31 -0500)]
interpret_branch_name: always respect "namelen" parameter

interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".

However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.

Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given.  This can result in us mis-parsing
object names.  We should instead be limiting our search to
"namelen" bytes.

There are three distinct types of object names this patch

  - The intrepret_empty_at helper uses strchr to find the
    next @-expression after our potential empty-at.  In an
    expression like "@:foo@bar", it erroneously thinks that
    the second "@" is relevant, even if we were asked only
    to look at the first character. This case is easy to
    trigger (and we test it in this patch).

  - When finding the initial @-mark for @{upstream}, we use
    strchr.  This means we might treat "foo:@{upstream}" as
    the upstream for "foo:", even though we were asked only
    to look at "foo". We cannot test this one in practice,
    because it is masked by another bug (which is fixed in
    the next patch).

  - The interpret_nth_prior_checkout helper did not receive
    the name length at all. This turns out not to be a
    problem in practice, though, because its parsing is so
    limited: it always starts from the far-left of the
    string, and will not tolerate a colon (which is
    currently the only way to get a smaller-than-strlen
    "namelen"). However, it's still worth fixing to make the
    code more obviously correct, and to future-proof us
    against callers with more exotic buffers.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agointerpret_branch_name: rename "cp" variable to "at"
Jeff King [Wed, 15 Jan 2014 08:27:32 +0000 (03:27 -0500)]
interpret_branch_name: rename "cp" variable to "at"

In the original version of this function, "cp" acted as a
pointer to many different things. Since the refactoring in
the last patch, it only marks the at-sign in the string.
Let's use a more descriptive variable name.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agointerpret_branch_name: factor out upstream handling
Jeff King [Wed, 15 Jan 2014 08:26:33 +0000 (03:26 -0500)]
interpret_branch_name: factor out upstream handling

This function checks a few different @{}-constructs. The
early part checks for and dispatches us to helpers for each
construct, but the code for handling @{upstream} is inline.

Let's factor this out into its own function. This makes
interpret_branch_name more readable, and will make it much
simpler to further refactor the function in future patches.

While we're at it, let's also break apart the refactored
code into a few helper functions. These will be useful if we
eventually implement similar @{upstream}-like constructs.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agofetch-pack: do not filter out one-level refs
Jeff King [Wed, 15 Jan 2014 10:46:13 +0000 (05:46 -0500)]
fetch-pack: do not filter out one-level refs

Currently fetching a one-level ref like "refs/foo" does not
work consistently. The outer "git fetch" program filters the
list of refs, checking each against check_refname_format.
Then it feeds the result to do_fetch_pack to actually
negotiate the haves/wants and get the pack. The fetch-pack
code does its own filter, and it behaves differently.

The fetch-pack filter looks for refs in "refs/", and then
feeds everything _after_ the slash (i.e., just "foo") into
check_refname_format.  But check_refname_format is not
designed to look at a partial refname. It complains that the
ref has only one component, thinking it is at the root
(i.e., alongside "HEAD"), when in reality we just fed it a
partial refname.

As a result, we omit a ref like "refs/foo" from the pack
request, even though "git fetch" then tries to store the
resulting ref.  If we happen to get the object anyway (e.g.,
because the ref is contained in another ref we are
fetching), then the fetch succeeds. But if it is a unique
object, we fail when trying to update "refs/foo".

We can fix this by just passing the whole refname into
check_refname_format; we know the part we were omitting is
"refs/", which is acceptable in a refname. This at least
makes the checks consistent with each other.

This problem happens most commonly with "refs/stash", which
is the only one-level ref in wide use. However, our test
does not use "refs/stash", as we may later want to restrict
it specifically (not because it is one-level, but because
of the semantics of stashes).

We may also want to do away with the multiple levels of
filtering (which can cause problems when they are out of
sync), or even forbid one-level refs entirely. However,
those decisions can come later; this fixes the most
immediate problem, which is the mismatch between the two.

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agoDocumentation: "git pull" does not have the "-m" option
Junio C Hamano [Tue, 14 Jan 2014 18:26:21 +0000 (10:26 -0800)]
Documentation: "git pull" does not have the "-m" option

Even though "--[no-]edit" can be used with "git pull", the
explanation of the interaction between this option and the "-m"
option does not make sense within the context of "git pull".  Use
the conditional inclusion mechanism to remove this part from "git
pull" documentation, while keeping it for "git merge".

Reported-by: Ivan Zakharyaschev
Signed-off-by: Junio C Hamano <>
7 years agoMerge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfix
Junio C Hamano [Tue, 14 Jan 2014 18:47:09 +0000 (10:47 -0800)]
Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfix

* jc/maint-pull-docfix-for-409b8d82:
  Documentation: exclude irrelevant options from "git pull"

7 years agoDocumentation: exclude irrelevant options from "git pull"
Junio C Hamano [Tue, 14 Jan 2014 18:26:21 +0000 (10:26 -0800)]
Documentation: exclude irrelevant options from "git pull"

10eb64f5 (git pull manpage: don't include -n from fetch-options.txt,
2008-01-25) introduced a way to exclude some parts of included
source when building git-pull documentation, and later 409b8d82
(Documentation/git-pull: put verbosity options before merge/fetch
ones, 2010-02-24) attempted to use the mechanism to exclude some
parts of merge-options.txt when used from git-pull.txt.

However, the latter did not have an intended effect, because the
macro "git-pull" used to decide if the source is included in
git-pull documentation were defined a bit too late.

Define the macro before it is used to fix this.

Signed-off-by: Junio C Hamano <>
7 years agoGit v1.8.5.3
Junio C Hamano [Mon, 13 Jan 2014 19:28:26 +0000 (11:28 -0800)]

7 years agoMerge branch 'nd/daemon-informative-errors-typofix' into maint
Junio C Hamano [Mon, 13 Jan 2014 19:23:07 +0000 (11:23 -0800)]
Merge branch 'nd/daemon-informative-errors-typofix' into maint

The "--[no-]informative-errors" options to "git daemon" were parsed
a bit too loosely, allowing any other string after these option

* nd/daemon-informative-errors-typofix:
  daemon: be strict at parsing parameters --[no-]informative-errors

7 years agoMerge branch 'km/gc-eperm' into maint
Junio C Hamano [Mon, 13 Jan 2014 19:23:04 +0000 (11:23 -0800)]
Merge branch 'km/gc-eperm' into maint

A "gc" process running as a different user should be able to stop a
new "gc" process from starting.

* km/gc-eperm:
  gc: notice gc processes run by other users

7 years agoMerge branch 'jk/credential-plug-leak' into maint
Junio C Hamano [Mon, 13 Jan 2014 19:23:01 +0000 (11:23 -0800)]
Merge branch 'jk/credential-plug-leak' into maint

An earlier "clean-up" introduced an unnecessary memory leak.

* jk/credential-plug-leak:
  Revert "prompt: clean up strbuf usage"

7 years agoMerge branch 'mm/mv-file-to-no-such-dir-with-slash' into maint
Junio C Hamano [Mon, 13 Jan 2014 19:22:48 +0000 (11:22 -0800)]
Merge branch 'mm/mv-file-to-no-such-dir-with-slash' into maint

"git mv A B/", when B does not exist as a directory, should error
out, but it didn't.

* mm/mv-file-to-no-such-dir-with-slash:
  mv: let 'git mv file no-such-dir/' error out on Windows, too
  mv: let 'git mv file no-such-dir/' error out

7 years agoMerge branch 'jk/rev-parse-double-dashes' into maint
Junio C Hamano [Mon, 13 Jan 2014 19:22:38 +0000 (11:22 -0800)]
Merge branch 'jk/rev-parse-double-dashes' into maint

"git rev-parse <revs> -- <paths>" did not implement the usual
disambiguation rules the commands in the "git log" family used in
the same way.

* jk/rev-parse-double-dashes:
  rev-parse: be more careful with munging arguments
  rev-parse: correctly diagnose revision errors before "--"

7 years agoMerge branch 'jk/cat-file-regression-fix' into maint
Junio C Hamano [Mon, 13 Jan 2014 19:22:21 +0000 (11:22 -0800)]
Merge branch 'jk/cat-file-regression-fix' into maint

"git cat-file --batch=", an admittedly useless command, did not
behave very well.

* jk/cat-file-regression-fix:
  cat-file: handle --batch format with missing type/size
  cat-file: pass expand_data to print_object_or_die

7 years agopack-heuristics.txt: mark up the file header properly
Thomas Ackermann [Sat, 11 Jan 2014 16:28:25 +0000 (17:28 +0100)]
pack-heuristics.txt: mark up the file header properly

AsciiDoc wants these header-lines left-aligned.

Signed-off-by: Thomas Ackermann <>
Signed-off-by: Junio C Hamano <>
7 years agomv: let 'git mv file no-such-dir/' error out on Windows, too
Johannes Sixt [Wed, 8 Jan 2014 16:33:44 +0000 (17:33 +0100)]
mv: let 'git mv file no-such-dir/' error out on Windows, too

The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out)
relies on that rename("file", "no-such-dir/") fails if the directory does not
exist (note the trailing slash).  This does not work as expected on Windows:
This rename() call does not fail, but renames "file" to "no-such-dir" (not to
"no-such-dir/file"). Insert an explicit check for this case to force an error.

This changes the error message from

   $ git mv file no-such-dir/
   fatal: renaming 'file' failed: Not a directory


   $ git mv file no-such-dir/
   fatal: destination directory does not exist, source=file, destination=no-such-dir/

Signed-off-by: Johannes Sixt <>
Signed-off-by: Junio C Hamano <>
7 years agostash: handle specifying stashes with $IFS
Øystein Walle [Tue, 7 Jan 2014 08:22:15 +0000 (09:22 +0100)]
stash: handle specifying stashes with $IFS

When trying to pop/apply a stash specified with an argument
containing IFS whitespace, git-stash will throw an error:

    $ git stash pop 'stash@{two hours ago}'
    Too many revisions specified: stash@{two hours ago}

This happens because word splitting is used to count non-option
arguments. Make use of rev-parse's --sq option to quote the arguments
for us to ensure a correct count. Add quotes where necessary.

Also add a test that verifies correct behaviour.

Helped-by: Thomas Rast <>
Signed-off-by: Øystein Walle <>
Signed-off-by: Junio C Hamano <>
7 years agoMerge branch 'maint' of git:// into maint
Junio C Hamano [Mon, 6 Jan 2014 17:10:09 +0000 (09:10 -0800)]
Merge branch 'maint' of git:// into maint

* 'maint' of git://
  l10n: de.po: fix translation of 'prefix'

7 years agoDocumentation/gitmodules: Only 'update' and 'url' are required
W. Trevor King [Fri, 3 Jan 2014 18:31:22 +0000 (10:31 -0800)]
Documentation/gitmodules: Only 'update' and 'url' are required

Descriptions for all the settings fell under the initial "Each
submodule section also contains the following required keys:".  The
example shows sections with just 'path' and 'url' entries, which are
indeed required, but we should still make the required/optional
distinction explicit to clarify that the rest of them are optional.

Signed-off-by: W. Trevor King <>
Reviewed-by: Heiko Voigt <>
Signed-off-by: Junio C Hamano <>
7 years agol10n: de.po: fix translation of 'prefix'
Ralf Thielow [Fri, 3 Jan 2014 17:05:43 +0000 (18:05 +0100)]
l10n: de.po: fix translation of 'prefix'

The word 'prefix' is currently translated as 'Prefix'
which is not a German word. It should be translated as

Signed-off-by: Ralf Thielow <>
7 years agogc: notice gc processes run by other users
Kyle J. McKay [Tue, 31 Dec 2013 12:07:39 +0000 (04:07 -0800)]
gc: notice gc processes run by other users

Since 64a99eb4 git gc refuses to run without the --force option if
another gc process on the same repository is already running.

However, if the repository is shared and user A runs git gc on the
repository and while that gc is still running user B runs git gc on
the same repository the gc process run by user A will not be noticed
and the gc run by user B will go ahead and run.

The problem is that the kill(pid, 0) test fails with an EPERM error
since user B is not allowed to signal processes owned by user A
(unless user B is root).

Update the test to recognize an EPERM error as meaning the process
exists and another gc should not be run (unless --force is given).

Signed-off-by: Kyle J. McKay <>
Signed-off-by: Junio C Hamano <>
7 years agoRevert "prompt: clean up strbuf usage"
Jeff King [Thu, 2 Jan 2014 03:03:30 +0000 (22:03 -0500)]
Revert "prompt: clean up strbuf usage"

This reverts commit 31b49d9b653803e7c7fd18b21c8bdd86e3421668.

That commit taught do_askpass to hand ownership of our
buffer back to the caller rather than simply return a
pointer into our internal strbuf.  What it failed to notice,
though, was that our internal strbuf is static, because we
are trying to emulate the getpass() interface.

By handing off ownership, we created a memory leak that
cannot be solved. Sometimes git_prompt returns a static
buffer from getpass() (or our smarter git_terminal_prompt
wrapper), and sometimes it returns an allocated string from

Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agofor-each-ref: remove unused variable
Ramkumar Ramachandra [Mon, 30 Dec 2013 16:28:55 +0000 (21:58 +0530)]
for-each-ref: remove unused variable

No code ever used this symbol since the command was introduced at
9f613ddd (Add git-for-each-ref: helper for language bindings,

Signed-off-by: Ramkumar Ramachandra <>
Signed-off-by: Junio C Hamano <>
7 years agomerge-base --octopus: reduce the result from get_octopus_merge_bases()
Junio C Hamano [Mon, 30 Dec 2013 19:58:54 +0000 (11:58 -0800)]
merge-base --octopus: reduce the result from get_octopus_merge_bases()

Scripts that use "merge-base --octopus" could do the reducing
themselves, but most of them are expected to want to get the reduced
results without having to do any work themselves.

Tests are taken from a message by Василий Макаров

Signed-off-by: Junio C Hamano <>

 We might want to vet the existing callers of the underlying
 get_octopus_merge_bases() and find out if _all_ of them are doing
 anything extra (like deduping) because the machinery can return
 duplicate results. And if that is the case, then we may want to
 move the dedupling down the callchain instead of having it here.

7 years agomerge-base: separate "--independent" codepath into its own helper
Junio C Hamano [Mon, 30 Dec 2013 19:37:49 +0000 (11:37 -0800)]
merge-base: separate "--independent" codepath into its own helper

It piggybacks on an unrelated handle_octopus() function only because
there are some similarities between the way they need to preprocess
their input and output their result.  There is nothing similar in
the true logic between these two operations.

Signed-off-by: Junio C Hamano <>
7 years agoRemove the line length limit for graft files
Johannes Schindelin [Fri, 27 Dec 2013 20:49:57 +0000 (21:49 +0100)]
Remove the line length limit for graft files

Support for grafts predates Git's strbuf, and hence it is understandable
that there was a hard-coded line length limit of 1023 characters (which
was chosen a bit awkwardly, given that it is *exactly* one byte short of
aligning with the 41 bytes occupied by a commit name and the following
space or new-line character).

While regular commit histories hardly win comprehensibility in general
if they merge more than twenty-two branches in one go, it is not Git's
business to limit grafts in such a way.

In this particular developer's case, the use case that requires
substantially longer graft lines to be supported is the visualization of
the commits' order implied by their changes: commits are considered to
have an implicit relationship iff exchanging them in an interactive
rebase would result in merge conflicts.

Thusly implied branches tend to be very shallow in general, and the
resulting thicket of implied branches is usually very wide; It is
actually quite common that *most* of the commits in a topic branch have
not even one implied parent, so that a final merge commit has about as
many implied parents as there are commits in said branch.

[jc: squashed in tests by Jonathan]

Signed-off-by: Johannes Schindelin <>
Reviewed-by: Jonathan Nieder <>
Signed-off-by: Junio C Hamano <>
7 years agoadd: don't complain when adding empty project root
Nguyễn Thái Ngọc Duy [Mon, 23 Dec 2013 09:02:41 +0000 (16:02 +0700)]
add: don't complain when adding empty project root

This behavior was added in 07d7bed (add: don't complain when adding
empty project root - 2009-04-28) then broken by 84b8b5d (remove
match_pathspec() in favor of match_pathspec_depth() -
2013-07-14). Reinstate it.

Noticed-by: Thomas Ferris Nicolaisen <>
Signed-off-by: Nguyễn Thái Ngọc Duy <>
Reviewed-by: Jonathan Nieder <>
Signed-off-by: Junio C Hamano <>
7 years agolog: properly handle decorations with chained tags
brian m. carlson [Tue, 17 Dec 2013 04:28:21 +0000 (04:28 +0000)]
log: properly handle decorations with chained tags

git log did not correctly handle decorations when a tag object referenced
another tag object that was no longer a ref, such as when the second tag was
deleted.  The commit would not be decorated correctly because parse_object had
not been called on the second tag and therefore its tagged field had not been
filled in, resulting in none of the tags being associated with the relevant

Call parse_object to fill in this field if it is absent so that the chain of
tags can be dereferenced and the commit can be properly decorated.  Include
tests as well to prevent future regressions.

Signed-off-by: brian m. carlson <>
Signed-off-by: Junio C Hamano <>
7 years agodaemon: be strict at parsing parameters --[no-]informative-errors
Nguyễn Thái Ngọc Duy [Fri, 20 Dec 2013 10:53:52 +0000 (17:53 +0700)]
daemon: be strict at parsing parameters --[no-]informative-errors

Use strcmp() instead of starts_with()/!prefixcmp() to stop accepting

Signed-off-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
7 years agoget_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure
Junio C Hamano [Wed, 18 Dec 2013 22:59:12 +0000 (14:59 -0800)]
get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure

On broken systems where RLIMIT_NOFILE is visible by the compliers
but underlying getrlimit() system call does not behave, we used to
simply die() when we are trying to decide how many file descriptors
to allocate for keeping packfiles open.  Instead, allow the fallback
codepath to take over when we get such a failure from getrlimit().

The same issue exists with _SC_OPEN_MAX and sysconf(); restructure
the code in a similar way to prepare for a broken sysconf() as well.

Noticed-by: Joey Hess <>
Helped-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agoGit v1.8.5.2
Junio C Hamano [Tue, 17 Dec 2013 19:42:12 +0000 (11:42 -0800)]

Signed-off-by: Junio C Hamano <>
7 years agoMerge branch 'rs/doc-submitting-patches' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:38:23 +0000 (11:38 -0800)]
Merge branch 'rs/doc-submitting-patches' into maint

* rs/doc-submitting-patches:
  SubmittingPatches: document how to handle multiple patches

7 years agoMerge branch 'tr/doc-git-cherry' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:37:55 +0000 (11:37 -0800)]
Merge branch 'tr/doc-git-cherry' into maint

* tr/doc-git-cherry:
  Documentation: revamp git-cherry(1)

7 years agoMerge branch 'nd/glossary-content-pathspec-markup' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:36:54 +0000 (11:36 -0800)]
Merge branch 'nd/glossary-content-pathspec-markup' into maint

* nd/glossary-content-pathspec-markup:
  glossary-content.txt: fix documentation of "**" patterns

7 years agoMerge branch 'jj/doc-markup-gitcli' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:36:38 +0000 (11:36 -0800)]
Merge branch 'jj/doc-markup-gitcli' into maint

* jj/doc-markup-gitcli:
  Documentation/gitcli.txt: fix double quotes

7 years agoMerge branch 'jj/doc-markup-hints-in-coding-guidelines' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:36:10 +0000 (11:36 -0800)]
Merge branch 'jj/doc-markup-hints-in-coding-guidelines' into maint

* jj/doc-markup-hints-in-coding-guidelines:
  State correct usage of literal examples in man pages in the coding standards

7 years agoMerge branch 'jj/log-doc' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:35:41 +0000 (11:35 -0800)]
Merge branch 'jj/log-doc' into maint

* jj/log-doc:
  Documentation/git-log.txt: mark-up fix and minor rephasing
  Documentation/git-log: update "--log-size" description

7 years agoMerge branch 'jj/rev-list-options-doc' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:34:41 +0000 (11:34 -0800)]
Merge branch 'jj/rev-list-options-doc' into maint

* jj/rev-list-options-doc:
  Documentation/rev-list-options.txt: fix some grammatical issues and typos
  Documentation/rev-list-options.txt: fix mark-up

7 years agoMerge branch 'tb/doc-fetch-pack-url' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:34:24 +0000 (11:34 -0800)]
Merge branch 'tb/doc-fetch-pack-url' into maint

* tb/doc-fetch-pack-url:
  git-fetch-pack uses URLs like git-fetch

7 years agoMerge branch 'mi/typofixes' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:34:01 +0000 (11:34 -0800)]
Merge branch 'mi/typofixes' into maint

* mi/typofixes:
  contrib: typofixes
  Documentation/technical/http-protocol.txt: typofixes
  typofixes: fix misspelt comments

7 years agoMerge branch 'jh/loose-object-dirs-creation-race' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:32:50 +0000 (11:32 -0800)]
Merge branch 'jh/loose-object-dirs-creation-race' into maint

Two processes creating loose objects at the same time could have
failed unnecessarily when the name of their new objects started
with the same byte value, due to a race condition.

* jh/loose-object-dirs-creation-race:
  sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs

7 years agoMerge branch 'jk/two-way-merge-corner-case-fix' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:32:04 +0000 (11:32 -0800)]
Merge branch 'jk/two-way-merge-corner-case-fix' into maint

"git am --abort" sometimes complained about not being able to write
a tree with an 0{40} object in it.

* jk/two-way-merge-corner-case-fix:
  t1005: add test for "read-tree --reset -u A B"
  t1005: reindent
  unpack-trees: fix "read-tree -u --reset A B" with conflicted index

7 years agoMerge branch 'sb/sha1-loose-object-info-check-existence' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:31:18 +0000 (11:31 -0800)]
Merge branch 'sb/sha1-loose-object-info-check-existence' into maint

"git cat-file --batch-check=ok" did not check the existence of the
named object.

* sb/sha1-loose-object-info-check-existence:
  sha1_loose_object_info(): do not return success on missing object

7 years agoMerge branch 'nd/magic-pathspec' into maint
Junio C Hamano [Tue, 17 Dec 2013 19:21:34 +0000 (11:21 -0800)]
Merge branch 'nd/magic-pathspec' into maint

"git diff -- ':(icase)makefile'" was unnecessarily rejected at the
command line parser.

* nd/magic-pathspec:
  diff: restrict pathspec limitations to diff b/f case only

7 years agocmd_repack(): remove redundant local variable "nr_packs"
Michael Haggerty [Tue, 17 Dec 2013 13:43:58 +0000 (14:43 +0100)]
cmd_repack(): remove redundant local variable "nr_packs"

Its value is the same as the number of entries in the "names"
string_list, so just use "" in its place.

Signed-off-by: Michael Haggerty <>
Acked-by: Stefan Beller <>
Signed-off-by: Junio C Hamano <>
7 years agocat-file: handle --batch format with missing type/size
Jeff King [Wed, 11 Dec 2013 23:15:50 +0000 (07:15 +0800)]
cat-file: handle --batch format with missing type/size

Commit 98e2092 taught cat-file to stream blobs with --batch,
which requires that we look up the object type before
loading it into memory.  As a result, we now print the
object header from information in sha1_object_info, and the
actual contents from the read_sha1_file. We double-check
that the information we printed in the header matches the
content we are about to show.

Later, commit 93d2a60 allowed custom header lines for
--batch, and commit 5b08640 made type lookups optional. As a
result, specifying a header line without the type or size
means that we will not look up those items at all.

This causes our double-checking to erroneously die with an
error; we think the type or size has changed, when in fact
it was simply left at "0".

For the size, we can fix this by only doing the consistency
double-check when we have retrieved the size via
sha1_object_info. In the case that we have not retrieved the
value, that means we also did not print it, so there is
nothing for us to check that we are consistent with.

We could do the same for the type. However, besides our
consistency check, we also care about the type in deciding
whether to stream or not. So instead of handling the case
where we do not know the type, this patch instead makes sure
that we always trigger a type lookup when we are printing,
so that even a format without the type will stream as we
would in the normal case.

Reviewed-by: Jonathan Nieder <>
Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agocat-file: pass expand_data to print_object_or_die
Jeff King [Wed, 11 Dec 2013 23:01:42 +0000 (07:01 +0800)]
cat-file: pass expand_data to print_object_or_die

We currently individually pass the sha1, type, and size
fields calculated by sha1_object_info. However, if we pass
the whole struct, the called function can make more
intelligent decisions about which fields were actually
filled by sha1_object_info.

This patch takes that first refactoring step, passing the
whole struct, so further patches can make those decisions
with less noise in their diffs. There should be no
functional change to this patch (aside from a minor typo fix
in the error message).

As a side effect, we can rename the local variables in the
function to "type" and "size", since the names are no longer

Reviewed-by: Jonathan Nieder <>
Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
7 years agogit_connect(): use common return point
Torsten Bögershausen [Thu, 28 Nov 2013 19:50:15 +0000 (20:50 +0100)]
git_connect(): use common return point

Use only one return point from git_connect(), doing the

    return conn;

only at one place in the code.

There may be a little confusion what the variable "host" is for.  At
some places it is only the host part, at other places it may include
the port number, so change host into hostandport here.

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agoconnect.c: refactor url parsing
Torsten Bögershausen [Thu, 28 Nov 2013 19:50:03 +0000 (20:50 +0100)]
connect.c: refactor url parsing

Make the function is_local() in transport.c public, rename it into
url_is_local_not_ssh() and use it in both transport.c and connect.c

Use a protocol "local" for URLs for the local file system.

One note about using file:// under Windows:

The (absolute) path on Unix like system typically starts with "/".
When the host is empty, it can be omitted, so that a shell scriptlet
will give a URL like "file:///home/user/repo".

Windows does not have the same concept of a root directory located in "/".
When parsing the URL allow "file://C:/user/repo"
(even if RFC1738 indicates that "file:///C:/user/repo" should be used).

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agogit_connect(): refactor the port handling for ssh
Torsten Bögershausen [Thu, 28 Nov 2013 19:49:54 +0000 (20:49 +0100)]
git_connect(): refactor the port handling for ssh

Use get_host_and_port() even for ssh.
Remove the variable port git_connect(), and simplify parse_connect_url()
Use only one return point in git_connect(), doing the free() and return conn.

t5601 had 2 corner test cases which now pass.

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agogit fetch: support host:/~repo
Torsten Bögershausen [Thu, 28 Nov 2013 19:49:38 +0000 (20:49 +0100)]
git fetch: support host:/~repo

The documentation (in urls.txt) says that

    "host:/~repo" or

specify the repository "repo" in the home directory at "host".

This has not been working for "host:/~repo".

Before commit 356bec "Support [address] in URLs", the comparison
"url != hostname" could be used to determine if the URL had a scheme
or not: "ssh://host/host" != "host".

However, after 356bec "[::1]" was converted into "::1", yielding
url != hostname as well.  To fix this regression, don't use
"if (url != hostname)", but look at the separator instead.

Rename the variable "c" into "separator" to make it easier to read.

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agot5500: add test cases for diag-url
Torsten Bögershausen [Thu, 28 Nov 2013 19:49:29 +0000 (20:49 +0100)]
t5500: add test cases for diag-url

Add test cases using git fetch-pack --diag-url:

- parse out host and path for URLs with a scheme (git:// file:// ssh://)
- parse host names embedded by [] correctly
- extract the port number, if present
- separate URLs like "file" (which are local)
  from URLs like "host:repo" which should use ssh

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agogit fetch-pack: add --diag-url
Torsten Bögershausen [Thu, 28 Nov 2013 19:49:17 +0000 (20:49 +0100)]
git fetch-pack: add --diag-url

The main purpose is to trace the URL parser called by git_connect() in

The main features of the parser can be listed as this:

- parse out host and path for URLs with a scheme (git:// file:// ssh://)
- parse host names embedded by [] correctly
- extract the port number, if present
- separate URLs like "file" (which are local)
  from URLs like "host:repo" which should use ssh

Add the new parameter "--diag-url" to "git fetch-pack", which prints
the value for protocol, host and path to stderr and exits.

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agogit_connect: factor out discovery of the protocol and its parts
Johannes Sixt [Thu, 28 Nov 2013 19:49:01 +0000 (20:49 +0100)]
git_connect: factor out discovery of the protocol and its parts

git_connect has grown large due to the many different protocols syntaxes
that are supported. Move the part of the function that parses the URL to
connect to into a separate function for readability.

Signed-off-by: Johannes Sixt <>
Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agogit_connect: remove artificial limit of a remote command
Johannes Sixt [Thu, 28 Nov 2013 19:48:45 +0000 (20:48 +0100)]
git_connect: remove artificial limit of a remote command

Since day one, function git_connect() had a limit on the command line of
the command that is invoked to make a connection. 7a33bcbe converted the
code that constructs the command to strbuf. This would have been the
right time to remove the limit, but it did not happen. Remove it now.

git_connect() uses start_command() to invoke the command; consequently,
the limits of the system still apply, but are diagnosed only at execve()
time. But these limits are more lenient than the 1K that git_connect()

Signed-off-by: Johannes Sixt <>
Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agorev-parse: be more careful with munging arguments
Jeff King [Fri, 6 Dec 2013 22:07:52 +0000 (17:07 -0500)]
rev-parse: be more careful with munging arguments

When rev-parse looks at whether an argument like "" or
"foobar^@" is a difference or parent-shorthand, it internally
munges the arguments so that it can pass the individual rev
arguments to get_sha1(). However, we do not consistently un-munge
the result.

For cases where we do not match (e.g., "doesnotexist..HEAD"), we
would then want to try to treat the argument as a filename.
try_difference gets() this right, and always unmunges in this case.
However, try_parent_shorthand() never unmunges, leading to incorrect
error messages, or even incorrect results:

  $ git rev-parse foobar^@
  fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions, like this:
  'git <command> [<revision>...] -- [<file>...]'

  $ >foobar
  $ git rev-parse foobar^@

For cases where we do match, neither function unmunges. This does
not currently matter, since we are done with the argument. However,
a future patch will do further processing, and this prepares for
it. In addition, it's simply a confusing interface for some cases to
modify the const argument, and others not to.

Signed-off-by: Jeff King <>
Reviewed-by: Jonathan Nieder <>
Signed-off-by: Junio C Hamano <>
7 years agorev-parse: correctly diagnose revision errors before "--"
Jeff King [Fri, 6 Dec 2013 22:05:48 +0000 (17:05 -0500)]
rev-parse: correctly diagnose revision errors before "--"

Rev-parse understands that a "--" may separate revisions and
filenames, and that anything after the "--" is taken as-is.
However, it does not understand that anything before the
token must be a revision (which is the usual rule
implemented by the setup_revisions parser).

Since rev-parse prefers revisions to files when parsing
before the "--", we end up with the correct result (if such
an argument is a revision, we parse it as one, and if it is
not, it is an error either way).  However, we misdiagnose
the errors:

  $ git rev-parse foobar -- >/dev/null
  fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions, like this:
  'git <command> [<revision>...] -- [<file>...]'

  $ >foobar
  $ git rev-parse foobar -- >/dev/null
  fatal: bad flag '--' used after filename

In both cases, we should know that the real error is that
"foobar" is meant to be a revision, but could not be

Signed-off-by: Jeff King <>
Reviewed-by: Jonathan Nieder <>
Signed-off-by: Junio C Hamano <>
7 years agoclone,fetch: catch non positive --depth option value
Nguyễn Thái Ngọc Duy [Thu, 5 Dec 2013 03:31:11 +0000 (10:31 +0700)]
clone,fetch: catch non positive --depth option value

Instead of simply ignoring the value passed to --depth option when
it is zero or negative, catch and report it as an error to let
people know that they were using the option incorrectly.

Original-patch-by: Andrés G. Aragoneses <>
Signed-off-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
7 years agocommit -v: strip diffs and submodule shortlogs from the commit message
Jens Lehmann [Thu, 5 Dec 2013 19:44:14 +0000 (20:44 +0100)]
commit -v: strip diffs and submodule shortlogs from the commit message

When using the '-v' option of "git commit" the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for "\ndiff --git " and truncating the commmit message
there if it is found.

But this approach has two problems:

- when the commit message itself contains a line starting with
  "diff --git" it will be truncated there prematurely; and

- when the "diff.submodule" setting is set to "log", the diff may
  start with "Submodule <hash1>..<hash2>", which will be left in
  the commit message while it shouldn't.

Fix that by introducing a special scissor separator line starting with the
comment character ('#' or the core.commentChar config if set) followed by
two lines describing what it is for. The scissor line - which will not be
translated - is used to reliably detect the start of the diff so it can be
chopped off from the commit message, no matter what the user enters there.

Turn a known test failure fixed by this change into a successful test;
also add one for a diff starting with a submodule log and another one for
proper handling of the comment char.

Reported-by: Ari Pollak <>
Signed-off-by: Jens Lehmann <>
Signed-off-by: Junio C Hamano <>
7 years agot5601: add tests for ssh
Torsten Bögershausen [Thu, 28 Nov 2013 19:48:22 +0000 (20:48 +0100)]
t5601: add tests for ssh

Add more tests testing all the combinations:

 -IPv4 or IPv6
 -path starting with "/" or with "/~"
 -with and without the ssh:// scheme

Some tests fail; they need updates in connect.c

Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agot5601: remove clear_ssh, refactor setup_ssh_wrapper
Torsten Bögershausen [Thu, 28 Nov 2013 19:53:47 +0000 (20:53 +0100)]
t5601: remove clear_ssh, refactor setup_ssh_wrapper

Commit 8d3d28f5 added test cases for URLs which should be ssh.
Remove the function clear_ssh, use test_when_finished to clean up.

Introduce the function setup_ssh_wrapper, which could be factored
out together with expect_ssh.

Tighten one test and use "foo:bar" instead of "./foo:bar",

Helped-by: Jeff King <>
Signed-off-by: Torsten Bögershausen <>
Signed-off-by: Junio C Hamano <>
7 years agomv: let 'git mv file no-such-dir/' error out
Matthieu Moy [Tue, 3 Dec 2013 08:32:04 +0000 (09:32 +0100)]
mv: let 'git mv file no-such-dir/' error out

Git used to trim the trailing slash, and make the command equivalent
to 'git mv file no-such-dir', which created the file no-such-dir
(while the trailing slash explicitly stated that it could only be a

This patch skips the trailing slash removal for the destination
path.  The path with its trailing slash is passed to rename(2),
which errors out with the appropriate message:

  $ git mv file no-such-dir/
  fatal: renaming 'file' failed: Not a directory

Original-patch-by: Duy Nguyen <>
Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
7 years agosend-email: set SSL options through IO::Socket::SSL::set_client_defaults
Thomas Rast [Sun, 1 Dec 2013 22:48:43 +0000 (23:48 +0100)]
send-email: set SSL options through IO::Socket::SSL::set_client_defaults

When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection,
passing its ->new all the options that would otherwise go to
Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the
SSL options).

However, while Net::SMTP::SSL replaces the underlying socket class
with an SSL socket, it does nothing to allow passing options to that
socket.  So the SSL-relevant options are lost.

Fortunately there is an escape hatch: we can directly set the options
with IO::Socket::SSL::set_client_defaults.  They will then persist
within the IO::Socket::SSL module.

Signed-off-by: Thomas Rast <>
Signed-off-by: Junio C Hamano <>
7 years agosend-email: --smtp-ssl-cert-path takes an argument
Thomas Rast [Sun, 1 Dec 2013 22:48:42 +0000 (23:48 +0100)]
send-email: --smtp-ssl-cert-path takes an argument

35035bb (send-email: be explicit with SSL certificate verification,
2013-07-18) forgot to specify that --smtp-ssl-cert-path takes a string
argument.  This means that the option could not actually be used as
intended.  Presumably noone noticed because it's much easier to set it
through configs anyway.

Add the required "=s".

Signed-off-by: Thomas Rast <>
Signed-off-by: Junio C Hamano <>