Make the MSVC projects use PDB/IDB files named after the project
Instead of having all PDB files for all projects named "vc90.pdb", name them
after the respective project to make the relation more clear (and to avoid name
clashes when copying files around).
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Marius Storm-Olsen <mstormo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When compiling with MSVC on x86-compatible, use an intrinsic for byte swapping.
In contrast to the GCC path, we do not prefer inline assembly here as it is not
supported for the x64 platform.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 28 Oct 2009 18:21:46 +0000 (11:21 -0700)]
Merge branch 'maint'
* maint:
help -a: do not unnecessarily look for a repository
Do not try to remove directories when removing old links
rebase -i: more graceful handling of invalid commands
help -i: properly error out if no info viewer can be found
David Brown [Wed, 28 Oct 2009 17:13:44 +0000 (10:13 -0700)]
commit: More generous accepting of RFC-2822 footer lines.
'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself. Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.
Be more generous in considering lines to be part of this footer.
If the last paragraph of the commit message reasonably resembles
RFC-2822 formatted lines, don't insert that blank line.
The new Signed-off-by line is still only suppressed when the
author's existing Signed-off-by is the last line of the message.
Signed-off-by: David Brown <davidb@quicinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash completion: difftool accepts the same options as diff
So complete refs, files after the double-dash and some diff options that
make sense for difftool.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
help -a: do not unnecessarily look for a repository
Although 'git help -a' actually doesn't need to be run inside a git
repository and uses no repository-specific information, it looks for a git
directory. On 'git <TAB><TAB>' the bash completion runs 'git help -a' and
unnecessary searching for a git directory can be annoying in auto-mount
environments. With this commit, 'git help' no longer searches for a
repository when run with the -a option.
Reported by Vincent Danjean through http://bugs.debian.org/539273
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Björn Gustavsson [Sat, 17 Oct 2009 09:33:38 +0000 (11:33 +0200)]
bash: complete more options for 'git rebase'
Complete all long options for 'git rebase' except --no-verify
(probably used very seldom) and the long options corresponding
to -v, -q, and -f.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not try to remove directories when removing old links
When building Git with MSVC on Windows, directories named after the Git alias
are created for the output files, e.g. there is a "git-merge-index" directory
next to the "git-merge-index.exe" executable in the build root. Previously,
"make all" just checked if "git-merge-index" and "git-merge-index.exe" are the
same file, and if not, tried to remove "git-merge-index". This fails in the
case of "git-merge-index" being a directory, which is why this is checked now.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jan Krüger [Tue, 27 Oct 2009 14:58:14 +0000 (15:58 +0100)]
rebase -i: more graceful handling of invalid commands
Currently, when there is an invalid command, the rest of the line is
still treated as if the command had been valid, i.e. rebase -i attempts
to produce a patch, using the next argument as a SHA1 name. If there is
no next argument or an invalid one, very confusing error messages
appear (the line was '.'; path to git-rebase-todo substituted):
Unknown command: .
fatal: ambiguous argument 'Please fix this in the file $somefile.':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name Please fix this in the file $somefile.
fatal: bad revision 'Please fix this in the file $somefile.'
Instead, verify the validity of the remaining line and error out earlier
if necessary.
Signed-off-by: Jan Krüger <jk@jk.gs> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 27 Oct 2009 23:07:41 +0000 (16:07 -0700)]
Merge git://git.bogomips.org/git-svn
* git://git.bogomips.org/git-svn:
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
git-svn: add test data for SVN 1.5+ merge, with script.
git-svn: convert SVK merge tickets to extra parents
git-svn: allow test setup script to support PERL env. var
git-svn: add test data for SVK merge, with script.
git svn: fix fetch where glob is on the top-level URL
Junio C Hamano [Tue, 27 Oct 2009 21:55:37 +0000 (14:55 -0700)]
Merge git://repo.or.cz/git-gui
* git://repo.or.cz/git-gui:
git-gui: adjust the minimum height of diff pane for shorter screen height
git-gui: fix use of uninitialized variable
git-gui: store wm state and fix wm geometry
git-gui: Ensure submodule path is quoted properly
git-gui: fix diff for partially staged submodule changes
git-gui: Update russian translation
git-gui: Limit display to a maximum number of files
git-gui: remove warning when deleting correctly merged remote branch
git-gui: Added Greek translation & glossary
git-gui: display summary when showing diff of a submodule
Vietor Liu [Fri, 16 Oct 2009 09:41:26 +0000 (17:41 +0800)]
git-gui: adjust the minimum height of diff pane for shorter screen height
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden. The diff pane is resizable, so that it can use less vertical
height, allowing the overall window to be shorter and still display both
the entire commit pane and status bar.
Signed-off-by: Vietor Liu <vietor@vxwo.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sam Vilain [Tue, 20 Oct 2009 02:42:03 +0000 (15:42 +1300)]
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
This feature is long overdue; convert SVN's merge representation to git's
as revisions are imported. This works by converting the list of revisions
in each line of the svn:mergeinfo into git revision ranges, and then
checking the latest of each of these revision ranges for A) being new and
B) now being completely merged.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
Sam Vilain [Tue, 20 Oct 2009 02:42:01 +0000 (15:42 +1300)]
git-svn: convert SVK merge tickets to extra parents
SVK is a simple case to start with, as its idea of merge parents
matches git's one. When a svk:merge ticket is encountered, check each
of the listed merged revisions to see if they are in the history of
this commit; if not, then we have encountered a merge - record it.
[ew: minor formatting cleanups]
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Acked-by: Eric Wong <normalperson@yhbt.net>
Eric Wong [Fri, 23 Oct 2009 06:39:04 +0000 (23:39 -0700)]
git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Thanks to Daniel Cordero for the original bug report and
bisection.
Junio C Hamano [Mon, 26 Oct 2009 01:40:20 +0000 (18:40 -0700)]
Merge branch 'jc/receive-pack-auto'
* jc/receive-pack-auto:
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
gc --auto --quiet: make the notice a bit less verboase
Andreas Schwab [Sat, 24 Oct 2009 13:06:57 +0000 (15:06 +0200)]
Work around option parsing bug in the busybox tar implementation
The first argument of the tar command is interpreted as a bundle of
letters specifying the mode of operation and additional options, with
any option arguments taken from subsequent words on the command line
as needed. The implementation of tar in busybox treats this bundle
as if preceded by a dash and then parses it by getopt rules, which
mishandles 'tar xfo -'. Use 'tar xof -' instead to work this around.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 22 Oct 2009 06:06:14 +0000 (23:06 -0700)]
Fix incorrect error check while reading deflated pack data
The loop in get_size_from_delta() feeds a deflated delta data from the
pack stream _until_ we get inflated result of 20 bytes[*] or we reach the
end of stream.
Side note. This magic number 20 does not have anything to do with the
size of the hash we use, but comes from 1a3b55c (reduce delta head
inflated size, 2006-10-18).
The loop reads like this:
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
This git_inflate() can return:
- Z_STREAM_END, if use_pack() fed it enough input and the delta itself
was smaller than 20 bytes;
- Z_OK, when some progress has been made;
- Z_BUF_ERROR, if no progress is possible, because we either ran out of
input (due to corrupt pack), or we ran out of output before we saw the
end of the stream.
The fix b3118bd (sha1_file: Fix infinite loop when pack is corrupted,
2009-10-14) attempted was against a corruption that appears to be a valid
stream that produces a result larger than the output buffer, but we are
not even trying to read the stream to the end in this loop. If avail_out
becomes zero, total_out will be the same as sizeof(delta_head) so the loop
will terminate without the "fix". There is no fix from b3118bd needed for
this loop, in other words.
The loop in unpack_compressed_entry() is quite a different story. It
feeds a deflated stream (either delta or base) and allows the stream to
produce output up to what we expect but no more.
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR)
This _does_ risk falling into an endless interation, as we can exhaust
avail_out if the length we expect is smaller than what the stream wants to
produce (due to pack corruption). In such a case, avail_out will become
zero and inflate() will return Z_BUF_ERROR, while avail_in may (or may
not) be zero.
But this is not a right fix:
do {
in = use_pack();
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out)
+ break; /* wants more input??? */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR)
as Z_BUF_ERROR from inflate() may be telling us that avail_in has also run
out before reading the end of stream marker. In such a case, both avail_in
and avail_out would be zero, and the loop should iterate to allow the end
of stream marker to be seen by inflate from the input stream.
The right fix for this loop is likely to be to increment the initial
avail_out by one (we allocate one extra byte to terminate it with NUL
anyway, so there is no risk to overrun the buffer), and break out if we
see that avail_out has become zero, in order to detect that the stream
wants to produce more than what we expect. After the loop, we have a
check that exactly tests this condition:
So here is a patch (without my previous botched attempts) to fix this
issue. The first hunk reverts the corresponding hunk from b3118bd, and
the second hunk is the same fix proposed earlier.
Ingmar Vanhassel [Tue, 20 Oct 2009 10:29:32 +0000 (12:29 +0200)]
import-tars: Add support for tarballs compressed with lzma, xz
Also handle the extensions .tlz and .txz, aliases for .tar.lzma and
.tar.xz respectively.
Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org> Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 20 Oct 2009 21:56:40 +0000 (14:56 -0700)]
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
Introduce two new configuration variables, receive.autogc (defaults to
true) and receive.updateserverinfo (defaults to false). When these are
set, receive-pack runs "gc --auto --quiet" and "update-server-info"
respectively after it finishes receiving data from "git push" and updating
refs.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Nicolas Pitre <nico@fluxnic.net>
Junio C Hamano [Tue, 20 Oct 2009 18:46:55 +0000 (11:46 -0700)]
fsck: default to "git fsck --full"
Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed. Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths. It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.
Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.
The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much. At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.
Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum. That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.
Stephen Boyd [Fri, 16 Oct 2009 04:14:59 +0000 (21:14 -0700)]
gitweb: linkify author/committer names with search
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Linkify the avatar icon in log/shortlog view because the icon is directly
adjacent to the name and thus more related. The same is not true
when in commit/tag view where the icon is farther away.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stephen Boyd [Fri, 16 Oct 2009 06:32:33 +0000 (23:32 -0700)]
rebase -i: fix reword when using a terminal editor
We don't want to use output() on git-commit --amend when rewording the
commit message. This leads to confusion as the editor is run in a
subshell with it's output saved away, leaving the user with a seemingly
frozen terminal.
Fix by removing the output part.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 16 Oct 2009 05:59:41 +0000 (22:59 -0700)]
format_commit_message(): fix function signature
The format template string was declared as "const void *" for some unknown
reason, even though it obviously is meant to be passed a string. Make it
"const char *".
Jeff King [Mon, 19 Oct 2009 06:49:55 +0000 (02:49 -0400)]
cvsimport: fix relative argument filenames
One of the first things that cvsimport does is chdir to the
newly created git repo. This means that any filenames given
to us on the command line will be looked up relative to the
git repo directory. This is probably not what the user
expects, so let's remember and prepend the original
directory for relative filenames.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Scharfe [Sat, 17 Oct 2009 16:30:48 +0000 (18:30 +0200)]
describe: load refnames before calling describe()
Get rid of the static variable that was used to prevent loading all
the refnames multiple times by moving that code out of describe(),
simply making sure it is only run once that way.
Also change the error message that is shown in case no refnames are
found to not include a hash any more, as the error condition is not
specific to any particular revision.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 19 Oct 2009 05:58:53 +0000 (22:58 -0700)]
Merge branch 'maint'
* maint:
git push: say that --tag can't be used with --all or --mirror in help text
git push: remove incomplete options list from help text
document push's new quiet option
Makefile: clean block-sha1/ directory instead of mozilla-sha1/
Nanako Shiraishi [Mon, 19 Oct 2009 02:54:12 +0000 (11:54 +0900)]
git push: remove incomplete options list from help text
'git push -h' shows usage text with incomplete list of options and then
has a separate list of options that are supported. Imitate the way other
commands (I looked at 'git diff' for an example) show their options.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 17 Oct 2009 07:11:03 +0000 (00:11 -0700)]
Merge branch 'jc/maint-blank-at-eof'
* jc/maint-blank-at-eof:
diff -B: colour whitespace errors
diff.c: emit_add_line() takes only the rest of the line
diff.c: split emit_line() from the first char and the rest of the line
diff.c: shuffling code around
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
Shawn O. Pearce [Wed, 14 Oct 2009 14:23:51 +0000 (07:23 -0700)]
sha1_file: Fix infinite loop when pack is corrupted
Some types of corruption to a pack may confuse the deflate stream
which stores an object. In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.
Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.
We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.
This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: Andy Isaacson <adi@hexapodia.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 14 Oct 2009 08:54:51 +0000 (01:54 -0700)]
Merge branch 'maint'
* maint:
change throughput display units with fast links
clone: Supply the right commit hash to post-checkout when -b is used
remote-curl: add missing initialization of argv0_path
Björn Steinbrink [Tue, 13 Oct 2009 22:11:09 +0000 (00:11 +0200)]
clone: Supply the right commit hash to post-checkout when -b is used
When we use -b <branch>, we may checkout something else than what the
remote's HEAD references, but we still used remote_head to supply the
new ref value to the post-checkout hook, which is wrong.
So instead of using remote_head to find the value to be passed to the
post-checkout hook, we have to use our_head_points_at, which is always
correctly setup, even if -b is not used.
This also fixes a segfault when "clone -b <branch>" is used with a
remote repo that doesn't have a valid HEAD, as in such a case
remote_head is NULL, but we still tried to access it.
Reported-by: Devin Cofer <ranguvar@archlinux.us> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Giuseppe Bilotta [Tue, 13 Oct 2009 19:51:36 +0000 (21:51 +0200)]
gitweb: fix esc_param
The custom CGI escaping done in esc_param failed to escape UTF-8
properly. Fix by using CGI::escape on each sequence of matched
characters instead of sprintf()ing a custom escaping for each byte.
Additionally, the space -> + escape was being escaped due to greedy
matching on the first substitution. Fix by adding space to the
list of characters not handled on the first substitution.
Finally, remove an unnecessary escaping of the + sign.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Tue, 13 Oct 2009 10:53:28 +0000 (12:53 +0200)]
remote-curl: add missing initialization of argv0_path
All programs, in particular also the stand-alone programs (non-builtins)
must call git_extract_argv0_path(argv[0]) in order to help builds that
derive the installation prefix at runtime, such as the MinGW build.
Without this call, the program segfaults (or raises an assertion
failure).
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Tested-by: Michael Wookey <michaelwookey@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Christian Couder [Mon, 12 Oct 2009 20:30:32 +0000 (22:30 +0200)]
git: add --no-replace-objects option to disable replacing
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace-objects" option that this patch adds it is
possible to get information about the original commit using:
$ git --no-replace-objects cat-file -p N
While at it, let's add some documentation about this new option in the
"git replace" man page too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Mon, 12 Oct 2009 20:34:12 +0000 (22:34 +0200)]
Let --decorate show HEAD position
'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Mon, 12 Oct 2009 09:00:09 +0000 (11:00 +0200)]
bash completion: complete refs for git-grep
Before the --, always attempt ref completion. This helps with
entering the <treeish> arguments to git-grep. As a bonus, you can
work around git-grep's current lack of --all by hitting M-*, ugly as
the resulting command line may be.
Strictly speaking, completing the regular expression argument (or
option argument) makes no sense. However, we cannot prevent _all_
completion (it will fall back to filenames), so we dispense with any
additional complication to detect whether the user still has to enter
a regular expression.
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>