Commit dbc6c74d08 "git-svn: handle empty
files marked as symlinks in SVN" caused a regression in an unusual case
where a branch has been created in SVN, later deleted and then created
again from another branch point and the original branch point had empty
files not in the new branch. In some cases git svn fetch will then fail
while trying to fetch the empty file from the wrong SVN revision.
This adds a test case that reproduces the issue.
[ew: added additional test to ensure file was created correctly
made test file executable ]
Signed-off-by: Anton Gyllenberg <anton@iki.fi>
Acked-by: Eric Wong <normalperson@yhbt.net>
Thanks to Anton Gyllenberg <anton@iki.fi> for the bug report
(and testcase in the following commit):
> Commit dbc6c74d08 "git-svn:
> handle empty files marked as symlinks in SVN" caused a
> regression in an unusual case where a branch has been created
> in SVN, later deleted and then created again from another
> branch point and the original branch point had empty files not
> in the new branch. In some cases git svn fetch will then fail
> while trying to fetch the empty file from the wrong SVN
> revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When initializing a git-svn repository from a Subversion repoository,
it is common to be interested in a path which did not exist in the
initial commit to Subversion. In a large repository, the initial fetch
may take some looking for the earliest existence of the path time while
the user receives no additional feedback. Print the highest revision
number scanned thus far to let the user know something is still
happening.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
We will be adding a more places that need to find git revisions
corresponding to new parents, so abstract out this section into a new
method.
Signed-off-by: Yuval Kogman <nothingmuch@woobling.org>
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
[ew: minor formatting changes]
Since dbc6c74d08, git-svn has had
an expensive check for broken symlinks that exist in some
repositories. This leads to a heavy performance hit on
repositories with many empty blobs that are not supposed to be
symlinks.
The workaround is enabled by default; and may be disabled via:
git config svn.brokenSymlinkWorkaround false
Reported by Markus Heidelberg.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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>
This is a companion patch to the recent 3d95d92 (receive-pack: explain
what to do when push updates the current branch, 2009-01-31).
Deleting the current branch from a remote will result in the next clone
from it not check out anything, among other things. It also is one of the
cause that makes remotes/origin/HEAD a dangling symbolic ref. This patch
still allows the traditional behaviour but with a big warning, and promises
that the default will change to 'refuse' in a future release.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous one squelched the diagnositic message we used to issue every
time we enumerated the refs and noticed a dangling ref. This adds the
warning back to the place where the user actually attempts to use it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you prune from the remote "frotz" that deleted the ref your tracking
branch remotes/frotz/HEAD points at, the symbolic ref will become
dangling. We used to detect this as an error condition and issued a
message every time refs are enumerated.
This stops the error message, but moves the warning to "remote prune".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
026fa0d (Move computation of absolute paths from Makefile to runtime in
preparation for RUNTIME_PREFIX, 2009-01-18) broke the installation of html
documentation. A relative htmldir is given to Documentation/Makefile and
html documentations are installed in a subdirectory of "Documentation" in
the source tree.
Fix this by not exporting htmldir from Makefile; this allows
Documentation/Makefile to compute the htmldir from the prefix.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index_is_dirty() in builtin-revert.c checks if the index is dirty.
This patch generalizes this function to check if the index differs
from a revision, i.e. the former index_is_dirty() behavior can now be
achieved by index_differs_from("HEAD", 0).
The second argument "diff_flags" allows to set further diff option
flags like DIFF_OPT_IGNORE_SUBMODULES. See DIFF_OPT_* macros in diff.h
for a list.
index_differs_from() seems to be useful for more than builtin-revert.c,
so it is moved into diff-lib.c and also used in builtin-commit.c.
Yet to mention:
- "rev.abbrev = 0;" can be safely removed.
This has no impact on performance or functioning of neither
setup_revisions() nor run_diff_index().
- rev.pending.objects is free()d because this fixes a leak.
(Also see 295dd2ad "Fix memory leak in traverse_commit_list")
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some filenames in the Makefile got out of order.
This patch resorts the filename lists which makes it easier
to grasp that it is sorted and that this should be kept.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many tests checked for failure by hand without using test_must_fail (they
probably predate the shell function).
When we know the desired outcome, explicitly check for it, instead of
checking if the result does not match one possible incorrect outcome.
E.g. if you expect a push to be refused, you do not test if the result is
different from what was pushed. Instead, make sure that the ref did not
before and after the push.
The test sequence chdir'ed around and any failure at one point could have
started the next test in an unexpected directory. Fix this problem by
using subshells as necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-1.6.0-path-normalize:
Remove unused normalize_absolute_path()
Test and fix normalize_path_copy()
Fix GIT_CEILING_DIRECTORIES on Windows
Move sanitary_path_copy() to path.c and rename it to normalize_path_copy()
Make test-path-utils more robust against incorrect use
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>
The previous check in git-web--browse for /bin/start used test -n
/bin/start, which was always true. This lead to "start" being tried
first in the browser list. On systems with upstart installed, "start"
exists and might be in the PATH, but it makes a poor choice for a web
browser. Instead, test that /bin/start exists and is executable.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a gitweb configuration variable $prevent_xss that disables features
to prevent content in repositories from launching cross-site scripting
(XSS) attacks in the gitweb domain. Currently, this option makes gitweb
ignore README.html (a better solution may be worked out in the future)
and serve a blob_plain file of an untrusted type with
"Content-Disposition: attachment", which tells the browser not to show
the file at its original URL.
The XSS prevention is currently off by default.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although it does not matter in general it is handled different by
"git clone", as it removes it to make the "humanish" name of the
new repository.
Signed-off-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After invoking git add -p I always got the warnings:
Use of uninitialized value $_[3] in exec at Git.pm line 1282.
Use of uninitialized value $args[2] in join or string at Git.pm line 1264.
A bisect showed that these warnings occur in a301973 "add -p: print errors
in separate color" the first time.
They can be reproduced by setting color.ui (or color.interactive) to "auto"
and unsetting color.interactive.help and color.interactive.error.
I am using Perl 5.10.0.
The reason of the warning is that color.interactive.error defaults to
color.interactive.help which defaults to nothing in the specific codepath.
It defaults to 'red bold' some lines above which could lead to the wrong
assumption that it always defaults to 'red bold' now.
This patch lets it default to 'red bold', blowing the warnings away.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Acked-By: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The idea was originated by discussion about usability of manually
editing the config file in 'special needs' systems such as Windows. Now
the user can forget a bit about where the config files actually are.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before d467a52 ("Make '--decorate' set an explicit 'show_decorations'
flag", Nov 3 2008), commit decorations were shown whenever they exist, and
distances stored in them by "git rev-list --bisect-all" were automatically
shown. d467a52 changed the rule so that commit decorations are not shown
unless rev_info explicitly asks to, with its show_decorations bit, but
forgot that the ones "git rev-list --bisect-all" adds need to be shown.
This patch fixes this old breakage.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Include it directly from git-shortlog.txt, and refer
to it from pretty-format.txt.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
map_user() allows to lookup and replace both email and
name of a user, based on a new style mailmap file.
The possible mailmap definitions are now:
proper_name <commit_email> # Old style
<proper_email> <commit_email> # New style
proper_name <proper_email> <commit_email> # New style
proper_name <proper_email> commit_name <commit_email> # New style
map_email() operates the same as before, with the
exception that it also will to try to match on a name
passed in through the name return buffer.
clear_mailmap() is needed to now clear the more complex
mailmap structure.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
string_list_find_insert_index() and string_list_insert_at_index()
enables you to see if an item is in the string_list, and to
insert at the appropriate index in the list, if not there.
This is usefull if you need to manipulate an existing item,
if present, and insert a new item if not.
Future mailmap code will use this construct to enable
complex (old_name, old_email) -> (new_name, new_email)
lookups.
The string_list_clear_func() allows to call a custom
cleanup function on each item in a string_list, which is
useful is the util member points to a complex structure.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows us to augment the repo mailmap file, and to use
mailmap files elsewhere than the repository root. Meaning
that the entries in mailmap.file will override the entries
in "./.mailmap", should they match.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
to match word boundary at the beginning and the end. This way we
reduce number of false matches, for example we now don't match
0x74a5cd01 which is hex decimal (for example memory address),
but is not SHA-1.
Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, when you called
git submodule some/bogus/path
Git would silently ignore the path, without warning the user about the
likely mistake. Now it does.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tab completion makes it easy to add a trailing slash to a submodule path.
As it is completely clear what the user actually wanted to say, be nice
and strip that slash at the end.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function is now superseded by normalize_path_copy().
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes the test-path-utils utility to invoke normalize_path_copy()
instead of normalize_absolute_path() because the latter is about to be
removed.
The test cases in t0060 are adjusted in two regards:
- normalize_path_copy() more often leaves a trailing slash in the result.
This has no negative side effects because the new user of this function,
longest_ancester_length(), already accounts for this behavior.
- The function can fail.
The tests uncover a flaw in normalize_path_copy(): If there are
sufficiently many '..' path components so that the root is reached, such as
in "/d1/s1/../../d2", then the leading slash was lost. This manifested
itself that (assuming there is a repository at /tmp/foo)
$ git add /d1/../tmp/foo/some-file
reported 'pathspec is outside repository'. This is now fixed.
Moreover, the test case descriptions of t0060 now include the test data and
expected outcome.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using git with GIT_CEILING_DIRECTORIES crashed on Windows due to a failed
assertion in normalize_absolute_path(): This function expects absolute
paths to start with a slash, while on Windows they can start with a drive
letter or a backslash.
This fixes it by using the alternative, normalize_path_copy() instead,
which can handle Windows-style paths just fine.
Secondly, the portability macro PATH_SEP is used instead of expecting
colons to be used as path list delimiter.
The test script t1504 is also changed to help MSYS's bash recognize some
program arguments as path list. (MSYS's bash must translate POSIX-style
path lists to Windows-style path lists, and the heuristic did not catch
some cases.)
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function and normalize_absolute_path() do almost the same thing. The
former already works on Windows, but the latter crashes.
In subsequent changes we will remove normalize_absolute_path(). Here we
make the replacement function reusable. On the way we rename it to reflect
that it does some path normalization. Apart from that this is only moving
around code.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
