Eric Wong [Sun, 18 Jan 2009 06:11:44 +0000 (22:11 -0800)]
git-svn: fix SVN 1.1.x compatibility
The get_log() function in the Perl SVN API introduced the limit
parameter in 1.2.0. However, this got discarded in our SVN::Ra
compatibility layer when used with SVN 1.1.x. We now emulate
the limit functionality in older SVN versions by preventing the
original callback from being called if the given limit has been
reached. This emulation is less bandwidth efficient, but SVN
1.1.x is becoming rarer now.
Additionally, the --limit parameter in svn(1) uses the
aforementioned get_log() functionality change in SVN 1.2.x.
t9129 no longer depends on --limit to work and instead uses
Perl to parse out the commit message.
Pete Harlan [Sun, 18 Jan 2009 04:10:14 +0000 (20:10 -0800)]
git-svn: Add --localtime option to "fetch"
By default git-svn stores timestamps of fetched commits in
Subversion's UTC format. Passing --localtime to fetch will convert
them to the timezone of the server on which git-svn is run.
This makes the timestamps of a resulting "git log" agree with what
"svn log" shows for the same repository.
Signed-off-by: Pete Harlan <pgit@pcharlan.com> Acked-by: Eric Wong <normalperson@yhbt.net>
Since broken SVN clients can commit svn:special files without
the magic "link " prefix, this can affect delta application
when we update the broken svn:special file. So now we fall
back and retry the delta application on symlinks if having
a "link " prefix fails.
Our behavior differs from svn(1) (v1.5.1) slightly:
When a svn:special file is created w/o a "link " prefix, svn
will create a regular file (mode 100644 to git) with the
contents of the blob as-is.
Our behavior is to continue creating the symlink (mode 120000
to git) with the contents of the blob as-is. While this
differs from current svn(1) behavior, this is easier and more
efficient to implement (and the correctness of the svn(1) is
debatable, since it's a workaround for a bug in the first
place).
More information on this SVN bug is described here:
http://subversion.tigris.org/issues/show_bug.cgi?id=2692
Eric Wong [Mon, 12 Jan 2009 00:51:10 +0000 (16:51 -0800)]
git-svn: handle empty files marked as symlinks in SVN
Broken SVN clients generate empty files with the svn:special set
to '*'. This attempts to denote a symlink pointing to a file
with an empty path (""), which cannot be generated on a POSIX
system.
Thus, we mimic the behavior of svn(1) and create a zero-byte
file in our tree.
Brandon Casey [Fri, 9 Jan 2009 22:14:39 +0000 (16:14 -0600)]
t7700: demonstrate misbehavior of 'repack -a' when local packs exist
The ability to "...fatten [the] local repository by packing everything that
is needed by the local ref into a single new pack, including things that are
borrowed from alternates"[1] is supposed to be provided by the '-a' or '-A'
options to repack when '-l' is not used, but there is a flaw. For each
pack in the local repository without a .keep file, repack supplies a
--unpacked=<pack> argument to pack-objects.
The --unpacked option to pack-objects, with or without an argument, causes
pack-objects to ignore any object which is packed in a pack not mentioned
in an argument to --unpacked=. So, if there are local packs, and
'repack -a' is called, then any objects which reside in packs accessible
through alternates will _not_ be packed. If there are no local packs, then
no --unpacked argument will be supplied, and repack will behave as expected.
Keith Cascio [Thu, 15 Jan 2009 00:48:24 +0000 (16:48 -0800)]
test more combinations of ignore-whitespace options to diff
There are three flags involved (-w -b and --ignore-space-at-eol) which
makes 8 combinations possible in total, but only 3 cases are tested (none,
-w alone and -b alone).
This adds the other 5 cases.
Signed-off-by: Keith Cascio <keith@cs.ucla.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 18 Jan 2009 07:06:38 +0000 (23:06 -0800)]
Merge branch 'tr/rebase-root'
* tr/rebase-root:
rebase: update documentation for --root
rebase -i: learn to rebase root commit
rebase: learn to rebase root commit
rebase -i: execute hook only after argument checking
Junio C Hamano [Sun, 18 Jan 2009 07:05:38 +0000 (23:05 -0800)]
Merge branch 'tr/maint-no-index-fixes'
* tr/maint-no-index-fixes:
diff --no-index -q: fix endless loop
diff --no-index: test for pager after option parsing
diff: accept -- when using --no-index
Junio C Hamano [Sun, 18 Jan 2009 07:04:40 +0000 (23:04 -0800)]
Merge branch 'maint'
* maint:
Update draft release notes for 1.6.1.1
builtin-fsck: fix off by one head count
t5540: clarify that http-push does not handle packed-refs on the remote
http-push: when making directories, have a trailing slash in the path name
http-push: fix off-by-path_len
Documentation: let asciidoc align related options
githooks.txt: add missing word
builtin-commit.c: do not remove COMMIT_EDITMSG
Junio C Hamano [Sun, 18 Jan 2009 06:39:49 +0000 (22:39 -0800)]
Merge branch 'maint-1.6.0' into maint
* maint-1.6.0:
builtin-fsck: fix off by one head count
Documentation: let asciidoc align related options
githooks.txt: add missing word
builtin-commit.c: do not remove COMMIT_EDITMSG
Christian Couder [Sun, 18 Jan 2009 03:46:09 +0000 (04:46 +0100)]
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>
David Aguilar [Fri, 16 Jan 2009 08:00:02 +0000 (00:00 -0800)]
contrib: add 'git difftool' for launching common merge tools
'git difftool' is a git command that allows you to compare and edit files
between revisions using common merge tools. 'git difftool' does what
'git mergetool' does but its use is for non-merge situations such as
when preparing commits or comparing changes against the index.
It uses the same configuration variables as 'git mergetool' and
provides the same command-line interface as 'git diff'.
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
http-push: when making directories, have a trailing slash in the path name
The function lock_remote() sends MKCOL requests to make leading
directories; However, if it does not put a forward slash '/' at the end of
the path, the server sends a 301 redirect.
By leaving the '/' in place, we can avoid this additional step.
Incidentally, at least one version of Curl (7.16.3) does not resend
credentials when it follows a 301 redirect, so this commit also fixes
a bug.
Original patch by Tay Ray Chuan <rctay89@gmail.com>.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When getting the result of remote_ls(), we were advancing the variable
"path" to the relative path inside the repository.
However, then we went on to malloc a bogus amount of memory: we were
subtracting the prefix length _again_, quite possibly getting something
negative, which xmalloc() interprets as really, really much.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
Stephan Beyer [Fri, 16 Jan 2009 19:40:05 +0000 (20:40 +0100)]
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>
Junio C Hamano [Fri, 16 Jan 2009 02:52:35 +0000 (18:52 -0800)]
Merge branch 'maint'
* maint:
t3404: Add test case for auto-amending only edited commits after "edit"
t3404: Add test case for aborted --continue after "edit"
t3501: check that commits are actually done
Junio C Hamano [Thu, 15 Jan 2009 22:33:54 +0000 (14:33 -0800)]
Merge branch 'maint-1.6.0' into maint
* maint-1.6.0:
t3404: Add test case for auto-amending only edited commits after "edit"
t3404: Add test case for aborted --continue after "edit"
t3501: check that commits are actually done
Stephan Beyer [Thu, 15 Jan 2009 13:03:17 +0000 (14:03 +0100)]
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>
Ted Pavlic [Thu, 15 Jan 2009 16:02:23 +0000 (11:02 -0500)]
bash-completion: Add comments to remind about required arguments
Add a few simple comments above commands that take arguments. These
comments are meant to remind developers of potential problems that
can occur when the script is sourced on systems with "set -u." Any
function which requires arguments really ought to be called with
explicit arguments given.
Also adds a #!bash to the top of bash completions so that editing
software can always identify that the file is of sh type.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ted Pavlic [Thu, 15 Jan 2009 16:02:22 +0000 (11:02 -0500)]
bash-completion: Try bash completions before simple filetype
When a git completion is not found, a bash shell should try bash-type
completions first before going to standard filetype completions. This
patch adds "-o bashdefault" to the completion line. If that option is
not available, it uses the old method.
This behavior was inspired by Mercurial's bash completion script.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ted Pavlic [Thu, 15 Jan 2009 16:02:21 +0000 (11:02 -0500)]
bash-completion: Support running when set -u is enabled
Under "set -u" semantics, it is an error to access undefined variables.
Some user environments may enable this setting in the interactive shell.
In any context where the completion functions access an undefined
variable, accessing a default empty string (aka "${1-}" instead of "$1")
is a reasonable way to code the function, as it silences the undefined
variable error while still supplying an empty string.
In this patch, functions that should always take an argument still use
$1. Functions that have optional arguments use ${1-}.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 15 Jan 2009 06:58:46 +0000 (22:58 -0800)]
Merge branch 'maint'
* maint:
Update draft release notes to 1.6.1.1
Make t3411 executable
fix handling of multiple untracked files for git mv -k
add test cases for "git mv -k"
Michael J Gruber [Wed, 14 Jan 2009 17:03:22 +0000 (18:03 +0100)]
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>
Michael J Gruber [Wed, 14 Jan 2009 17:03:21 +0000 (18:03 +0100)]
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>
Felipe Contreras [Wed, 14 Jan 2009 01:37:07 +0000 (03:37 +0200)]
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>
Junio C Hamano [Tue, 13 Jan 2009 09:13:56 +0000 (01:13 -0800)]
Merge branch 'cb/maint-merge-recursive-fix' into maint
* cb/maint-merge-recursive-fix:
merge-recursive: do not clobber untracked working tree garbage
modify/delete conflict resolution overwrites untracked file
contrib/vim: change URL to point to the latest syntax files
Vim's SVN repository doesn't offer the latest runtime files, since
normally they are only updated there on a release. Though currently
there is no difference between the SVN and HTTP/FTP version of the git
syntax files.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Fri, 2 Jan 2009 22:28:28 +0000 (23:28 +0100)]
rebase -i: learn to rebase root commit
Teach git-rebase -i a new option --root, which instructs it to rebase
the entire history leading up to <branch>. This is mainly for
symmetry with ordinary git-rebase; it cannot be used to edit the root
commit in-place (it requires --onto <newbase>). Commits that already
exist in <newbase> are skipped.
In the normal mode of operation, this is fairly straightforward. We
run cherry-pick in a loop, and cherry-pick has supported picking the
root commit since f95ebf7 (Allow cherry-picking root commits,
2008-07-04).
In --preserve-merges mode, we track the mapping from old to rewritten
commits and use it to update the parent list of each commit. In this
case, we define 'rebase -i -p --root --onto $onto $branch' to rewrite
the parent list of all root commit(s) on $branch to contain $onto
instead.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Mon, 5 Jan 2009 17:35:16 +0000 (18:35 +0100)]
rebase: learn to rebase root commit
Teach git-rebase a new option --root, which instructs it to rebase the
entire history leading up to <branch>. This option must be used with
--onto <newbase>, and causes commits that already exist in <newbase>
to be skipped. (Normal operation skips commits that already exist in
<upstream> instead.)
One possible use-case is with git-svn: suppose you start hacking
(perhaps offline) on a new project, but later notice you want to
commit this work to SVN. You will have to rebase the entire history,
including the root commit, on a (possibly empty) commit coming from
git-svn, to establish a history connection. This previously had to
be done by cherry-picking the root commit manually.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kjetil Barvik [Sun, 11 Jan 2009 18:36:42 +0000 (19:36 +0100)]
Cleanup of unused symcache variable inside diff-lib.c
Commit c40641b77b0274186fd1b327d5dc3246f814aaaf, 'Optimize
symlink/directory detection' by Linus Torvalds, removed the 'char
*symcache' parameter to the has_symlink_leading_path() function. This
made all variables currently named 'symcache' inside diff-lib.c
unnecessary.
This also let us throw away the 'struct oneway_unpack_data', and
instead directly use the 'struct rev_info *revs' member, which
was the only member left after removal of the 'symcache[] array'
member. The 'struct oneway_unpack_data' was introduced by the
following commit:
948dd346 "diff-files: careful when inspecting work tree items"
Impact: cleanup
PATH_MAX bytes less memory stack usage in some cases
Signed-off-by: Kjetil Barvik <barvik@broadpark.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new inline function is_dot_or_dotdot is used to check if the
directory name is either "." or "..". It returns a non-zero value if
the given string is "." or "..". It's applicable to a lot of Git
source code.
Signed-off-by: Alexander Potashev <aspotashev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adeodato Simó [Fri, 9 Jan 2009 17:30:05 +0000 (18:30 +0100)]
t7501-commit.sh: explicitly check that -F prevents invoking the editor
The "--signoff" test case in t7500-commit.sh was setting VISUAL while
using -F -, which indeed tested that the editor is not spawned with -F.
However, having it there was confusing, since there was no obvious reason
to the casual reader for it to be there.
This commits removes the setting of VISUAL from the --signoff test, and
adds in t7501-commit.sh a dedicated test case, where the rest of tests for
-F are.
Signed-off-by: Adeodato Simó <dato@net.com.org.es> Okay-then-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suggest opml.xml as name for OPML view by providing the appropriate
header, consistently with similar usage in project_index view.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 10 Jan 2009 20:41:33 +0000 (12:41 -0800)]
format-patch: show patch text for the root commit
Even without --root specified, if the range given on the command line
happens to include a root commit, we should include its patch text in the
output.
This fix deliberately ignores log.showroot configuration variable because
"format-patch" and "log -p" can and should behave differently in this
case, as the former is about exporting a part of your history in a form
that is replayable elsewhere and just giving the commit log message
without the patch text does not make any sense for that purpose.
Noticed and fix originally attempted by Nathan W. Panike; credit goes to
Alexander Potashev for injecting sanity to my initial (broken) fix that
used the value from log.showroot configuration, which was misguided.
Lee Marlow [Wed, 10 Dec 2008 19:39:18 +0000 (12:39 -0700)]
bash completion: Use 'git add' completions for 'git stage'
Signed-off-by: Lee Marlow <lee.marlow@gmail.com> Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lee Marlow [Wed, 10 Dec 2008 19:39:17 +0000 (12:39 -0700)]
bash completion: Add '--intent-to-add' long option for 'git add'
Signed-off-by: Lee Marlow <lee.marlow@gmail.com> Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pierre Habouzit [Fri, 31 Oct 2008 09:12:21 +0000 (10:12 +0100)]
filter-branch: add git_commit_non_empty_tree and --prune-empty.
git_commit_non_empty_tree is added to the functions that can be run from
commit filters. Its effect is to commit only commits actually touching the
tree and that are not merge points either.
The option --prune-empty is added. It defaults the commit-filter to
'git_commit_non_empty_tree "$@"', and can be used with any other
combination of filters, except --commit-hook that must used
'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
usually to achieve the same result.
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 10 Jan 2009 06:21:36 +0000 (22:21 -0800)]
Resurrect "git apply --flags -" to read from the standard input
The previous "parse-opt"ification broke git-apply reading from the
standard input. "git apply A - C <B" is supposed to read patches from
files A, B and C in this order.
Before "parse-opt"ification, we used be able to:
git apply --stat - --apply <A B
to read the patch from file A, showing only the diffstat, and then read the
patch from file B, showing the diffstat and actually applying it. Even
with this fix we cannot do that anymore, but that is so crazy use case I
do not think anybody sane relied on such a broken behaviour.
René Scharfe [Fri, 9 Jan 2009 23:18:34 +0000 (00:18 +0100)]
grep: don't call regexec() for fixed strings
Add the new flag "fixed" to struct grep_pat and set it if the pattern
is doesn't contain any regex control characters in addition to if the
flag -F/--fixed-strings was specified.
This gives a nice speed up on msysgit, where regexec() seems to be
extra slow. Before (best of five runs):
$ time git grep grep v1.6.1 >/dev/null
real 0m0.552s
user 0m0.000s
sys 0m0.000s
$ time git grep -F grep v1.6.1 >/dev/null
real 0m0.170s
user 0m0.000s
sys 0m0.015s
With the patch:
$ time git grep grep v1.6.1 >/dev/null
real 0m0.173s
user 0m0.000s
sys 0m0.000s
The difference is much smaller on Linux, but still measurable.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Scharfe [Fri, 9 Jan 2009 23:08:40 +0000 (00:08 +0100)]
grep -w: forward to next possible position after rejected match
grep -w accepts matches between non-word characters, only. If a match
from regexec() doesn't meet this criteria, grep continues its search
after the first character of that match.
We can be a bit smarter here and skip all positions that follow a word
character first, as they can't match our criteria. This way we can
consume characters quite cheaply and don't need to special-case the
handling of the beginning of a line.
Here's a contrived example command on msysgit (best of five runs):
$ time git grep -w ...... v1.6.1 >/dev/null
real 0m1.611s
user 0m0.000s
sys 0m0.015s
With the patch it's quite a bit faster:
$ time git grep -w ...... v1.6.1 >/dev/null
real 0m1.179s
user 0m0.000s
sys 0m0.015s
More common search patterns will gain a lot less, but it's a nice clean
up anyway.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit: color status output when color.ui is set
When using "git commit" and there was nothing to commit (the editor
wasn't launched), the status output wasn't colored, even though color.ui
was set. Only when setting color.status it worked.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / git.git / log