Cloning/initializing svn repositories with an uncanonicalize url
does not work as libsvn throws an assertion. This patch
canonicalize svn uris for the clone and init command from
git-svn.
[ew: fixed trailing whitespace]
Signed-off-by: Ulrich Dangel <uli@spamt.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Marc Branchaud wrote:
> I'm fairly happy with this, except for the way the branch
> subcommand matches refspecs. The patch does a simple string
> comparison, but it'd be better to do an actual glob. I just
> couldn't track down the right function for that, so I left it as
> a strcmp and hope that a gitizen can tell me how to glob here.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This enables git-svn.perl to read multiple 'branches' and 'tags' entries in
svn-remote config sections. The init and clone subcommands also support
multiple --branches and --tags arguments.
The branch (and tag) subcommand gets a new argument: --destination (or -d).
This argument is required if there are multiple branches (or tags) entries
configured for the remote Subversion repository. The argument's value
specifies which branch (or tag) path to use to create the branch (or tag).
The specified value must match the left side (without wildcards) of one of
the branches (or tags) refspecs in the svn-remote's config.
[ew: avoided explicit loop when combining globs with "push"]
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Add a command to unwind the effects of fetch by moving the rev_map
and refs/remotes/git-svn back to an old SVN revision. This allows
revisions to be re-fetched. Ideally SVN revs would be immutable,
but permissions changes in the SVN repository or indiscriminate use
of '--ignore-paths' can create situations where fetch cannot make
progress.
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
By limiting start revision of find_rev_before to max existing
revision. This avoids a long wait if you do
'git svn reset -r 9999999'. The linear search within the
contiguous revisions doesn't seem to be a problem.
[ew: expanded commit message]
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously there was no explicit 'help' command, but 'git svn help'
still printed the usage message (as an invalid command), provided you
got past the initialization steps that required a valid repo.
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
'git svn dcommit' takes an optional revision argument, but the meaning
of it was rather scary. It completely ignored the current state of
the HEAD, only looking at the revisions between SVN and $rev. If HEAD
was attached to $branch, the branch lost all commits $rev..$branch in
the process.
Considering that 'git svn dcommit HEAD^' has the intuitive meaning
"dcommit all changes on my branch except the last one", we change the
meaning of the revision argument. git-svn temporarily checks out $rev
for its work, meaning that
* if a branch is specified, that branch (_not_ the HEAD) is rebased as
part of the dcommit,
* if some other revision is specified, as in the example, all work
happens on a detached HEAD and no branch is affected.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
...without i18n.commitencoding set in the config.
SVN tries to store all commit messages in UTF-8, however it is
up to the job of the clients to enforce this rule. SVN servers
themselves do not always enforce this; allowing clients to
commit malformed UTF-8 messages and break repositories.
So git-svn will enforce this and tell the user to set
i18n.commitencoding when a git commit is is not in UTF-8.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Add a new option, --authors-prog, to git-svn that allows a more flexible
alternative (or supplement) to --authors-file. This allows more
advanced username operations than the authors file will allow. For
example, one may look up Subversion users via LDAP, or may generate the
name and email address from the Subversion username.
Notes:
* If both --authors-name and --authors-prog are given, the former is
tried first, falling back to the later.
* The program is called once per unique SVN username, and the result is
cached.
* The command-line argument must be the path to a program, not a generic
shell command line. The absolute path to this program is taken at
startup since the git-svn script changes directory during operation.
* The option is not enabled for `git svn log'.
[ew: fixed case where neither --authors-(name|prog) were defined]
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Report the maximum found revision in the range, instead of the minimum
changed revision.
Signed-off-by: Alex Vandiver <alexmv@mit.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Instead of trying to find the end of the commit history only in the
last window, track if we have seen commits yet, and use that to judge
if we need to backtrack and look for a tail. Otherwise, conversion
can silently lose up to 100 revisions of a branch if it was deleted
>100 revisions ago.
Signed-off-by: Alex Vandiver <alexmv@mit.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
* maint:
improve error message in config.c
t4018-diff-funcname: add cpp xfuncname pattern to syntax test
Work around BSD whose typeof(tv.tv_sec) != time_t
git-am.txt: reword extra headers in message body
git-am.txt: Use date or value instead of time or timestamp
git-am.txt: add an 'a', say what 'it' is, simplify a sentence
dir.c: Fix two minor grammatical errors in comments
git-svn: fix a sloppy Getopt::Long usage
Getopt-Long v2.38 is much stricter about sloppy getopt usage. The
trailing pipe causes git-svn testcases to fail for all of the --stdin
argument calls.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It has been reported time and time again in relation to msysGit that
git-svn does not work well when core.autocrlf has any value other than
'false'. So let's make it so by default.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --ignored-paths argument is now stored as
"svn-remote.$REMOTE_NAME.ignore-paths" in the config file.
[ew: edited subject and message]
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
The --ignore-paths option to fetch is very useful for working on a subset
of a SVN repository. For proper operation, every command that causes a
fetch (explicit or implied) must include a matching --ignore-paths option.
This patch adds a persistent svn-remote.$repo_id.ignore-paths config by
promoting Fetcher::is_path_ignored to a member function and initializing
$self->{ignore_regex} in Fetcher::new. Command line --ignore-paths is
still recognized and acts in addition to the config value.
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
'git svn blame' now uses the 'git cat-file --batch' command to
speed up resolving SVN revision number out of commit SHA by
removing fork+exec overhead.
[ew: enforced 80-column line wrap]
Signed-off-by: Boris Byk <boris.byk@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
People may expect/prefer -q to still show git commits,
so this change allows a second -q to hide them.
Signed-off-by: Michael Poole <mdpoole@troilus.org>
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Acked-by: Eric Wong <normalperson@yhbt.net>
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
Thanks to Anton Gyllenberg for pointing me toward the
Twisted repository as a real-world example of this case.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ideally only errors should be output in this mode so fetch
can be run from cron and normally produce no output. Without
this change it would output a single line on each git commit,
e.g.
r1909 = 32ef87860662526d4a62f903949ed21e0341079e (u2_10_12_branch)
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Acked-by: Eric Wong <normalperson@yhbt.net>
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
Thanks to Anton Gyllenberg for pointing me toward the
Twisted repository as a real-world example of this case.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
For repositories laid out like the following:
[svn-remote "svn"]
url = http://foo.com/svn/repos/bar
fetch = myproject/trunk:refs/remotes/trunk
branches = bar/myproject/branches/*:refs/remotes/*
tags = bar/myproject/tags/*:refs/remotes/tags/*
The "bar" component above is considered the intermediate path
and was not handled correctly.
Signed-off-by: Michael Lai <myllai@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When %z was removed from the strftime call and subsituted with a
local gmt offset calculation, time() was no longer the default for
all time functions as it was with the previous localtime(shift).
This is now corrected so that format_svn_time behaves as it used to.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though this will break things for some extremely rare repositories
used by broken Windows clients, it's probably not worth enabling this by
default as it has negatively affected many more users than it has helped
from what we've seen so far.
The extremely rare repositories that have broken symlinks in them will be
silently corrupted in import; but users can still reenable this option and
restart the import.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
%z isn't available on all platforms in the date formatting
routines. Provide a workalike capability that should be
more portable.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Acked-by: Eric Wong <normalperson@yhbt.net>
The commit url for dcommit is determined in the following order:
commandline option --commit-url
svn.commiturl
svn-remote.<name>.commiturl
svn-remote.<name>.url
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Original bug report and test case by Björn Steinbrink.
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Hi Eric,
>
> seems that the empty symlink stuff gets confused about which revision to
> use when looking for the parent's file.
>
> r3 = f1a6fcf6b0a1c4a373d0b2b65a3d70700084f361 (tags/1.0.1)
> Found possible branch point: file:///home/doener/h/svn/tags/1.0 => file:///home/doener/h/svn/branches/1.0, 4
> Found branch parent: (1.0) 63ae640ba01014ecbb3df590999ed1fa5914545b
> Following parent with do_switch
> Successfully followed parent
> r5 = 26fcfef5bcced97ab74faf1af7341a2ae0d272aa (1.0)
> Found possible branch point: file:///home/doener/h/svn/branches/1.0 => file:///home/doener/h/svn/tags/1.0.1, 5
> Found branch parent: (tags/1.0.1) 26fcfef5bcced97ab74faf1af7341a2ae0d272aa
> Following parent with do_switch
> Scanning for empty symlinks, this may take a while if you have many empty files
> You may disable this with `git config svn.brokenSymlinkWorkaround false'.
> This may be done in a different terminal without restarting git svn
> Filesystem has no item: File not found: revision 3, path '/branches/1.0/file' at /usr/local/libexec/git-core/git-svn line 3318
>
> Note how it tries to look at revision 3 instead of revision 5 (which it
> correctly detected as the parent). The import succeeds when
> svn.brokenSymlinkWorkaround is set to false. Testcase below.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since SVN tracks empty directories and git does not, we can not assume
that the directory exists when creating .gitignore files.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Ward Wouts reports that git-svn barfed like this:
Unable to parse date: 2004-03-09T09:44:33.Z at /usr/bin/git-svn line 3995
The parse_svn_date sub expects there always are one or more digits after
the decimal point to record fractional seconds, but this example does not
and results in a failure like this.
The fix is based on the original fix by the reporter, further cleaned up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
If the new svn root URL given with the svn-remote.<repo>.rewriteRoot config option
(or by the --rewrite-root option to 'git svn init') contains a username
(such as 'svn+ssh://username@example.com/repo'), find_by_url() cannot find
the repository URL, because the URL contained in the commit message does have
the username removed.
Signed-off-by: Dévai Tamás <devait@mailbox.sk>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
This will be useful when somebody want to checkout something partially from
repository with some non-standart layout or exclude some files from it.
Example: repository has structure /module-{a,b,c}/{trunk,branches,tags}/...
Modules are interdependent, and you want it to be single repostory (to commit
to all modules simultaneously and view complete history), but do not want
branches and tags be checked out into working copy.
Other use case is excluding some large blobs.
The quirk for now is that user must specify this option every fetch/rebase;
in other case he may get extra files or "file not found" errors. It may be
will be resolved by adding regular expression to .git/config into
[svn-remote ...] to make it persistent.
Signed-off-by: Vitaly "_Vi" Shukela <public_vi@tut.by>
Acked-by: Eric Wong <normalperson@yhbt.net>
[ew: replaced 4-space indent with tabs]
[ew: prefixed $ignore_regex with an underscore to be consistent
with other globals in git-svn]
[ew: rearranged functions to minimize diff and removed prototype
usage to be consistent with the rest of git-svn (and other
Perl code in git (and they're ugly to me)]
By enforcing SVN::Pool usage when calling get_file once again.
This regression was introduced with the reintroduction of
SVN::Ra::get_file() usage in
dbc6c74d08
Signed-off-by: Eric Wong <normalperson@yhbt.net>
In svn 1.5.5 the output of "svn info" for added directories was changed
and now shows the repository UUID. This patch implements the same
behavior for "git svn info" and makes t9119-git-svn-info.17 pass if
svn 1.5.5 is used.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Some SVN repositories contain git repositories within them
(hopefully accidentally checked in). Since git refuses to track
nested ".git" repositories, this can be a problem when fetching
updates from SVN.
Thanks to Morgan Christiansson for the report and testing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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.
Thanks to Tom G. Christensen for the bug report.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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>
This is a followup to 7fc35e0e94,
(workaround a for broken symlinks in SVN).
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
Signed-off-by: Eric Wong <normalperson@yhbt.net>
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.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn. If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated. This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.
To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history. If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'branch' subcommand incorrectly had the svn-remote to use hardcoded
as 'svn', the default remote name. This meant that branches derived
from other svn-remotes would try to use the branch and tag configuration
for the 'svn' remote, potentially copying would-be branches to the wrong
place in SVN, into the branch namespace for another project.
Fix this by using the remote name extracted from the svn info for the
specified git ref. Add a testcase for this behaviour.
[jc: squashed in a fix to test from Michael J Gruber for older svn (1.4)]
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes git-svn within msys where Perl will provide temporary files with path
such as /tmp while the git suit expects native Windows paths.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
