tokkee.org

core.whitespace: split trailing-space into blank-at-{eol,eof}

People who configured trailing-space depended on it to catch both extra
white space at the end of line, and extra blank lines at the end of file.
Earlier attempt to introduce only blank-at-eof gave them an escape hatch
to keep the old behaviour, but it is a regression until they explicitly
specify the new error class.

This introduces a blank-at-eol that only catches extra white space at the
end of line, and makes the traditional trailing-space a convenient synonym
to catch both blank-at-eol and blank-at-eof.  This way, people who used
trailing-space continue to catch both classes of errors.

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

diff --color: color blank-at-eof

Since the coloring logic processed the patch output one line at a time, we
couldn't easily color code the new blank lines at the end of file.

Reuse the adds_blank_at_eof() function to find where the runs of such
blank lines start, keep track of the line number in the preimage while
processing the patch output one line at a time, and paint the new blank
lines that appear after that line to implement this.

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

diff --whitespace=warn/error: fix blank-at-eof check

The "diff --check" logic used to share the same issue as the one fixed for
"git apply" earlier in this series, in that a patch that adds new blank
lines at end could appear as

    @@ -l,5 +m,7 @@$
    _context$
    _context$
    -deleted$
    +$
    +$
    +$
    _$
    _$

where _ stands for SP and $ shows a end-of-line.  Instead of looking at
each line in the patch in the callback, simply count the blank lines from
the end in two versions, and notice the presence of new ones.

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

diff --whitespace=warn/error: obey blank-at-eof

The "diff --check" code used to conflate trailing-space whitespace error
class with this, but now we have a proper separate error class, we should
check it under blank-at-eof, not trailing-space.

The whitespace error is not about _having_ blank lines at end, but about
adding _new_ blank lines.  To keep the message consistent with what is
given by "git apply", call whitespace_error_string() to generate it,
instead of using a hardcoded custom message.

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

diff.c: the builtin_diff() deals with only two-file comparison

The combined diff is implemented in combine_diff() and fn_out_consume()
codepath never has to deal with anything but two-file comparision.

Drop nparents from the emit_callback structure and simplify the code.

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

apply --whitespace: warn blank but not necessarily empty lines at EOF

The whitespace error of adding blank lines at the end of file should
trigger if you added a non-empty line at the end, if the contents of the
line is full of whitespaces.

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

apply --whitespace=warn/error: diagnose blank at EOF

"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.

Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.

The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes.  The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors.  It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.

Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix.  Or you could call it a new feature.  The line
between them is somewhat fuzzy in this case.

Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have.  People who do not want added blank lines at EOF to trigger an error
can disable the new error class.

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

apply.c: split check_whitespace() into two

This splits the logic to record the presence of whitespace errors out of
the check_whitespace() function, which checks and then records.  The new
function, record_ws_error(), can be used by the blank-at-eof check that
does not use ws_check() logic to report its findings in the same output
format.

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

apply --whitespace=fix: detect new blank lines at eof correctly

The command tries to strip blank lines at the end of the file added by a
patch.  It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file.  This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).

If the original ends with blank lines, often the patch hunk ends like
this:

    @@ -l,5 +m,7 @@$
    _context$
    _context$
    -deleted$
    +$
    +$
    +$
    _$
    _$

where _ stands for SP and $ shows a end-of-line.  This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk.  In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:

    @@ -l,5 +m,7 @@$
    _context$
    _context$
    -deleted$
    _$
    _$
    +$
    +$
    +$

The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.

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

apply --whitespace=fix: fix handling of blank lines at the eof

b94f2ed (builtin-apply.c: make it more line oriented, 2008-01-26) broke
the logic used to detect if a hunk adds blank lines at the end of the
file.  With the new code after that commit:

 - img holds the contents of the file that the hunk is being applied to;

 - preimage has the lines the hunk expects to be in img; and

 - postimage has the lines the hunk wants to update the part in img that
   corresponds to preimage with.

and we need to compare if the last line of preimage (not postimage)
matches the last line of img to see if the hunk applies at the end of the
file.

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

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

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>

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>

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>

git-rerere.txt: grammatical fixups and cleanups

Rewrite the gc section using unresolved and resolved instead of "not
recorded". Add plurals and missing articles. Make some sentences have
consistent tense. Try and be more active by removing "that" and
simplifying sentences.

The terms "hand-resolve" and "hand resolve" were used, so just use "hand
resolve" to be more consistent.

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

http-push.c::remove_locks(): fix use after free

Noticed and reported by Serhat Şevki Dinçer.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ls-tree manpage: output of ls-tree is compatible with update-index

Such format relationships are very useful things to remember for
script writers.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ls-tree manpage: use "unless" instead of "when ... is not"

Delayed negation in a statement is harder to spot and keep in mind.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir.c: Fix two minor grammatical errors in comments

Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff -c -p: do not die on submodules

The combine diff logic knew only about blobs (and their checked-out form
in the work tree, either regular files or symlinks), and barfed when fed
submodules.  This "externalizes" gitlinks in the same way as the normal
patch generation codepath does (i.e. "Subproject commit Xxx\n") to fix the
issue.

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

grep: fix segfault when "git grep '('" is given

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

Documentation: fix a grammatical error in api-builtin.txt

Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-merge: fix a typo in an error message

Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-genrandom: Add newline to usage string

A minor fix to place the terminal input on a new line if test-genrandom
is run with no arguments.

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

doc/git-daemon: add missing arguments to options

Also fix some spellings and typos.

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

init: Do not segfault on big GIT_TEMPLATE_DIR environment variable

Signed-off-by: Frank Lichtenheld <flichtenheld@astaro.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix buffer overflow in config parser

When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).

Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.

The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)

    Read: Thanks to Johannes Sixt for the correct printf call
    which replaces the perl invocation.

Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

State the effect of filter-branch on graft explicitly

Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

process_{tree,blob}: Remove useless xstrdup calls

On Wed, 8 Apr 2009, Björn Steinbrink wrote:
>
> The name of the processed object was duplicated for passing it to
> add_object(), but that already calls path_name, which allocates a new
> string anyway. So the memory allocated by the xstrdup calls just went
> nowhere, leaking memory.

Ack, ack.

There's another easy 5% or so for the built-in object walker: once we've
created the hash from the name, the name isn't interesting any more, and
so something trivial like this can help a bit.

Does it matter? Probably not on its own. But a few more memory saving
tricks and it might all make a difference.

Linus

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

process_{tree,blob}: Remove useless xstrdup calls

The name of the processed object was duplicated for passing it to
add_object(), but that already calls path_name, which allocates a new
string anyway. So the memory allocated by the xstrdup calls just went
nowhere, leaking memory.

This reduces the RSS usage for a "rev-list --all --objects" by about 10% on
the gentoo repo (fully packed) as well as linux-2.6.git:

    gentoo:
                    | old           | new
    ----------------|-------------------------------
    RSS             |       1537284 |       1388408
    VSZ             |       1816852 |       1667952
    time elapsed    |       1:49.62 |       1:48.99
    min. page faults|        417178 |        379919

    linux-2.6.git:
                    | old           | new
    ----------------|-------------------------------
    RSS             |        324452 |        292996
    VSZ             |        491792 |        460376
    time elapsed    |       0:14.53 |       0:14.28
    min. page faults|         89360 |         81613

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: clarify .gitattributes search

Use the term "toplevel of the work tree" in gitattributes.txt and
gitignore.txt to define the limits of the search for those files.

Signed-off-by: Jason Merrill <jason@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-checkout.txt: clarify that <branch> applies when no path is given.

Otherwise, the sentence "Defaults to HEAD." can be mis-read to mean
that "git checkout -- hello.c" checks-out from HEAD.

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

git-checkout.txt: fix incorrect statement about HEAD and index

The command "git checkout" checks out from the index by default, not
HEAD (the introducing comment were correct, but the detailled
explanation added below were not).

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

commit: abort commit if interactive add failed

Previously we ignored the result of calling add_interactive,
which meant that if an error occurred we simply committed
whatever happened to be in the index.

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

git-repack: use non-dashed update-server-info

Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: Remove an odd "instead"

Signed-off-by: Holger Weiß <holger@zedat.fu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix bash completion in path with spaces

Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
Trivially-acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bash completion: only show 'log --merge' if merging

The gitk completion only shows --merge if MERGE_HEAD is present.
Do it the same way for git-log completion.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-tag(1): add hint about commit messages

If a tag is not annotated, git tag displays the commit message
instead. Add this hint to the manpage to unhide this secret.

Signed-off-by: Nico Schottelius <nico@ikn.schottelius.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: update graph api example.

As of commit 03300c0 the graph API uses '*' for all nodes including merges.
This updates the example in the documentation to match.

Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

import-zips: fix thinko

Embarrassingly, the common prefix calculation did not work properly, due
to a mistake in the assignment: instead of assigning the dirname of the
current file name, the dirname of the current common prefix needs to
be assigned to common prefix, when the current prefix does not match the
current file name.

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

close_sha1_file(): make it easier to diagnose errors

A bug report with "unable to write sha1 file" made us realize that we do
not have enough information to guess why close() is failing.

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

avoid possible overflow in delta size filtering computation

On a 32-bit system, the maximum possible size for an object is less than
4GB, while 64-bit systems may cope with larger objects.  Due to this
limitation, variables holding object sizes are using an unsigned long
type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).

When large objects are encountered, and/or people play with large delta
depth values, it is possible for the maximum allowed delta size
computation to overflow, especially on a 32-bit system.  When this
occurs, surviving result bits may represent a value much smaller than
what it is supposed to be, or even zero.  This prevents some objects
from being deltified although they do get deltified when a smaller depth
limit is used.  Fix this by always performing a 64-bit multiplication.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

everyday: use the dashless form of git-init

The 'Everyday GIT' guide was using the old dashed form
of git-init.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ks/maint-1.6.0-mailinfo-folded' into maint-1.6.0

* ks/maint-1.6.0-mailinfo-folded:
  mailinfo: tests for RFC2047 examples
  mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
  mailinfo: 'From:' header should be unfold as well
  mailinfo: correctly handle multiline 'Subject:' header

Merge branch 'cc/maint-1.6.0-bisect-fix' into maint-1.6.0

* cc/maint-1.6.0-bisect-fix:
  bisect: fix another instance of eval'ed string
  bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped

Merge branch 'fg/maint-1.6.0-exclude-bq' into maint-1.6.0

* fg/maint-1.6.0-exclude-bq:
  Support "\" in non-wildcard exclusion entries

Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into maint-1.6.0

* jc/maint-1.6.0-split-diff-metainfo:
  diff.c: output correct index lines for a split diff

added missing backtick in git-apply.txt

Signed-off-by: Danijel Tasov <dt@korn.shell.la>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: fix another instance of eval'ed string

When there is nothing to be skipped, the output from
rev-list --bisect-vars was eval'ed without first being
strung together with &&; this is probably not a problem
as it is much less likely to be a bad input than the list
handcrafted by the filter_skip function, but it still is
a good discipline.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped

When the "bad" commit was also "skip"ped and when more than one
commit was skipped, the "filter_skipped" function would have
printed something like:

    bisect_rev=<hash1>|<hash2>

(where <hash1> and <hash2> are hexadecimal sha1 hashes)

and this would have been evaled later as piping "bisect_rev=<hash1>"
into "<hash2>", which would have failed.

So this patch makes the "filter_skipped" function properly quote
what it outputs, so that it will print something like:

bisect_rev='<hash1>|<hash2>'

which will be properly evaled later.  The caller was not stopping
properly because the scriptlet this function returned to be evaled
was not strung together with && and because of this, an error in
an earlier part of the output was simply ignored.

A test case is added to the test suite.

And while at it, we also initialize the VARS, FOUND and TRIED
variables, so that we protect ourselves from environment variables
the user may have with these names.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Support "\" in non-wildcard exclusion entries

"\" was treated differently in exclude rules depending on whether a
wildcard match was done. For wildcard rules, "\" was de-escaped in
fnmatch, but this was not done for other rules since they used strcmp
instead.  A file named "#foo" would not be excluded by "\#foo", but would
be excluded by "\#foo*".

We now treat all rules with "\" as wildcard rules.

Another solution could be to de-escape all non-wildcard rules as we
read them, but we would have to do the de-escaping exactly as fnmatch
does it to avoid inconsistencies.

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make repack less likely to corrupt repository

Some platforms refuse to rename a file that is open.  When repacking an
already packed repository without adding any new object, the resulting
pack will contain the same set of objects as an existing pack, and on such
platforms, a newly created packfile cannot replace the existing one.

The logic detected this issue but did not try hard enough to recover from
it.  Especially because the files that needs renaming come in pairs, there
potentially are different failure modes that one can be renamed but the
others cannot.  Asking manual recovery to end users were error prone.

This patch tries to make it more robust by first making sure all the
existing files that need to be renamed have been renamed before
continuing, and attempts to roll back if some failed to rename.

This is based on an initial patch by Robin Rosenberg.

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

fast-export: ensure we traverse commits in topological order

fast-export will only list as parents those commits which have already
been traversed (making it appear as if merges have been squashed if not
all parents have been traversed).  To avoid this silent squashing of
merge commits, we request commits in topological order.

Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Clear the delta base cache if a pack is rebuilt

There is some risk that re-opening a regenerated pack file with
different offsets could leave stale entries within the delta base
cache that could be matched up against other objects using the same
"struct packed_git*" and pack offset.

Throwing away the entire delta base cache in this case is safer,
as we don't have to worry about a recycled "struct packed_git*"
matching to the wrong base object, resulting in delta apply
errors while unpacking an object.

Suggested-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.5.5' into maint-1.5.6

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

Conflicts:
revision.c

Merge branch 'maint-1.5.4' into maint-1.5.5

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

revision traversal and pack: notice and die on missing commit

cc0e6c5 (Handle return code of parse_commit in revision machinery,
2007-05-04) attempted to tighten error checking in the revision machinery,
but it wasn't enough.  When get_revision_1() was asked for the next commit
to return, it tries to read and simplify the parents of the commit to be
returned, but an error while doing so was silently ignored and reported as
a truncated history to the caller instead.

This resulted in an early end of "git log" output or a pack that lacks
older commits from "git pack-objects", without any error indication in the
exit status from these commands, even though the underlying parse_commit()
issues an error message to the end user.

Note that the codepath in add_parents_list() that paints parents of an
UNINTERESTING commit UNINTERESTING silently ignores the error when
parse_commit() fails; this is deliberate and in line with aeeae1b
(revision traversal: allow UNINTERESTING objects to be missing,
2009-01-27).

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

Clear the delta base cache during fast-import checkpoint

Otherwise we may reuse the same memory address for a totally
different "struct packed_git", and a previously cached object from
the prior occupant might be returned when trying to unpack an object
from the new pack.

Found-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fixed broken git help -w when installing from RPM

After the git-core package was renamed to git, git help -w was still looking
for files in /usr/share/doc/git-core-$VERSION instead of
/usr/share/doc/git-$VERSION.

Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-mv.c: check for unversionned files before looking at the destination.

The previous code was failing in the case where one moves an
unversionned file to an existing destination, with mv -f: the
"existing destination" was checked first, and the error was cancelled
by the force flag.

We now check the unrecoverable error first, which fixes the bug.

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

Add a testcase for "git mv -f" on untracked files.

This currently fails with:
git: builtin-mv.c:217: cmd_mv: Assertion `pos >= 0' failed.

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

Missing && in t/t7001.sh.

Without this, the exit status is only the one of the last line.

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

User-manual: "git stash <comment>" form is long gone

These days you must explicitly say "git stash save <comment>".

Signed-off-by: William Pursell <bill.pursell@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add test-dump-cache-tree in Makefile

5c5ba73 (Makefile: Use generic rule to build test programs,
2007-05-31) tried to use generic rule to build test programs, but it
misses the file 'dump-cache-tree.c', since its name is not prefixed by
'test-'.  This commit solves this little problem by renaming this file
instead of carrying out an explicit rule in Makefile.

Signed-off-by: Guanqun Lu <guanqun.lu@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix typo in Documentation

Signed-off-by: Guanqun Lu <guanqun.lu@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

apply: fix access to an uninitialized mode variable, found by valgrind

When 'tpatch' was initialized successfully, st_mode was already taken
from the previous diff.  We should not try to override it with data
from an lstat() that was never called.

This is a companion patch to 7a07841(git-apply: handle a patch that
touches the same path more than once better).

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

grep: pass -I (ignore binary) down to external grep

We forgot to pass this option to the external grep process.

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

merge: fix out-of-bounds memory access

The parameter n of unpack_callback() can have a value of up to
MAX_UNPACK_TREES.  The check at the top of unpack_trees() (its only
(indirect) caller) makes sure it cannot exceed this limit.

unpack_callback() passes it and the array src to unpack_nondirectories(),
which has this loop:

for (i = 0; i < n; i++) {
/* ... */
src[i + o->merge] = o->df_conflict_entry;

o->merge can be 0 or 1, so unpack_nondirectories() potentially accesses
the array src at index MAX_UNPACK_TREES.  This patch makes it big enough.

Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

avoid 31-bit truncation in write_loose_object

The size of the content we are adding may be larger than
2.1G (i.e., "git add gigantic-file"). Most of the code-path
to do so uses size_t or unsigned long to record the size,
but write_loose_object uses a signed int.

On platforms where "int" is 32-bits (which includes x86_64
Linux platforms), we end up passing malloc a negative size.

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

mailinfo: tests for RFC2047 examples

Also as suggested by Junio, in order to try to catch other MIME
problems, test cases from the "8. Examples" section of RFC2047 are added
to t5100 testsuite as well.

Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>

mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>

test-path-utils: Fix off by one, found by valgrind

When normalizing an absolute path, we might have to add a slash _and_ a
NUL to the buffer, so the buffer was one too small.

Let's just future proof the code and alloc PATH_MAX + 1 bytes.

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

get_sha1_basic(): fix invalid memory access, found by valgrind

When get_sha1_basic() is passed a buffer of len 0, it should not
check if buf[len-1] is a curly bracket.

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

diff.c: output correct index lines for a split diff

A patch that changes the filetype (e.g. regular file to symlink) of a path
must be split into a deletion event followed by a creation event, which
means that we need to have two independent metainfo lines for each.
However, the code reused the single set of metainfo lines.

As the blob object names recorded on the index lines are usually not used
nor validated on the receiving end, this is not an issue with normal use
of the resulting patch.  However, when accepting a binary patch to delete
a blob, git-apply verified that the postimage blob object name on the
index line is 0{40}, hence a patch that deletes a regular file blob that
records binary contents to create a blob with different filetype (e.g. a
symbolic link) failed to apply.  "git am -3" also uses the blob object
names recorded on the index line, so it would also misbehave when
synthesizing a preimage tree.

This moves the code to generate metainfo lines around, so that two
independent sets of metainfo lines are used for the split halves.

Additional tests by Jeff King.

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

Fix Documentation for git-describe

The documentation for git-describe says the default abbreviation is 8
hexadecimal digits while cache.c clearly shows DEFAULT_ABBREV set to 7.
This patch corrects the documentation.

Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-fsck: fix off by one head count

According to the man page, if "git fsck" is passed one or more heads, it
should verify connectivity and validity of only objects reachable from the
heads it is passed.

However, since 5ac0a20 (Make builtin-fsck.c use parse_options.,
2007-10-15) the command behaved as if no heads were passed, when given
only one argument.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: let asciidoc align related options

Command line options can share the same paragraph of description, if
they are related or synonymous. In these cases they should be written
among each other, so that asciidoc can format them itself.

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

githooks.txt: add missing word

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-commit.c: do not remove COMMIT_EDITMSG

git-commit tries to remove the file ./COMMIT_EDITMSG instead of
$GIT_DIR/COMMIT_EDITMSG after commit preparation (e.g. running
hooks, launching editor).
This behavior exists since f5bbc3225c4b07 "Port git commit to C".

Some test cases (e.g. t/t7502-commit.sh) rely on the existence of
$GIT_DIR/COMMIT_EDITMSG after committing and, I guess, many people
are used to it.  So it is best not to remove it.

This patch just removes the removal of COMMIT_EDITMSG.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3404: Add test case for auto-amending only edited commits after "edit"

Add a test case for the bugfix introduced by commit c14c3c82d
"git-rebase--interactive: auto amend only edited commit".

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3404: Add test case for aborted --continue after "edit"

Add a test case for the bugfix introduced by commit 8beb1f33d
"git-rebase-interactive: do not squash commits on abort".

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3501: check that commits are actually done

The basic idea of t3501 is to check whether revert
and cherry-pick works on renamed files.
But as there is no pure cherry-pick/revert test, it is
good to also check if commits are actually done in that
scenario.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix handling of multiple untracked files for git mv -k

The "-k" option to "git mv" should allow specifying multiple untracked
files. Currently, multiple untracked files raise an assertion if they
appear consecutively as arguments. Fix this by decrementing the loop
index after removing one entry from the array of arguments.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add test cases for "git mv -k"

Add test cases for ignoring nonexisting and untracked files using the -k
option to "git mv". There is one known breakage related to multiple
untracked files specfied as consecutive arguments.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-import: Cleanup mode setting.

"S_IFREG | mode" makes only sense for 0644 and 0755.

Even though doing (S_IFREG | mode) may not hurt when mode is any other
supported value, that is only true because S_IFREG mode bit happens to
be already on for S_IFLNK or S_IFGITLINK.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git.pm: call Error::Simple() properly

The error message to Error::Simple() must be passed as a single argument.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Avoid spurious error messages on error mistakes.

Prior to that, if the user chose "squash" as a first action, the stderr
looked like:

    grep: /home/madcoder/dev/scm/git/.git/rebase-merge/done: No such file or directory
    Cannot 'squash' without a previous commit

Now the first line is gone.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contrib/examples/README: give an explanation of the status of these files

We attempt to give an explanation of the status of the files in this
directory.

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

mailinfo: 'From:' header should be unfold as well

At present we do headers unfolding (see RFC822 3.1.1. LONG HEADER FIELDS) for
all fields except 'From' (always) and 'Subject' (when keep_subject is set)

Not unfolding 'From' is a bug -- see above-mentioned RFC link.

Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mailinfo: correctly handle multiline 'Subject:' header

When native language (RU) is in use, subject header usually contains several
parts, e.g.

Subject: [Navy-patches] [PATCH]
=?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?=
=?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?=
=?utf-8?b?0YHQsdC+0YDQutC4?=

This exposes several bugs in builtin-mailinfo.c:

1. decode_b_segment: do not append explicit NUL -- explicit NUL was preventing
   correct header construction on parts concatenation via strbuf_addbuf in
   decode_header_bq.  Fixes:

-Subject: Изменён список пакетов необходимых для сборки
+Subject: Изменён список па

Then

2. Do not emit '\n' between "encoded-word" where RFC2046 says that linear
   white space between them are ignored when displaying.  Fixes:

-Subject: Изменён список пакетов необходимых для сборки
+Subject: Изменён список па кетов необходимых для сборки

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

Merge branch 'maint-1.5.6' into maint-1.6.0

* maint-1.5.6:
  README: tutorial.txt is now called gittutorial.txt

README: tutorial.txt is now called gittutorial.txt

Signed-off-by: Joey Hess <joey@gnu.kitenet.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc/git-fsck: change the way for getting heads' SHA1s

The straightforward way with using 'cat .git/refs/heads/*' doesn't work
with packed refs as well as branches of the form topic/topic1. So let's
use git-for-each-ref for getting the heads' SHA1s in this example.

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.6.0.6

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

fast-import: make tagger information optional

Even though newer Porcelain tools always record the tagger information
when creating new tags, export/import pair should be able to faithfully
reproduce ancient tag objects that lack tagger information.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>

fast-export: deal with tag objects that do not have a tagger

When no tagger was found (old Git produced tags like this),
no "tagger" line is printed (but this is incompatible with the current
git fast-import).

Alternatively, you can pass the option --fake-missing-tagger, forcing
fast-export to fake a tagger

Unspecified Tagger <no-tagger>

with a tag date of the beginning of (Unix) time in the case of a missing
tagger, so that fast-import is still able to import the result.

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