git/git.git
5 years agoxdiff: reject files larger than ~1GB
Jeff King [Thu, 24 Sep 2015 23:12:45 +0000 (19:12 -0400)]
xdiff: reject files larger than ~1GB

The xdiff code is not prepared to handle extremely large
files. It uses "int" in many places, which can overflow if
we have a very large number of lines or even bytes in our
input files. This can cause us to produce incorrect diffs,
with no indication that the output is wrong. Or worse, we
may even underallocate a buffer whose size is the result of
an overflowing addition.

We're much better off to tell the user that we cannot diff
or merge such a large file. This patch covers both cases,
but in slightly different ways:

  1. For merging, we notice the large file and cleanly fall
     back to a binary merge (which is effectively "we cannot
     merge this").

  2. For diffing, we make the binary/text distinction much
     earlier, and in many different places. For this case,
     we'll use the xdi_diff as our choke point, and reject
     any diff there before it hits the xdiff code.

     This means in most cases we'll die() immediately after.
     That's not ideal, but in practice we shouldn't
     generally hit this code path unless the user is trying
     to do something tricky. We already consider files
     larger than core.bigfilethreshold to be binary, so this
     code would only kick in when that is circumvented
     (either by bumping that value, or by using a
     .gitattribute to mark a file as diffable).

     In other words, we can avoid being "nice" here, because
     there is already nice code that tries to do the right
     thing. We are adding the suspenders to the nice code's
     belt, so notice when it has been worked around (both to
     protect the user from malicious inputs, and because it
     is better to die() than generate bogus output).

The maximum size was chosen after experimenting with feeding
large files to the xdiff code. It's just under a gigabyte,
which leaves room for two obvious cases:

  - a diff3 merge conflict result on files of maximum size X
    could be 3*X plus the size of the markers, which would
    still be only about 3G, which fits in a 32-bit int.

  - some of the diff code allocates arrays of one int per
    record. Even if each file consists only of blank lines,
    then a file smaller than 1G will have fewer than 1G
    records, and therefore the int array will fit in 4G.

Since the limit is arbitrary anyway, I chose to go under a
gigabyte, to leave a safety margin (e.g., we would not want
to overflow by allocating "(records + 1) * sizeof(int)" or
similar.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoreact to errors in xdi_diff
Jeff King [Thu, 24 Sep 2015 23:12:23 +0000 (19:12 -0400)]
react to errors in xdi_diff

When we call into xdiff to perform a diff, we generally lose
the return code completely. Typically by ignoring the return
of our xdi_diff wrapper, but sometimes we even propagate
that return value up and then ignore it later.  This can
lead to us silently producing incorrect diffs (e.g., "git
log" might produce no output at all, not even a diff header,
for a content-level diff).

In practice this does not happen very often, because the
typical reason for xdiff to report failure is that it
malloc() failed (it uses straight malloc, and not our
xmalloc wrapper).  But it could also happen when xdiff
triggers one our callbacks, which returns an error (e.g.,
outf() in builtin/rerere.c tries to report a write failure
in this way). And the next patch also plans to add more
failure modes.

Let's notice an error return from xdiff and react
appropriately. In most of the diff.c code, we can simply
die(), which matches the surrounding code (e.g., that is
what we do if we fail to load a file for diffing in the
first place). This is not that elegant, but we are probably
better off dying to let the user know there was a problem,
rather than simply generating bogus output.

We could also just die() directly in xdi_diff, but the
callers typically have a bit more context, and can provide a
better message (and if we do later decide to pass errors up,
we're one step closer to doing so).

There is one interesting case, which is in diff_grep(). Here
if we cannot generate the diff, there is nothing to match,
and we silently return "no hits". This is actually what the
existing code does already, but we make it a little more
explicit.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoGit 2.3.9 v2.3.9
Junio C Hamano [Fri, 4 Sep 2015 17:31:34 +0000 (10:31 -0700)]
Git 2.3.9

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoSync with 2.2.3
Junio C Hamano [Fri, 4 Sep 2015 17:29:28 +0000 (10:29 -0700)]
Sync with 2.2.3

5 years agoGit 2.2.3 v2.2.3
Junio C Hamano [Fri, 4 Sep 2015 17:25:47 +0000 (10:25 -0700)]
Git 2.2.3

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'jk/long-paths' into maint-2.2
Junio C Hamano [Fri, 4 Sep 2015 17:25:23 +0000 (10:25 -0700)]
Merge branch 'jk/long-paths' into maint-2.2

5 years agoshow-branch: use a strbuf for reflog descriptions
Jeff King [Wed, 19 Aug 2015 18:12:48 +0000 (14:12 -0400)]
show-branch: use a strbuf for reflog descriptions

When we show "branch@{0}", we format into a fixed-size
buffer using sprintf. This can overflow if you have long
branch names. We can fix it by using a temporary strbuf.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoread_info_alternates: handle paths larger than PATH_MAX
Jeff King [Wed, 19 Aug 2015 18:12:45 +0000 (14:12 -0400)]
read_info_alternates: handle paths larger than PATH_MAX

This function assumes that the relative_base path passed
into it is no larger than PATH_MAX, and writes into a
fixed-size buffer. However, this path may not have actually
come from the filesystem; for example, add_submodule_odb
generates a path using a strbuf and passes it in. This is
hard to trigger in practice, though, because the long
submodule directory would have to exist on disk before we
would try to open its info/alternates file.

We can easily avoid the bug, though, by simply creating the
filename on the heap.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agonotes: use a strbuf in add_non_note
Jeff King [Wed, 19 Aug 2015 18:12:41 +0000 (14:12 -0400)]
notes: use a strbuf in add_non_note

When we are loading a notes tree into our internal hash
table, we also collect any files that are clearly non-notes.
We format the name of the file into a PATH_MAX buffer, but
unlike true notes (which cannot be larger than a fanned-out
sha1 hash), these tree entries can be arbitrarily long,
overflowing our buffer.

We can fix this by switching to a strbuf. It doesn't even
cost us an extra allocation, as we can simply hand ownership
of the buffer over to the non-note struct.

This is of moderate security interest, as you might fetch
notes trees from an untrusted remote. However, we do not do
so by default, so you would have to manually fetch into the
notes namespace.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoverify_absent: allow filenames longer than PATH_MAX
Jeff King [Wed, 19 Aug 2015 18:12:37 +0000 (14:12 -0400)]
verify_absent: allow filenames longer than PATH_MAX

When unpack-trees wants to know whether a path will
overwrite anything in the working tree, we use lstat() to
see if there is anything there. But if we are going to write
"foo/bar", we can't just lstat("foo/bar"); we need to look
for leading prefixes (e.g., "foo"). So we use the lstat cache
to find the length of the leading prefix, and copy the
filename up to that length into a temporary buffer (since
the original name is const, we cannot just stick a NUL in
it).

The copy we make goes into a PATH_MAX-sized buffer, which
will overflow if the prefix is longer than PATH_MAX. How
this happens is a little tricky, since in theory PATH_MAX is
the biggest path we will have read from the filesystem. But
this can happen if:

  - the compiled-in PATH_MAX does not accurately reflect
    what the filesystem is capable of

  - the leading prefix is not _quite_ what is on disk; it
    contains the next element from the name we are checking.
    So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb"
    exists, the prefix of interest is "aaa/bbb/ccc". If
    "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow
    it.

So this can be triggered, but it's hard to do. In
particular, you cannot just "git clone" a bogus repo. The
verify_absent checks happen before unpack-trees writes
anything to the filesystem, so there are never any leading
prefixes during the initial checkout, and the bug doesn't
trigger. And by definition, these files are larger than
PATH_MAX, so writing them will fail, and clone will
complain (though it may write a partial path, which will
cause a subsequent "git checkout" to hit the bug).

We can fix it by creating the temporary path on the heap.
The extra malloc overhead is not important, as we are
already making at least one stat() call (and probably more
for the prefix discovery).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 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>
5 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>

5 years agoMerge branch 'jc/diff-no-index-d-f' into maint-2.3
Junio C Hamano [Mon, 11 May 2015 21:34:00 +0000 (14:34 -0700)]
Merge branch 'jc/diff-no-index-d-f' into maint-2.3

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

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

5 years agoMerge branch 'oh/fix-config-default-user-name-section' into maint-2.3
Junio C Hamano [Mon, 11 May 2015 21:33:59 +0000 (14:33 -0700)]
Merge branch 'oh/fix-config-default-user-name-section' into maint-2.3

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

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

5 years agoMerge branch 'jc/epochtime-wo-tz' into maint-2.3
Junio C Hamano [Mon, 11 May 2015 21:33:58 +0000 (14:33 -0700)]
Merge branch 'jc/epochtime-wo-tz' into maint-2.3

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

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

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

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'tb/connect-ipv6-parse-fix' into maint
Junio C Hamano [Mon, 27 Apr 2015 19:23:53 +0000 (12:23 -0700)]
Merge branch 'tb/connect-ipv6-parse-fix' into maint

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

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

5 years agoMerge branch 'ma/bash-completion-leaking-x' into maint
Junio C Hamano [Mon, 27 Apr 2015 19:23:51 +0000 (12:23 -0700)]
Merge branch 'ma/bash-completion-leaking-x' into maint

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

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

5 years agoMerge branch 'jc/push-cert' into maint
Junio C Hamano [Mon, 27 Apr 2015 19:23:47 +0000 (12:23 -0700)]
Merge branch 'jc/push-cert' into maint

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

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

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

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'jk/colors' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:25 +0000 (12:12 -0700)]
Merge branch 'jk/colors' into maint

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

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

5 years agoMerge branch 'jk/test-annoyances' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:24 +0000 (12:12 -0700)]
Merge branch 'jk/test-annoyances' into maint

Test fixes.

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

5 years agoMerge branch 'pt/enter-repo-comment-fix' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:23 +0000 (12:12 -0700)]
Merge branch 'pt/enter-repo-comment-fix' into maint

Documentation update.

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

5 years agoMerge branch 'jz/gitweb-conf-doc-fix' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:22 +0000 (12:12 -0700)]
Merge branch 'jz/gitweb-conf-doc-fix' into maint

Documentation update.

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

5 years agoMerge branch 'jk/cherry-pick-docfix' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:21 +0000 (12:12 -0700)]
Merge branch 'jk/cherry-pick-docfix' into maint

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

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

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

5 years agoMerge branch 'jg/cguide-we-cannot-count' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:19 +0000 (12:12 -0700)]
Merge branch 'jg/cguide-we-cannot-count' into maint

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

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

Documentation update.

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

5 years agoMerge branch 'jn/doc-fast-import-no-16-octopus-limit' into maint
Junio C Hamano [Tue, 21 Apr 2015 19:12:17 +0000 (12:12 -0700)]
Merge branch 'jn/doc-fast-import-no-16-octopus-limit' into maint

Documentation update.

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

5 years agolog -L: improve error message on malformed argument
Matthieu Moy [Mon, 20 Apr 2015 12:09:07 +0000 (14:09 +0200)]
log -L: improve error message on malformed argument

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

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

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoDocumentation: change -L:<regex> to -L:<funcname>
Matthieu Moy [Mon, 20 Apr 2015 12:09:06 +0000 (14:09 +0200)]
Documentation: change -L:<regex> to -L:<funcname>

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

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoconfig: fix settings in default_user_config template
Ossi Herrala [Fri, 17 Apr 2015 14:50:10 +0000 (17:50 +0300)]
config: fix settings in default_user_config template

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

Signed-off-by: Ossi Herrala <oherrala@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoparse_date_basic(): let the system handle DST conversion
Junio C Hamano [Wed, 15 Apr 2015 15:47:48 +0000 (08:47 -0700)]
parse_date_basic(): let the system handle DST conversion

The function parses the input to compute the broken-down time in
"struct tm", and the GMT timezone offset.  If the timezone offset
does not exist in the input, the broken-down time is turned into the
number of seconds since epoch both in the current timezone and in
GMT and the offset is computed as their difference.

However, we forgot to make sure tm.tm_isdst is set to -1 (i.e. let
the system figure out if DST is in effect in the current timezone
when turning the broken-down time to the number of seconds since
epoch); it is done so at the beginning of the function, but a call
to match_digit() in the function can lead to a call to gmtime_r() to
clobber the field.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Diagnosed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoparse_date_basic(): return early when given a bogus timestamp
Junio C Hamano [Wed, 15 Apr 2015 15:43:58 +0000 (08:43 -0700)]
parse_date_basic(): return early when given a bogus timestamp

When the input does not have GMT timezone offset, the code computes
it by computing the local and GMT time for the given timestamp. But
there is no point doing so if the given timestamp is known to be a
bogus one.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoCodingGuidelines: update 'rough' rule count
Julian Gindi [Mon, 13 Apr 2015 12:54:14 +0000 (08:54 -0400)]
CodingGuidelines: update 'rough' rule count

Changed inaccurate count of "rough rules" from three to the more
generic 'a few'.

Signed-off-by: Julian Gindi <juliangindi@gmail.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agocompletion: fix global bash variable leak on __gitcompappend
Márcio Almada [Wed, 8 Apr 2015 05:45:58 +0000 (02:45 -0300)]
completion: fix global bash variable leak on __gitcompappend

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoconnect.c: ignore extra colon after hostname
Torsten Bögershausen [Tue, 7 Apr 2015 20:03:25 +0000 (22:03 +0200)]
connect.c: ignore extra colon after hostname

Ignore an extra ':' at the end of the hostname in URL's like
"ssh://example.com:/path/to/repo"

The colon is meant to separate a port number from the hostname.
If the port is empty, the colon should be ignored, see RFC 3986.

It had been working for URLs with ssh:// scheme, but was unintentionally
broken in 86ceb3, "allow ssh://user@[2001:db8::1]/repo.git"

Reported-by: Reid Woodbury Jr. <reidw@rawsound.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agodiff-highlight: do not split multibyte characters
Kyle J. McKay [Fri, 3 Apr 2015 22:15:14 +0000 (15:15 -0700)]
diff-highlight: do not split multibyte characters

When the input is UTF-8 and Perl is operating on bytes instead of
characters, a diff that changes one multibyte character to another
that shares an initial byte sequence will result in a broken diff
display as the common byte sequence prefix will be separated from
the rest of the bytes in the multibyte character.

For example, if a single line contains only the unicode character
U+C9C4 (encoded as UTF-8 0xEC, 0xA7, 0x84) and that line is then
changed to the unicode character U+C9C0 (encoded as UTF-8 0xEC,
0xA7, 0x80), when operating on bytes diff-highlight will show only
the single byte change from 0x84 to 0x80 thus creating invalid UTF-8
and a broken diff display.

Fix this by putting Perl into character mode when splitting the line
and then back into byte mode after the split is finished.

The utf8::xxx functions require Perl 5.8 so we require that as well.

Also, since we are mucking with code in the split_line function, we
change a '*' quantifier to a '+' quantifier when matching the $COLOR
expression which has the side effect of speeding everything up while
eliminating useless '' elements in the returned array.

Reported-by: Yi EungJun <semtlenori@gmail.com>
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agopush --signed: tighten what the receiving end can ask to sign
Junio C Hamano [Thu, 2 Apr 2015 01:00:36 +0000 (18:00 -0700)]
push --signed: tighten what the receiving end can ask to sign

Instead of blindly trusting the receiving side to give us a sensible
nonce to sign, limit the length (max 256 bytes) and the alphabet
(alnum and a few selected punctuations, enough to encode in base64)
that can be used in nonce.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agohowto: document more tools for recovery corruption
Jeff King [Wed, 1 Apr 2015 21:08:56 +0000 (17:08 -0400)]
howto: document more tools for recovery corruption

Long ago, I documented a corruption recovery I did and gave
some C code that I used to help find a flipped bit.  I had
to fix a similar case recently, and I ended up writing a few
more tools.  I hope nobody ever has to use these, but it
does not hurt to share them, just in case.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agofast-import doc: remove suggested 16-parent limit
Jonathan Nieder [Tue, 31 Mar 2015 23:18:07 +0000 (16:18 -0700)]
fast-import doc: remove suggested 16-parent limit

Merges with an absurd number of parents are still a bad idea because
they do not render well in tools like gitk, but if they are present
in the repository being imported into git then there's no need to
avoid reproducing them faithfully.

In olden times, before v1.6.0-rc0~194 (2008-06-27), git commit-tree
and higher-level tools built on top of it were limited to writing 16
parents for a commit.  Nowadays normal git operations are happy to
write more parents when asked, so the motivation for this note in the
fast-import documentation is gone and we can remove it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoGit 2.3.5 v2.3.5
Junio C Hamano [Tue, 31 Mar 2015 21:57:10 +0000 (14:57 -0700)]
Git 2.3.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'ss/pull-rebase-preserve' into maint
Junio C Hamano [Tue, 31 Mar 2015 21:54:11 +0000 (14:54 -0700)]
Merge branch 'ss/pull-rebase-preserve' into maint

* ss/pull-rebase-preserve:
  docs: clarify what git-rebase's "-p" / "--preserve-merges" does
  docs: clarify "preserve" option wording for git-pull

5 years agoMerge branch 'jc/report-path-error-to-dir' into maint
Junio C Hamano [Tue, 31 Mar 2015 21:53:08 +0000 (14:53 -0700)]
Merge branch 'jc/report-path-error-to-dir' into maint

Code clean-up.

* jc/report-path-error-to-dir:
  report_path_error(): move to dir.c

5 years agoMerge branch 'ph/push-doc-cas' into maint
Junio C Hamano [Tue, 31 Mar 2015 21:52:23 +0000 (14:52 -0700)]
Merge branch 'ph/push-doc-cas' into maint

* ph/push-doc-cas:
  git-push.txt: clean up force-with-lease wording

5 years agogitweb.conf.txt: say "build-time", not "built-time"
Jérôme Zago [Thu, 3 Apr 2014 20:49:47 +0000 (22:49 +0200)]
gitweb.conf.txt: say "build-time", not "built-time"

"build-time" is used everywhere else.

Signed-off-by: Jérôme Zago <git-patch@agt-the-walker.net>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoenter_repo(): fix docs to match code
Paul Tan [Tue, 31 Mar 2015 13:39:27 +0000 (21:39 +0800)]
enter_repo(): fix docs to match code

In b3256eb (standardize and improve lookup rules for external local
repos), enter_repo() was modified to use a different precedence
ordering of suffixes for DWIM of the repository path, and to ensure
that the repository path is actually valid instead of just testing
for existence.

However, the documentation was not modified to reflect these
changes.  Fix the documentation to match the code.

Documentation contributed by Jeff King.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agocherry-pick: fix docs describing handling of empty commits
Jeff King [Tue, 31 Mar 2015 01:08:54 +0000 (21:08 -0400)]
cherry-pick: fix docs describing handling of empty commits

Commit b27cfb0 (git-cherry-pick: Add keep-redundant-commits
option, 2012-04-20), added the --keep-redundant-commits
option, and switched the default behavior (without that
option) to silently ignore empty commits. Later, the second
half of that commit was reverted in ac2b0e8 (cherry-pick:
regression fix for empty commits, 2012-05-29), but the
documentation added for --keep-redundant-commits was never
updated to match. Let's do so now.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agodocs: clarify what git-rebase's "-p" / "--preserve-merges" does
Sebastian Schuberth [Mon, 30 Mar 2015 09:29:46 +0000 (11:29 +0200)]
docs: clarify what git-rebase's "-p" / "--preserve-merges" does

Ignoring a merge can be read as ignoring the changes a merge commit
introduces altogether, as if the entire side branch the merge commit
merged was removed from the history.  But that is not what happens
if "-p" is not specified.  What happens is that the individual
commits a merge commit introduces are replayed in order, and only
any possible merge conflict resolutions or manual amendments to the
merge commit are ignored.

Get this straight in the docs.

Also, do not say that merge commits are *tried* to be recreated. As that is
true almost everywhere it is better left unsaid.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoparse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval
Ivan Ukhov [Sun, 29 Mar 2015 08:32:55 +0000 (10:32 +0200)]
parse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval

When 20d1c652 (parse-options: remove unused OPT_SET_PTR, 2014-03-30)
removed OPT_SET_PTR, the comment in the header that describes what
the option did to defval field was left behind by mistake.  Remove
it.

Signed-off-by: Ivan Ukhov <ivan.ukhov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoPrepare for 2.3.5
Junio C Hamano [Sat, 28 Mar 2015 16:36:30 +0000 (09:36 -0700)]
Prepare for 2.3.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'sg/completion-gitcomp-nl-for-refs' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:15 +0000 (09:33 -0700)]
Merge branch 'sg/completion-gitcomp-nl-for-refs' into maint

Code clean-up.

* sg/completion-gitcomp-nl-for-refs:
  completion: use __gitcomp_nl() for completing refs

5 years agoMerge branch 'jk/simplify-csum-file-sha1fd-check' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:15 +0000 (09:33 -0700)]
Merge branch 'jk/simplify-csum-file-sha1fd-check' into maint

Code simplification.

* jk/simplify-csum-file-sha1fd-check:
  sha1fd_check: die when we cannot open the file

5 years agoMerge branch 'tg/test-index-v4' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:14 +0000 (09:33 -0700)]
Merge branch 'tg/test-index-v4' into maint

A test fix.

* tg/test-index-v4:
  t1700: make test pass with index-v4

5 years agoMerge branch 'nd/doc-git-index-version' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:13 +0000 (09:33 -0700)]
Merge branch 'nd/doc-git-index-version' into maint

Doc clean-up.

* nd/doc-git-index-version:
  git.txt: list index versions in plain English

5 years agoMerge branch 'ct/prompt-untracked-fix' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:12 +0000 (09:33 -0700)]
Merge branch 'ct/prompt-untracked-fix' into maint

The prompt script (in contrib/) did not show the untracked sign
when working in a subdirectory without any untracked files.

* ct/prompt-untracked-fix:
  git prompt: use toplevel to find untracked files

5 years agoMerge branch 'ws/grep-quiet-no-pager' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:11 +0000 (09:33 -0700)]
Merge branch 'ws/grep-quiet-no-pager' into maint

Even though "git grep --quiet" is run merely to ask for the exit
status, we spawned the pager regardless.  Stop doing that.

* ws/grep-quiet-no-pager:
  grep: fix "--quiet" overwriting current output

5 years agoMerge branch 'jc/submitting-patches-mention-send-email' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:10 +0000 (09:33 -0700)]
Merge branch 'jc/submitting-patches-mention-send-email' into maint

Recommend format-patch and send-email for those who want to submit
patches to this project.

* jc/submitting-patches-mention-send-email:
  SubmittingPatches: encourage users to use format-patch and send-email

5 years agoMerge branch 'jk/cleanup-failed-clone' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:09 +0000 (09:33 -0700)]
Merge branch 'jk/cleanup-failed-clone' into maint

An failure early in the "git clone" that started creating the
working tree and repository could have resulted in some directories
and files left without getting cleaned up.

* jk/cleanup-failed-clone:
  clone: drop period from end of die_errno message
  clone: initialize atexit cleanup handler earlier

5 years agoMerge branch 'jk/fetch-pack' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:08 +0000 (09:33 -0700)]
Merge branch 'jk/fetch-pack' into maint

"git fetch" that fetches a commit using the allow-tip-sha1-in-want
extension could have failed to fetch all the requested refs.

* jk/fetch-pack:
  fetch-pack: remove dead assignment to ref->new_sha1
  fetch_refs_via_pack: free extra copy of refs
  filter_ref: make a copy of extra "sought" entries
  filter_ref: avoid overwriting ref->old_sha1 with garbage

5 years agoMerge branch 'tg/fix-check-order-with-split-index' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:07 +0000 (09:33 -0700)]
Merge branch 'tg/fix-check-order-with-split-index' into maint

The split-index mode introduced at v2.3.0-rc0~41 was broken in the
codepath to protect us against a broken reimplementation of Git
that writes an invalid index with duplicated index entries, etc.

* tg/fix-check-order-with-split-index:
  read-cache: fix reading of split index

5 years agoMerge branch 'jk/prune-with-corrupt-refs' into maint
Junio C Hamano [Sat, 28 Mar 2015 16:33:06 +0000 (09:33 -0700)]
Merge branch 'jk/prune-with-corrupt-refs' into maint

"git prune" used to largely ignore broken refs when deciding which
objects are still being used, which could spread an existing small
damage and make it a larger one.

* jk/prune-with-corrupt-refs:
  refs.c: drop curate_packed_refs
  repack: turn on "ref paranoia" when doing a destructive repack
  prune: turn on ref_paranoia flag
  refs: introduce a "ref paranoia" flag
  t5312: test object deletion code paths in a corrupted repository

5 years ago2.3.2 release notes: typofix
Thomas Ackermann [Thu, 26 Mar 2015 20:29:47 +0000 (21:29 +0100)]
2.3.2 release notes: typofix

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'jk/tag-h-column-is-a-listing-option' into maint
Junio C Hamano [Fri, 27 Mar 2015 20:00:23 +0000 (13:00 -0700)]
Merge branch 'jk/tag-h-column-is-a-listing-option' into maint

"git tag -h" used to show the "--column" and "--sort" options
that are about listing in a wrong section.

* jk/tag-h-column-is-a-listing-option:
  tag: fix some mis-organized options in "-h" listing

5 years agoMerge branch 'jk/smart-http-hide-refs' into maint
Junio C Hamano [Fri, 27 Mar 2015 20:00:20 +0000 (13:00 -0700)]
Merge branch 'jk/smart-http-hide-refs' into maint

The transfer.hiderefs support did not quite work for smart-http
transport.

* jk/smart-http-hide-refs:
  upload-pack: do not check NULL return of lookup_unknown_object
  upload-pack: fix transfer.hiderefs over smart-http

5 years agoMerge branch 'js/completion-ctags-pattern-substitution-fix' into maint
Junio C Hamano [Fri, 27 Mar 2015 20:00:17 +0000 (13:00 -0700)]
Merge branch 'js/completion-ctags-pattern-substitution-fix' into maint

The code that reads from the ctags file in the completion script
(in contrib/) did not spell ${param/pattern/string} substitution
correctly, which happened to work with bash but not with zsh.

* js/completion-ctags-pattern-substitution-fix:
  contrib/completion: escape the forward slash in __git_match_ctag

5 years agoUpdate mailmap to spell out "Alexander Kuleshov"
Junio C Hamano [Fri, 27 Mar 2015 19:58:04 +0000 (12:58 -0700)]
Update mailmap to spell out "Alexander Kuleshov"

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agodiff-no-index: align D/F handling with that of normal Git
Junio C Hamano [Sun, 22 Mar 2015 05:11:27 +0000 (22:11 -0700)]
diff-no-index: align D/F handling with that of normal Git

When a commit changes a path P that used to be a file to a directory
and creates a new path P/X in it, "git show" would say that file P
was removed and file P/X was created for such a commit.

However, if we compare two directories, D1 and D2, where D1 has a
file D1/P in it and D2 has a directory D2/P under which there is a
file D2/P/X, and ask "git diff --no-index D1 D2" to show their
differences, we simply get a refusal "file/directory conflict".

Surely, that may be what GNU diff does, but we can do better and it
is easy to do so.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agodocs: clarify "preserve" option wording for git-pull
Sebastian Schuberth [Thu, 26 Mar 2015 20:11:21 +0000 (21:11 +0100)]
docs: clarify "preserve" option wording for git-pull

The "also" sounds as if "preserve" does a rebase as an additional
step that "true" would not do, but that is not the case.  Clarify
this by omitting "also", and rewording the sentence a bit.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agogit-push.txt: clean up force-with-lease wording
Phil Hord [Thu, 26 Mar 2015 15:15:09 +0000 (11:15 -0400)]
git-push.txt: clean up force-with-lease wording

The help text for the --force-with-lease option to git-push
does not parse cleanly.  Clean up the wording and syntax to
be more sensible.  Also remove redundant information in the
"--force-with-lease alone" description.

Signed-off-by: Phil Hord <hordp@cisco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agodiff-no-index: DWIM "diff D F" into "diff D/F F"
Junio C Hamano [Wed, 25 Mar 2015 23:11:39 +0000 (16:11 -0700)]
diff-no-index: DWIM "diff D F" into "diff D/F F"

"git diff --no-index" was supposed to be a poor-man's approach to
allow using Git diff goodies outside of a Git repository, without
having to patch mainstream diff implementations.

Unlike a POSIX diff that treats "diff D F" (or "diff F D") as a
request to compare D/F and F (or F and D/F) when D is a directory
and F is a file, however, we did not accept such a command line and
instead barfed with "file/directory conflict".

Imitate what POSIX diff does and append the basename of the file
after the name of the directory before comparing.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoreport_path_error(): move to dir.c
Junio C Hamano [Tue, 24 Mar 2015 21:12:10 +0000 (14:12 -0700)]
report_path_error(): move to dir.c

The expected call sequence is for the caller to use match_pathspec()
repeatedly on a set of pathspecs, accumulating the "hits" in a
separate array, and then call this function to diagnose a pathspec
that never matched anything, as that can indicate a typo from the
command line, e.g. "git commit Maekfile".

Many builtin commands use this function from builtin/ls-files.c,
which is not a very healthy arrangement.  ls-files might have been
the first command to feel the need for such a helper, but the need
is shared by everybody who uses the "match and then report" pattern.

Move it to dir.c where match_pathspec() is defined.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agogit.txt: list index versions in plain English
Nguyễn Thái Ngọc Duy [Tue, 24 Mar 2015 00:28:33 +0000 (07:28 +0700)]
git.txt: list index versions in plain English

At the first look, a user may think the default version is "23". Even
with UNIX background, there's no reference anywhere close that may
indicate this is glob or regex.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoGit 2.3.4 v2.3.4
Junio C Hamano [Mon, 23 Mar 2015 18:27:27 +0000 (11:27 -0700)]
Git 2.3.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoMerge branch 'rs/use-isxdigit' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:41 +0000 (11:23 -0700)]
Merge branch 'rs/use-isxdigit' into maint

Code cleanup.

* rs/use-isxdigit:
  use isxdigit() for checking if a character is a hexadecimal digit

5 years agoMerge branch 'rs/deflate-init-cleanup' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:37 +0000 (11:23 -0700)]
Merge branch 'rs/deflate-init-cleanup' into maint

Code simplification.

* rs/deflate-init-cleanup:
  zlib: initialize git_zstream in git_deflate_init{,_gzip,_raw}

5 years agoMerge branch 'ak/git-done-help-cleanup' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:35 +0000 (11:23 -0700)]
Merge branch 'ak/git-done-help-cleanup' into maint

Code simplification.

* ak/git-done-help-cleanup:
  git: make was_alias and done_help non-static

5 years agoMerge branch 'sg/completion-remote' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:33 +0000 (11:23 -0700)]
Merge branch 'sg/completion-remote' into maint

Code simplification.

* sg/completion-remote:
  completion: simplify __git_remotes()
  completion: add a test for __git_remotes() helper function

5 years agoMerge branch 'mg/doc-status-color-slot' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:30 +0000 (11:23 -0700)]
Merge branch 'mg/doc-status-color-slot' into maint

Documentation fixes.

* mg/doc-status-color-slot:
  config,completion: add color.status.unmerged

5 years agoMerge branch 'jc/decorate-leaky-separator-color' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:28 +0000 (11:23 -0700)]
Merge branch 'jc/decorate-leaky-separator-color' into maint

"git log --decorate" did not reset colors correctly around the
branch names.

* jc/decorate-leaky-separator-color:
  log --decorate: do not leak "commit" color into the next item
  Documentation/config.txt: simplify boolean description in the syntax section
  Documentation/config.txt: describe 'color' value type in the "Values" section
  Documentation/config.txt: have a separate "Values" section
  Documentation/config.txt: describe the structure first and then meaning
  Documentation/config.txt: explain multi-valued variables once
  Documentation/config.txt: avoid unnecessary negation

5 years agoMerge branch 'kn/git-cd-to-empty' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:25 +0000 (11:23 -0700)]
Merge branch 'kn/git-cd-to-empty' into maint

"git -C '' subcmd" refused to work in the current directory, unlike
"cd ''" which silently behaves as a no-op.

* kn/git-cd-to-empty:
  git: treat "git -C '<path>'" as a no-op when <path> is empty

5 years agoMerge branch 'km/imap-send-libcurl-options' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:22 +0000 (11:23 -0700)]
Merge branch 'km/imap-send-libcurl-options' into maint

"git imap-send" learned to optionally talk with an IMAP server via
libcURL; because there is no other option when Git is built with
NO_OPENSSL option, use that codepath by default under such
configuration.

* km/imap-send-libcurl-options:
  imap-send: use cURL automatically when NO_OPENSSL defined

5 years agoMerge branch 'mg/verify-commit' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:19 +0000 (11:23 -0700)]
Merge branch 'mg/verify-commit' into maint

Workarounds for certain build of GPG that triggered false breakage
in a test.

* mg/verify-commit:
  t7510: do not fail when gpg warns about insecure memory

5 years agoMerge branch 'es/rebase-i-count-todo' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:17 +0000 (11:23 -0700)]
Merge branch 'es/rebase-i-count-todo' into maint

"git rebase -i" recently started to include the number of
commits in the insn sheet to be processed, but on a platform
that prepends leading whitespaces to "wc -l" output, the numbers
are shown with extra whitespaces that aren't necessary.

* es/rebase-i-count-todo:
  rebase-interactive: re-word "item count" comment
  rebase-interactive: suppress whitespace preceding item count

5 years agoMerge branch 'tb/connect-ipv6-parse-fix' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:12 +0000 (11:23 -0700)]
Merge branch 'tb/connect-ipv6-parse-fix' into maint

We did not parse username followed by literal IPv6 address in SSH
transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git
correctly.

* tb/connect-ipv6-parse-fix:
  t5500: show user name and host in diag-url
  t5601: add more test cases for IPV6
  connect.c: allow ssh://user@[2001:db8::1]/repo.git

5 years agocompletion: use __gitcomp_nl() for completing refs
SZEDER Gábor [Sun, 22 Mar 2015 12:03:11 +0000 (13:03 +0100)]
completion: use __gitcomp_nl() for completing refs

We do that almost everywhere, because it's faster for large number of
refs, see a31e62629 (completion: optimize refs completion, 2011-10-15).
These were the last two places where we still used __gitcomp() for
completing refs.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoread-cache: fix reading of split index
Thomas Gummerer [Fri, 20 Mar 2015 21:43:14 +0000 (22:43 +0100)]
read-cache: fix reading of split index

The split index extension uses ewah bitmaps to mark index entries as
deleted, instead of removing them from the index directly.  This can
result in an on-disk index, in which entries of stage #0 and higher
stages appear, which are removed later when the index bases are merged.

15999d0 read_index_from(): catch out of order entries when reading an
index file introduces a check which checks if the entries are in order
after each index entry is read in do_read_index.  This check may however
fail when a split index is read.

Fix this by moving checking the index after we know there is no split
index or after the split index bases are successfully merged instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agorefs.c: drop curate_packed_refs
Jeff King [Fri, 20 Mar 2015 18:43:17 +0000 (14:43 -0400)]
refs.c: drop curate_packed_refs

When we delete a ref, we have to rewrite the entire
packed-refs file. We take this opportunity to "curate" the
packed-refs file and drop any entries that are crufty or
broken.

Dropping broken entries (e.g., with bogus names, or ones
that point to missing objects) is actively a bad idea, as it
means that we lose any notion that the data was there in the
first place. Aside from the general hackiness that we might
lose any information about ref "foo" while deleting an
unrelated ref "bar", this may seriously hamper any attempts
by the user at recovering from the corruption in "foo".

They will lose the sha1 and name of "foo"; the exact pointer
may still be useful even if they recover missing objects
from a different copy of the repository. But worse, once the
ref is gone, there is no trace of the corruption. A
follow-up "git prune" may delete objects, even though it
would otherwise bail when seeing corruption.

We could just drop the "broken" bits from
curate_packed_refs, and continue to drop the "crufty" bits:
refs whose loose counterpart exists in the filesystem. This
is not wrong to do, and it does have the advantage that we
may write out a slightly smaller packed-refs file. But it
has two disadvantages:

  1. It is a potential source of races or mistakes with
     respect to these refs that are otherwise unrelated to
     the operation. To my knowledge, there aren't any active
     problems in this area, but it seems like an unnecessary
     risk.

  2. We have to spend time looking up the matching loose
     refs for every item in the packed-refs file. If you
     have a large number of packed refs that do not change,
     that outweighs the benefit from writing out a smaller
     packed-refs file (it doesn't get smaller, and you do a
     bunch of directory traversal to find that out).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agorepack: turn on "ref paranoia" when doing a destructive repack
Jeff King [Fri, 20 Mar 2015 18:43:13 +0000 (14:43 -0400)]
repack: turn on "ref paranoia" when doing a destructive repack

If we are repacking with "-ad", we will drop any unreachable
objects. Likewise, using "-Ad --unpack-unreachable=<time>"
will drop any old, unreachable objects. In these cases, we
want to make sure the reachability we compute with "--all"
is complete. We can do this by passing GIT_REF_PARANOIA=1 in
the environment to pack-objects.

Note that "-Ad" is safe already, because it only loosens
unreachable objects. It is up to "git prune" to avoid
deleting them.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoprune: turn on ref_paranoia flag
Jeff King [Fri, 20 Mar 2015 18:43:09 +0000 (14:43 -0400)]
prune: turn on ref_paranoia flag

Prune should know about broken objects at the tips of refs,
so that we can feed them to our traversal rather than
ignoring them. It's better for us to abort the operation on
the broken object than it is to start deleting objects with
an incomplete view of the reachability namespace.

Note that for missing objects, aborting is the best we can
do. For a badly-named ref, we technically could use its sha1
as a reachability tip. However, the iteration code just
feeds us a null sha1, so there would be a reasonable amount
of code involved to pass down our wishes. It's not really
worth trying to do better, because this is a case that
should happen extremely rarely, and the message we provide:

  fatal: unable to parse object: refs/heads/bogus:name

is probably enough to point the user in the right direction.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agorefs: introduce a "ref paranoia" flag
Jeff King [Fri, 20 Mar 2015 18:43:06 +0000 (14:43 -0400)]
refs: introduce a "ref paranoia" flag

Most operations that iterate over refs are happy to ignore
broken cruft. However, some operations should be performed
with knowledge of these broken refs, because it is better
for the operation to choke on a missing object than it is to
silently pretend that the ref did not exist (e.g., if we are
computing the set of reachable tips in order to prune
objects).

These processes could just call for_each_rawref, except that
ref iteration is often hidden behind other interfaces. For
instance, for a destructive "repack -ad", we would have to
inform "pack-objects" that we are destructive, and then it
would in turn have to tell the revision code that our
"--all" should include broken refs.

It's much simpler to just set a global for "dangerous"
operations that includes broken refs in all iterations.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agot5312: test object deletion code paths in a corrupted repository
Jeff King [Fri, 20 Mar 2015 18:43:02 +0000 (14:43 -0400)]
t5312: test object deletion code paths in a corrupted repository

When we are doing a destructive operation like "git prune",
we want to be extra careful that the set of reachable tips
we compute is valid. If there is any corruption or oddity,
we are better off aborting the operation and letting the
user figure things out rather than plowing ahead and
possibly deleting some data that cannot be recovered.

The tests here include:

  1. Pruning objects mentioned only be refs with invalid
     names. This used to abort prior to d0f810f (refs.c:
     allow listing and deleting badly named refs,
     2014-09-03), but since then we silently ignore the tip.

     Likewise, we test repacking that can drop objects
     (either "-ad", which drops anything unreachable,
     or "-Ad --unpack-unreachable=<time>", which tries to
     optimize out a loose object write that would be
     directly pruned).

  2. Pruning objects when some refs point to missing
     objects. We don't know whether any dangling objects
     would have been reachable from the missing objects. We
     are better to keep them around, as they are better than
     nothing for helping the user recover history.

  3. Packed refs that point to missing objects can sometimes
     be dropped. By itself, this is more of an annoyance
     (you do not have the object anyway; even if you can
     recover it from elsewhere, all you are losing is a
     placeholder for your state at the time of corruption).
     But coupled with (2), if we drop the ref and then go
     on to prune, we may lose unrecoverable objects.

Note that we use test_might_fail for some of the operations.
In some cases, it would be appropriate to abort the
operation, and in others, it might be acceptable to continue
but taking the information into account. The tests don't
care either way, and check only for data loss.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agot1700: make test pass with index-v4
Thomas Gummerer [Fri, 20 Mar 2015 18:20:30 +0000 (19:20 +0100)]
t1700: make test pass with index-v4

The different index versions have different sha-1 checksums.  Those
checksums are checked in t1700, which makes it fail when the test suite
is run with TEST_GIT_INDEX_VERSION=4.  Fix it.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agofetch-pack: remove dead assignment to ref->new_sha1
Jeff King [Thu, 19 Mar 2015 20:39:36 +0000 (16:39 -0400)]
fetch-pack: remove dead assignment to ref->new_sha1

In everything_local(), we used to assign the current ref's value
found in ref->old_sha1 to ref->new_sha1 when we already have all the
necessary objects to complete the history leading to that
commit.  This copying was broken at 49bb805e (Do not ask for
objects known to be complete., 2005-10-19) and ever since we
instead stuffed a random bytes in ref->new_sha1 here.  No
code complained or failed due to this breakage.

It turns out that no code path that comes after this
assignment even looks at ref->new_sha1 at all.

 - The only caller of everything_local(), do_fetch_pack(),
   returns this list of refs, whose element has bogus
   new_sha1 values, to its caller.  It does not look at the
   elements itself, but does pass them to find_common, which
   looks only at the name and old_sha1 fields.

 - The only caller of do_fetch_pack(), fetch_pack(), returns this
   list to its caller.  It does not look at the elements nor act on
   them.

 - One of the two callers of fetch_pack() is cmd_fetch_pack(), the
   top-level that implements "git fetch-pack".  The only thing it
   looks at in the elements of the returned ref list is the old_sha1
   and name fields.

 - The other caller of fetch_pack() is fetch_refs_via_pack() in the
   transport layer, which is a helper that implements "git fetch".
   It only cares about whether the returned list is empty (i.e.
   failed to fetch anything).

Just drop the bogus assignment, that is not even necessary.  The
remote-tracking refs are updated based on a different list and not
using the ref list being manipulated by this code path; the caller
do_fetch_pack() created a copy of that real ref list and passed the
copy down to this function, and modifying the elements here does not
affect anything.

Noticed-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agofetch_refs_via_pack: free extra copy of refs
Jeff King [Thu, 19 Mar 2015 20:38:35 +0000 (16:38 -0400)]
fetch_refs_via_pack: free extra copy of refs

When fetch_refs_via_pack calls fetch_pack(), we pass a
list of refs to fetch, and the function returns either a
copy of that list, with the fetched items filled in, or
NULL. We check the return value to see whether the fetch was
successful, but do not otherwise look at the copy, and
simply leak it at the end of the function.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agofilter_ref: make a copy of extra "sought" entries
Jeff King [Thu, 19 Mar 2015 20:37:09 +0000 (16:37 -0400)]
filter_ref: make a copy of extra "sought" entries

If the server supports allow_tip_sha1_in_want, we add any
unmatched raw-sha1 entries in our "sought" list of refs to
the list of refs we will ask the other side for. We do so by
inserting the original "struct ref" directly into our list,
rather than making a copy. This has several problems.

The most minor problem is that one cannot ever free the
resulting list; it contains structs that are copies of the
remote refs (made earlier by fetch_pack) along with sought
refs that are referenced elsewhere.

But more importantly that we set the ref->next pointer to
NULL, chopping off the remainder of any existing list that
the ref was a part of. We get the set of "sought" refs in
an array rather than a linked list, but that array is often
in turn generated from a list.  The test modification in
t5516 demonstrates this. Rather than fetching just an exact
sha1, we fetch that sha1 plus another ref:

  - we build a linked list of refs to fetch when do_fetch
    calls get_ref_map; the exact sha1 is first, followed by
    the named ref ("refs/heads/extra" in this case).

  - we pass that linked list to transport_fetch_ref, which
    squashes it into an array of pointers

  - that array goes to fetch_pack, which calls filter_ref.
    There we generate the want list from a mix of what the
    remote side has advertised, and the "sought" entry for
    the exact sha1. We set the sought entry's "next" pointer
    to NULL.

  - after we return from transport_fetch_refs, we then try
    to update the refs by following the linked list. But our
    list is now truncated, and we do not update
    refs/heads/extra at all.

We can fix this by making a copy of the ref. There's nothing
that fetch_pack does to it that must be reflected in the
original "sought" list (and indeed, if that were the case we
would have a serious bug, because it is only exact-sha1
entries which are treated this way).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agofilter_ref: avoid overwriting ref->old_sha1 with garbage
Jeff King [Thu, 19 Mar 2015 20:34:51 +0000 (16:34 -0400)]
filter_ref: avoid overwriting ref->old_sha1 with garbage

If the server supports allow_tip_sha1_in_want, then
fetch-pack's filter_refs function tries to check whether a
ref is a request for a straight sha1 by running:

  if (get_sha1_hex(ref->name, ref->old_sha1))
  ...

I.e., we are using get_sha1_hex to ask "is this ref name a
sha1?". If it is true, then the contents of ref->old_sha1
will end up unchanged. But if it is false, then get_sha1_hex
makes no guarantees about what it has written. With a ref
name like "abcdefoo", we would overwrite 3 bytes of
ref->old_sha1 before realizing that it was not a sha1.

This is likely not a problem in practice, as anything in
refs->name (besides a sha1) will start with "refs/", meaning
that we would notice on the first character that there is a
problem. Still, we are making assumptions about the state
left in the output when get_sha1_hex returns an error (e.g.,
it could start from the end of the string, or error check
the values only once they were placed in the output). It's
better to be defensive.

We could just check that we have exactly 40 characters of
sha1. But let's be even more careful and make sure that we
have a 40-char hex refname that matches what is in old_sha1.
This is perhaps overly defensive, but spells out our
assumptions clearly.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoclone: drop period from end of die_errno message
Jeff King [Wed, 18 Mar 2015 19:02:01 +0000 (15:02 -0400)]
clone: drop period from end of die_errno message

We do not usually end our errors with a full stop, but it
looks especially bad when you use die_errno, which adds a
colon, like:

  fatal: could not create work tree dir 'foo'.: No such file or directory

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoclone: initialize atexit cleanup handler earlier
Jeff King [Wed, 18 Mar 2015 18:55:32 +0000 (14:55 -0400)]
clone: initialize atexit cleanup handler earlier

If clone fails, we generally try to clean up any directories
we've created. We do this by installing an atexit handler,
so that we don't have to manually trigger cleanup. However,
since we install this after touching the filesystem, any
errors between our initial mkdir() and our atexit() call
will result in us leaving a crufty directory around.

We can fix this by moving our atexit() call earlier. It's OK
to do it before the junk_work_tree variable is set, because
remove_junk makes sure the variable is initialized. This
means we "activate" the handler by assigning to the
junk_work_tree variable, which we now bump down to just
after we call mkdir(). We probably do not want to do it
before, because a plausible reason for mkdir() to fail is
EEXIST (i.e., we are racing with another "git init"), and we
would not want to remove their work.

OTOH, this is probably not that big a deal; we will allow
cloning into an empty directory (and skip the mkdir), which
is already racy (i.e., one clone may see the other's empty
dir and start writing into it). Still, it does not hurt to
err on the side of caution here.

Note that writing into junk_work_tree and junk_git_dir after
installing the handler is also technically racy, as we call
our handler on an async signal.  Depending on the platform,
we could see a sheared write to the variables. Traditionally
we have not worried about this, and indeed we already do
this later in the function. If we want to address that, it
can come as a separate topic.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agosha1fd_check: die when we cannot open the file
Jeff King [Wed, 18 Mar 2015 06:30:12 +0000 (02:30 -0400)]
sha1fd_check: die when we cannot open the file

Right now we return a NULL "struct sha1file" if we encounter
an error. However, the sole caller (write_idx_file) does not
check the return value, and will segfault if we hit this
case.

One option would be to handle the error in the caller.
However, there's really nothing for it to do but die. This
code path is hit during "git index-pack --verify"; after we
verify the packfile, we check that the ".idx" we would
generate from it is byte-wise identical to what is on disk.
We hit the error (and segfault) if we can't open the .idx
file (a likely cause of this is that somebody else ran "git
repack -ad" while we were verifying). Since we can't
complete the requested verification, we really have no
choice but to die.

Furthermore, the rest of the sha1fd_* functions simply die
on errors. So if were to open the file successfully, for
example, and then hit a read error, sha1write would call
die() for us. So pushing the die() down into sha1fd_check
keeps the interface consistent.

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