refs: ref entry with NULL sha1 is can be a dangling symref

Brandon Casey noticed that t5505 had accidentally broken its && chain,
hiding inconsistency between the code that writes the warning to the
standard output and the test that expects to see the warning on the
standard error, which was introduced by f8948e2 (remote prune: warn
dangling symrefs, 2009-02-08).

It turns out that the issue is deeper than that.  After f8948e2, a symref
that is dangling is marked with a NULL sha1, and the idea of using NULL
sha1 to mean a deleted ref was scrapped, but somehow a follow-up eafb452
(do_one_ref(): null_sha1 check is not about broken ref, 2009-07-22)
incorrectly reorganized do_one_ref(), still thinking NULL sha1 is never
used in the code.

Fix this by:

 - adopt Brandon's fix to t5505 test;

 - introduce REF_BROKEN flag to mark a ref that fails to resolve (dangling
   symref);

 - move the check for broken ref back inside the "if we are skipping
   dangling refs" code block.

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

Merge branch 'maint-1.6.2' into maint-1.6.3

* maint-1.6.2:
  base85: Make the code more obvious instead of explaining the non-obvious
  base85: encode_85() does not use the decode table
  base85 debug code: Fix length byte calculation
  checkout -m: do not try to fall back to --merge from an unborn branch
  branch: die explicitly why when calling "git branch [-a|-r] branchname".
  textconv: stop leaking file descriptors
  commit: --cleanup is a message option
  git count-objects: handle packs bigger than 4G
  t7102: make the test fail if one of its check fails

Conflicts:
diff.c

Merge branch 'maint-1.6.1' into maint-1.6.2

* maint-1.6.1:
  base85: Make the code more obvious instead of explaining the non-obvious
  base85: encode_85() does not use the decode table
  base85 debug code: Fix length byte calculation
  checkout -m: do not try to fall back to --merge from an unborn branch
  branch: die explicitly why when calling "git branch [-a|-r] branchname".
  textconv: stop leaking file descriptors
  commit: --cleanup is a message option
  git count-objects: handle packs bigger than 4G
  t7102: make the test fail if one of its check fails

Conflicts:
diff.c

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  base85: Make the code more obvious instead of explaining the non-obvious
  base85: encode_85() does not use the decode table
  base85 debug code: Fix length byte calculation
  checkout -m: do not try to fall back to --merge from an unborn branch
  branch: die explicitly why when calling "git branch [-a|-r] branchname".

base85: Make the code more obvious instead of explaining the non-obvious

Here is another cleanup ...

Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

base85: encode_85() does not use the decode table

Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

base85 debug code: Fix length byte calculation

Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout -m: do not try to fall back to --merge from an unborn branch

If switching from an unborn branch (= empty tree) to a valid commit failed
without -m, it would fail with -m option as well.

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

branch: die explicitly why when calling "git branch [-a|-r] branchname".

The -a and -r options used to be silently ignored in such a command.

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

textconv: stop leaking file descriptors

We read the output from textconv helpers over a pipe, but we
never actually closed our end of the pipe after using it.

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

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  commit: --cleanup is a message option
  t7102: make the test fail if one of its check fails

commit: --cleanup is a message option

In the usage message for "git commit", the --cleanup option appeared
at the end, as one of the "contents options":

usage: git commit [options] [--] <filepattern>...
...
Commit message options
...
Commit contents options
...
    --allow-empty         ok to record an empty change
    --cleanup <default>   how to strip spaces and #comments from message

This is confusing, in part because it makes it ambiguous whether
--allow-empty, just above, refers to an empty diff or an empty message.

Move --cleanup into the 'message options' group.  Also add a pair of
comments to prevent similar oversights in the future.

Signed-off-by: Greg Price <price@ksplice.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git count-objects: handle packs bigger than 4G

Use off_t to count sizes of packs and objects to avoid overflow after
4Gb.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7102: make the test fail if one of its check fails

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

Merge branch 'maint-1.6.2' into maint-1.6.3

* maint-1.6.2:
  git-clone: add missing comma in --reference documentation
  clone: disconnect transport after fetching

git-clone: add missing comma in --reference documentation

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-cvsserver: no longer use deprecated 'git-subcommand' commands

git-cvsserver still references git commands like 'git-config', which
is depcrecated.  This commit changes git-cvsserver to use the
'git subcommand' form.

Sylvain Beucler reported the problem through
 http://bugs.debian.org/536067

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clone: disconnect transport after fetching

The current code just leaves the transport in whatever state
it was in after performing the fetch.  For a non-empty clone
over the git protocol, the transport code already
disconnects at the end of the fetch.

But for an empty clone, we leave the connection hanging, and
eventually close the socket when clone exits. This causes
the remote upload-pack to complain "the remote end hung up
unexpectedly". While this message is harmless to the clone
itself, it is unnecessarily scary for a user to see and may
pollute git-daemon logs.

This patch just explicitly calls disconnect after we are
done with the remote end, which sends a flush packet to
upload-pack and cleanly disconnects, avoiding the error
message.

Other transports are unaffected or slightly improved:

 - for a non-empty repo over the git protocol, the second
   disconnect is a no-op (since we are no longer connected)

 - for "walker" transports (like HTTP or FTP), we actually
   free some used memory (which previously just sat until
   the clone process exits)

 - for "rsync", disconnect is always a no-op anyway

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.2' into maint-1.6.3

* maint-1.6.2:
  Fix overridable written with an extra 'e'
  Documentation: git-archive: mark --format as optional in summary
  Round-down years in "years+months" relative date view

Conflicts:
Documentation/git-archive.txt

Fix overridable written with an extra 'e'

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.1' into maint-1.6.2

* maint-1.6.1:
  Documentation: git-archive: mark --format as optional in summary

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  Documentation: git-archive: mark --format as optional in summary

Documentation: git-archive: mark --format as optional in summary

The --format option was made optional in 8ff21b1 (git-archive: make
tar the default format, 2007-04-09), but it was not marked as optional
in the summary. This trival patch just changes the summary to match
the rest of the documentation.

Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.5.6' into maint-1.6.0

* maint-1.5.6:
  revision traversal and pack: notice and die on missing commit

Round-down years in "years+months" relative date view

Previously, a commit from 1 year and 7 months ago would display as
"2 years, 7 months ago".

Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'tr/maint-1.6.3-add-p-modeonly-fix' into maint-1.6.3

* tr/maint-1.6.3-add-p-modeonly-fix:
  add -p: do not attempt to coalesce mode changes
  git add -p: demonstrate failure when staging both mode and hunk

add -p: do not attempt to coalesce mode changes

In 0392513 (add-interactive: refactor mode hunk handling, 2009-04-16),
we merged the interaction loops for mode changes and hunk staging.
This was fine at the time, because 0beee4c (git-add--interactive:
remove hunk coalescing, 2008-07-02) removed hunk coalescing.

However, in 7a26e65 (Revert "git-add--interactive: remove hunk
coalescing", 2009-05-16), we resurrected it.  Since then, the code
would attempt in vain to merge mode changes with diff hunks,
corrupting both in the process.

We add a check to the coalescing loop to ensure it only looks at diff
hunks, thus skipping mode changes.

Noticed-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git add -p: demonstrate failure when staging both mode and hunk

When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:

    $ echo content >> file
    $ chmod +x file
    $ git add -p
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    old mode 100644
    new mode 100755
    Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
    @@ -0,0 +1 @@
    +content
    Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
    Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    fatal: corrupt patch at line 5
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    @@ -,0 + @@
    +content

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Change mentions of "git programs" to "git commands"

Most of the docs and printouts refer to "commands" when discussing what
the end users call via the "git" top-level program. We should refer them
as "git programs" when we discuss the fact that the commands are
implemented as separate programs, but in other contexts, it is better to
use the term "git commands" consistently.

Signed-off-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: merge: one <remote> is required

merge only requires one <remote>, so "<remote>..." should be used in the
synopsis (and not "<remote> <remote>...").

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

help.c: give correct structure's size to memset()

These two structures are of the same type, but we'd better be consistent.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix typos in git-remote.txt and git-symbolic-ref.txt

Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.2' into maint-1.6.3

* maint-1.6.2:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used

Merge branch 'maint-1.6.1' into maint-1.6.2

* maint-1.6.1:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used

verify-pack -v: do not report "chain length 0"

When making a histogram of delta chain length in the pack, the program
collects number of objects whose delta depth exceeds the MAX_CHAIN limit
in histogram[0], and showed it as the number of items that exceeds the
limit correctly.  HOWEVER, it also showed the same number labeled as
"chain length = 0".

In fact, we are not showing the number of objects whose chain length is
zero, i.e. the base objects.  Correct this.

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

t5510: harden the way verify-pack is used

The test ignored the exit status from verify pack command, and also relied
on not seeing any delta chain statistics.

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

Better usage string for reflog.

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

hg-to-git: don't import the unused popen2 module

Importing the popen2 module in Python-2.6 results in the
"DeprecationWarning: The popen2 module is deprecated.  Use the
subprocess module." message. The module itself isn't used in fact, so
just removing it solves the problem.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: remove debug trace

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>

config: Keep inner whitespace verbatim

Configuration values are expected to be quoted when they have leading or
trailing whitespace, but inner whitespace should be kept verbatim even if
the value is not quoted. This is already documented in git-config(1), but
the code caused inner whitespace to be collapsed to a single space,
breaking, for example, clones from a path that has two consecutive spaces
in it, as future fetches would only see a single space.

Reported-by: John te Bokkel <tanj.tanj@gmail.com>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.6.3.4

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

config.txt: document add.ignore-errors

Use the description of "--ignore-errors" from git-add.txt as
inspiration.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

request-pull: allow ls-remote to notice remote.$nickname.uploadpack

The location to pull from should be converted from the configured nickname
to URL in the message, but ls-remote should be fed the nickname so that
the command uses remote.$nickname.* variables, most notably "uploadpack".

Signed-off-by: Tom Grennan <tgrennan@redback.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t8005: Nobody writes Russian in shift_jis

The second and third tests of this script expected that Russian strings
are converted between ISO-8859-5 and Shift_JIS in the "blame --porcelain"
format output correctly.

Sure, many platforms may convert between such a combination, but that is
only because one of the base character set of Shift_JIS, JIS X 0208,
defines codepoints for Russian characters (among others); I do not think
anybody uses Shift_JIS when seriously writing Russian, and it is perfectly
understandable if iconv() libraries on some platforms fail converting
between this combination, as it does not matter in reality.

This patch changes the test to verify Japanese strings are converted
correctly between EUC-JP and Shift_JIS in the same procedure.  The point
of the test is not about verifying the platform's iconv() library, but to
see if "git blame" makes correct iconv() library calls when it should.

We could instead use ISO-8859-5 and KOI8-R as the combination, because
they are both meant to represent Russian, in order to make this test
meaningful on more platforms, but we already use Shift_JIS vs EUC-JP
combinations to test other programs in our test suite, so this combination
is safer from the point of view of the portability.  Besides, I do not
read nor write Russian; sorry ;-)

This change allows tests to pass on my (friend's) Solaris 5.11 box.

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

Fix severe breakage in "git-apply --whitespace=fix"

735c674 (Trailing whitespace and no newline fix, 2009-07-22) completely
broke --whitespace=fix, causing it to lose all the empty lines in a patch.

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

SunOS grep does not understand -C<n> nor -e

The first "grep -C1" test in t7002 does not pass on my SunOS-5.11-i86pc,
and that is not because our way to spawn external grep is broken, but
because the native grep does not understand -C<n>.

It turns out that Peff was also using this option himself because our
Makefile doesn't do that automatically.  Brandon Casey uses SUNWspro
compiler without having to set this, and it turns out that the compiler
does not define preprocessor macro __unix__ which made him always use the
built-in grep, never an external one.

Let's be more explicit and say that we do not use external grep on Suns.

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

Fix export_marks() error handling.

- Don't leak one FILE * on error per export_marks() call. Found with
  cppcheck and reported by Martin Ettl.

- Abort the potentially long for(;idnums.size;) loop on write errors.

- Record error if fprintf() fails for reasons not required to set the
  stream error indicator, such as ENOMEM.

- Add a trailing full-stop to error message when fopen() fails.

Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git branch: clean up detached branch handling

Make the 'show detached branch info' a routine of its own.  And in the
process, avoid the object lookup that is unnecessary if the current
branch isn't detached.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git branch: avoid unnecessary object lookups

They can be expensive in the cold-cache case, so don't bother looking up
the commits for all branches unless we really need them for some reason.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git branch: fix performance problem

'git branch' looks at _all_ the refs, and verifies them.  Which means that
during cold-cache situations with a slow disk (and lots of tags, for
example) it can take several very annoying seconds (7.5s according to a
report by Carlos R.  Mafra).

This avoids most of it by simply doing the filtering before looking up
the commits, by using the "raw" version of for_each_ref.

Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

do_one_ref(): null_sha1 check is not about broken ref

f8948e2 (remote prune: warn dangling symrefs, 2009-02-08) introduced a
more dangerous variant of for_each_ref() family that skips the check for
dangling refs, but it also made another unrelated check optional by
mistake.

The check to see if a ref points at 0{40} is not about brokenness, but is
about a possible future plan to represent a deleted ref by writing 40 "0"
in a loose ref when there is a stale version of the same ref already in
.git/packed-refs, so that we can implement deletion of a ref without
having to rewrite the packed refs file excluding the ref being deleted.

This check has to live outside of the conditional.

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

Trailing whitespace and no newline fix

If a patch adds a new line to the end of a file and this line ends with
one trailing whitespace character and has no newline, then
'--whitespace=fix' currently does not remove that trailing whitespace.

This patch fixes this by removing the check for trailing whitespace at
the end of the line at a hardcoded offset which does not take the
eventual absence of newline into account.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --cc: a lost line at the beginning of the file is shown incorrectly

When combine-diff inspected the diff from one parent to the merge result,
it misinterpreted a header in the form @@ -l,k +0,0 @@.

This hunk header means that K lines were removed from the beginning of the
file, so the lost lines must be queued to the sline that represents the
first line of the merge result, but we incremented our pointer incorrectly
and ended up queuing it to the second line, which in turn made the lossage
appear _after_ the first line.

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

combine-diff.c: fix performance problem when folding common deleted lines

For a deleted line in a patch with the parent we are looking at, the
append_lost() function finds the same line among a run of lines that were
deleted from the same location by patches from parents we previously
checked.  This is so that patches with two parents

    @@ -1,4 +1,3 @@    @@ -1,4 +1,3 @@
     one                   one
    -two                  -two
     three                 three
    -quatro               -fyra
    +four                 +four

can be coalesced into this sequence, reusing one line that describes the
removal of "two" for both parents.

   @@@ -1,4 -1,4 +1,3 @@@
     one
   --two
     three
   - quatro
    -frya
   ++four

While reading the second patch (that removes "two" and then "fyra"), after
finding where removal of the "two" matches, we need to find existing
removal of "fyra" (if exists) in the removal list, but the match has to
happen after all the existing matches (in this case "two").  The code used
a naïve O(n^2) algorithm to compute this by scanning the whole removal
list over and over again.

This patch remembers where the next scan should be started in the existing
removal list to avoid this.

Noticed by Linus Torvalds.

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

checkout -f: deal with a D/F conflict entry correctly

When we switch branches with "checkout -f", unpack_trees() feeds two
cache_entries to oneway_merge() function in its src[] array argument.  The
zeroth entry comes from the current index, and the first entry represents
what the merge result should be, taken from the tree recorded in the
commit we are switching to.

When we have a blob (either regular file or a symlink) in the index and in
the work tree at path "foo", and the switched-to tree has "foo/bar",
i.e. "foo" becomes a directory, src[0] is obviously that blob currently
registered at "foo".  Even though we do not have anything at "foo" in the
switched-to tree, src[1] is _not_ NULL in this case.

The unpack_trees() machinery places a special marker df_conflict_entry
to signal that no blob exists at "foo", but it will become a directory
that may have somthing underneath it (namely "foo/bar"), so a usual 3-way
merge can notice the situation.

But oneway_merge() codepath failed to notice this and passed the special
marker directly to merged_entry().  This happens to remove the "foo" in
the end because the df_conflict_entry does not have any name (hence the
"error" message) and its addition in add_index_entry() is rejected, but it
is wrong.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>

sha1_name.c: avoid unnecessary strbuf_release

When we fall back to a standard for_each_reflog_ent() after failing to find
the nth branch switch (or if we had a short reflog) with the call to
for_each_recent_reflog_ent(), we do not need to free the memory allocated
for our strbuf's since a strbuf_reset() will be performed in
grab_nth_branch_switch() before assigning to the entry.

Plus, the strbuf_release() negates the non-zero hint we initially gave to
strbuf_init() just above these lines.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs.c: release file descriptor on error return

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'cb/maint-fetch-refspec-wo-dst' into maint

* cb/maint-fetch-refspec-wo-dst:
  fetch: do not create ref from empty name

Merge branch 'cf/maint-remote-uploadpack-useconfig-fix' into maint

* cf/maint-remote-uploadpack-useconfig-fix:
  git-remote: fix missing .uploadpack usage for show command

Documentation: update description of shell aliases

Aliases that invoke shell commands start from the top-level directory,
but this was not documented.

Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

request-pull: really really disable pager

Earlier 476cc72 (request-pull: really disable pager, 2009-06-30)
tried to use the correct environment variable to disable paging
from multiple calls to "git log" and friends, but there was one
extra call to "git log" that was not covered by the trick.

Move the setting and exporting of GIT_PAGER much earlier in the
script to cover everybody.

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

attr: plug minor memory leak

Free the memory allocated for struct strbuf pathbuf when we're done.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

request-pull: really disable pager

ff06c74 (Improve request-pull to handle non-rebased branches, 2007-05-01)
attempted to disable pager when running subcommands in this script, but
with a wrong variable.  If GIT_PAGER is set, it takes precedence over
PAGER.

Noticed by Michal Marek.

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

Makes some cleanup/review in gittutorial

There are some different but little cleanup changes to fix some missing
quotes, to fix what seemed to be an unended sentence, to reident a
little paragraph with too large a sentence and fix a branch name that
was referred to twice later by another name.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: git.o depends on library headers

This dependency was not yet specified anywhere else.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-submodule documentation: fix foreach example

Backtick and apostrophe are asciidoc markup, so they should be escaped
in order to get the expected result in the rendered manual page.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb/README: fix AliasMatch in example

When combining "dumb client" and human-friendly access by using the
'.git' extension to switch between the two, make sure the AliasMatch
covers the entire request. Without a full match, a request for

http://git.example.com/project/shortlog/branch..gitsomething

would result in a 404 because the server would try to access the
the project 'project/shortlog/branch.'

The solution is still not bulletproof, so document the possible failing
case.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Test grep --and/--or/--not

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Test git archive --remote

Add a small test case for git archive --remote (and thus
git-upload-archive), which so far went untested.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote: fix missing .uploadpack usage for show command

For users pulling from machines with self compiled git installs,
in non-PATH locations, they can set the config option
remote.<name>.uploadpack to set the location of git-upload-pack.

When using 'git remote show <name>', the remote HEAD check
did not use the uploadpack configuration setting, and would
not use the configured program.

In builtin-remote.c, the config setting is already loaded
with the call to remote_get(), so this patch passes that remote
along to transport_get().

Signed-off-by: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fread does not return negative on error

size_t res cannot be less than 0. fread returns 0 on error.

Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3700-add: add a POSIXPERM prerequisite to a new test

The new test does a 'chmod 0', which does not have the intended
effect on Windows.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'sb/maint-1.6.0-add-config-fix' into maint

* sb/maint-1.6.0-add-config-fix:
  add: allow configurations to be overriden by command line

GIT 1.6.3.3

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

Merge branch 'ak/maint-for-each-ref-no-lookup' into maint

* ak/maint-for-each-ref-no-lookup:
  for-each-ref: Do not lookup objects when they will not be used

Merge branch 'rc/maint-http-local-slot-fix' into maint

* rc/maint-http-local-slot-fix:
  http*: cleanup slot->local after fclose

Merge branch 'cb/maint-no-double-merge' into maint

* cb/maint-no-double-merge:
  refuse to merge during a merge

Merge branch 'mn/maint-iconv-autoconf' into maint

* mn/maint-iconv-autoconf:
  fix handling of iconv configuration options

Merge branch 'lt/maint-unsigned-left-shift' into maint

* lt/maint-unsigned-left-shift:
  Fix big left-shifts of unsigned char

Merge branch 'pb/maint-1.6.2-userdiff-fix' into maint

* pb/maint-1.6.2-userdiff-fix:
  upload-archive: fix infinite loop on Cygwin
  avoid exponential regex match for java and objc function names

attribute: whitespace set to true detects all errors known to git

That is what the documentation says, but the code pretends as if all the
known whitespace error tokens were given.

Among the whitespace error tokens, there is one kind that loosens the rule
when set: cr-at-eol.  Which means that whitespace error token that is set
to true ignores a newly introduced CR at the end, which is inconsistent
with the documentation.

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

.gitattributes: CR at the end of the line is an error

When a CR is accidentally added at the end of a C source file in the git
project tree, "git diff --check" doesn't detect it as an error.

    $ echo abQ | tr Q '\015' >>fast-import.c
    $ git diff --check

I think this is because the "whitespace" attribute is set to *.[ch] files
without specifying what kind of errors are caught. It makes git "notice
all types of errors" (as described in the documentation), but I think it
is incorrectly setting cr-at-eol, too, and hides this error.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3505: fix abuse of test_expect_code

The test wanted to make sure that cherry-pick exits with status 1,
but with the way it was placed after "git checkout master &&" meant
that it could have misjudged success if checkout barfed with the
same failure status.

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

Merge branch 'maint-1.6.2' into maint

* maint-1.6.2:
  git-show-ref.txt: remove word and make consistent
  git-svn documentation: fix typo in 'rebase vs. pull/merge' section
  use xstrdup, not strdup in ll-merge.c

Merge branch 'maint-1.6.1' into maint-1.6.2

* maint-1.6.1:
  git-show-ref.txt: remove word and make consistent
  git-svn documentation: fix typo in 'rebase vs. pull/merge' section
  use xstrdup, not strdup in ll-merge.c

Merge branch 'maint-1.6.0' into maint-1.6.1

* maint-1.6.0:
  git-show-ref.txt: remove word and make consistent
  git-svn documentation: fix typo in 'rebase vs. pull/merge' section
  use xstrdup, not strdup in ll-merge.c

git-show-ref.txt: remove word and make consistent

Under is better than in because of the nested nature of the .git
directory.

"also using" sounds a little odd, plus we say combined with later on so
just use that.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn documentation: fix typo in 'rebase vs. pull/merge' section

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add: allow configurations to be overriden by command line

Don't call git_config after parsing the command line options, otherwise
the config settings will override any settings made by the command line.

This can be seen by setting add.ignore_errors and then specifying
--no-ignore-errors when using git-add.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http.c: fix compiling with libcurl 7.9.2

Change the minimimum required libcurl version for the http.sslKey option
to 7.9.3.  Previously, preprocessor macros checked for >= 7.9.2, which
is incorrect because CURLOPT_SSLKEY was introduced in 7.9.3.  This now
allows git to compile with libcurl 7.9.2.

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: do not create ref from empty name

Previously, the refspec "<src>:" would be expanded to
"<src>:refs/heads/". Instead, treat an empty <dst> just like refspecs
without a colon.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

import-tars: support symlinks

Without this patch, symbolic links are turned into empty files.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

upload-archive: fix infinite loop on Cygwin

On Cygwin, poll() reports POLLIN even for file descriptors that have
reached their end.  This caused git upload-archive to be stuck in an
infinite loop, as it only looked at the POLLIN flag.

In addition to POLLIN, check if read() returned 0, which indicates
end-of-file, and keep looping only as long as at least one of the file
descriptors has input.  This lets the following command finish on its
own when run in a git repository on Cygwin, instead of it getting stuck
after printing all file names:

$ git archive -v --remote . HEAD >/dev/null

Reported-by: Bob Kagy <bobkagy@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

avoid exponential regex match for java and objc function names

In the old regex

^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\([^;]*)$
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

you can backtrack arbitrarily from [A-Za-z_0-9]* into [A-Za-z_], thus
causing an exponential number of backtracks.  Ironically it also causes
the regex not to work as intended; for example "catch" can match the
underlined part of the regex, the first repetition matching "c" and
the second matching "atch".

The replacement regex avoids this problem, because it makes sure that
at least a space/tab is eaten on each repetition.  In other words,
a suffix of a repetition can never be a prefix of the next repetition.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix big left-shifts of unsigned char

Shifting 'unsigned char' or 'unsigned short' left can result in sign
extension errors, since the C integer promotion rules means that the
unsigned char/short will get implicitly promoted to a signed 'int' due to
the shift (or due to other operations).

This normally doesn't matter, but if you shift things up sufficiently, it
will now set the sign bit in 'int', and a subsequent cast to a bigger type
(eg 'long' or 'unsigned long') will now sign-extend the value despite the
original expression being unsigned.

One example of this would be something like

unsigned long size;
unsigned char c;

size += c << 24;

where despite all the variables being unsigned, 'c << 24' ends up being a
signed entity, and will get sign-extended when then doing the addition in
an 'unsigned long' type.

Since git uses 'unsigned char' pointers extensively, we actually have this
bug in a couple of places.

I may have missed some, but this is the result of looking at

git grep '[^0-9  ][  ]*<<[  ][a-z]' -- '*.c' '*.h'
git grep '<<[   ]*24'

which catches at least the common byte cases (shifting variables by a
variable amount, and shifting by 24 bits).

I also grepped for just 'unsigned char' variables in general, and
converted the ones that most obviously ended up getting implicitly cast
immediately anyway (eg hash_name(), encode_85()).

In addition to just avoiding 'unsigned char', this patch also tries to use
a common idiom for the delta header size thing. We had three different
variations on it: "& 0x7fUL" in one place (getting the sign extension
right), and "& ~0x80" and "& 0x7f" in two other places (not getting it
right). Apart from making them all just avoid using "unsigned char" at
all, I also unified them to then use a simple "& 0x7f".

I considered making a sparse extension which warns about doing implicit
casts from unsigned types to signed types, but it gets rather complex very
quickly, so this is just a hack.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pull, rebase: simplify to use die()

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

use xstrdup, not strdup in ll-merge.c

Otherwise, a fluky allocation failure would cause merge
configuration settings to be silently ignored.

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.2' into maint

* maint-1.6.2:
  git-rerere.txt: grammatical fixups and cleanups

Merge branch 'maint-1.6.1' into maint-1.6.2

* maint-1.6.1:
  git-rerere.txt: grammatical fixups and cleanups