- 19 2月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com> Acked-by: NEric Wong <normalperson@yhbt.net>
-
- 16 2月, 2009 1 次提交
-
-
由 Dévai Tamás 提交于
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: NDévai Tamás <devait@mailbox.sk> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 2月, 2009 4 次提交
-
-
由 Eric Wong 提交于
Thanks to Anton Gyllenberg <anton@iki.fi> for the bug report (and testcase in the following commit): > Commit dbc6c74d "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: NEric Wong <normalperson@yhbt.net>
-
由 Deskin Miller 提交于
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: NDeskin Miller <deskinm@umich.edu>
-
由 Sam Vilain 提交于
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: NYuval Kogman <nothingmuch@woobling.org> Signed-off-by: NSam Vilain <sam@vilain.net> Acked-by: NEric Wong <normalperson@yhbt.net> [ew: minor formatting changes]
-
由 Eric Wong 提交于
Since dbc6c74d, 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: NEric Wong <normalperson@yhbt.net>
-
- 26 1月, 2009 2 次提交
-
-
由 Vitaly \"_Vi\" Shukela 提交于
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: NVitaly "_Vi" Shukela <public_vi@tut.by> Acked-by: NEric 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)]
-
由 Eric Wong 提交于
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 dbc6c74dSigned-off-by: NEric Wong <normalperson@yhbt.net>
-
- 19 1月, 2009 6 次提交
-
-
由 Marcel Koeppen 提交于
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: NMarcel Koeppen <git-dev@marzelpan.de> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
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: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
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: NEric Wong <normalperson@yhbt.net>
-
由 Pete Harlan 提交于
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: NPete Harlan <pgit@pcharlan.com> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
This is a followup to 7fc35e0e, (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=2692Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
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: NEric Wong <normalperson@yhbt.net>
-
- 15 12月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 12月, 2008 1 次提交
-
-
由 Deskin Miller 提交于
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: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 12月, 2008 1 次提交
-
-
由 Deskin Miller 提交于
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: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 11月, 2008 4 次提交
-
-
由 Marten Svanfeldt (dev) 提交于
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: NMarten Svanfeldt <developer@svanfeldt.com> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Deskin Miller 提交于
When in a bare repository (or .git, for that matter), git-svn would fail to initialise properly, since git rev-parse --show-cdup would not output anything. However, git rev-parse --show-cdup actually returns an error code if it's really not in a git directory. Fix the issue by checking for an explicit error from git rev-parse, and setting $git_dir appropriately if instead it just does not output. Signed-off-by: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
SVN itself always stores log messages in the repository as UTF-8. git always stores/retrieves everything as raw binary data with no transformations whatsoever. To interact with SVN, we need to encode log messages as UTF-8 before sending them to SVN, as SVN cannot do it for us. When retrieving log messages from SVN, we also need to (attempt to) reencode the UTF-8 log message back to the user-specified commit encoding. Note, handling i18n.logoutputencoding for "git svn log" also needs to be done in a future change. Also, this change only deals with the encoding of commit messages and nothing else (path names, blob content, ...). In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com> James North <tocapicha@gmail.com> wrote: > Hi, > > I'm using git-svn on a system with ISO-8859-1 encoding. The problem is > when I try to use "git svn dcommit" to send changes to a remote svn > (also ISO-8859-1). > > Seems like git-svn is sending commit messages with utf-8 (just a > guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a > de cami?\243n" > > I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the > warning when doing "git svn dcommit" but messages still are sent with > wrong encoding. Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
Thanks to Jose Carlos Garcia Sogo and Björn Steinbrink for the bug report. On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote: > Hi, > > Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this > svn repo fails for him: > https://sucs.org/~welshbyte/svn/backuptool/trunk > > I can reproduce that here with: > git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1) > > The error message I get is: > Apache got a malformed URI: Unusable URI: it does not refer to this > repository at /usr/local/libexec/git-core/git-svn line 4057 > > strace revealed that git-svn url-encodes ~ while svn does not do that. > > For svn we have: > write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\"> > <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>... > > While git-svn shows: > write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\"> > <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>... Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
- 06 11月, 2008 3 次提交
-
-
由 Deskin Miller 提交于
When in a bare repository (or .git, for that matter), git-svn would fail to initialise properly, since git rev-parse --show-cdup would not output anything. However, git rev-parse --show-cdup actually returns an error code if it's really not in a git directory. Fix the issue by checking for an explicit error from git rev-parse, and setting $git_dir appropriately if instead it just does not output. Signed-off-by: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
SVN itself always stores log messages in the repository as UTF-8. git always stores/retrieves everything as raw binary data with no transformations whatsoever. To interact with SVN, we need to encode log messages as UTF-8 before sending them to SVN, as SVN cannot do it for us. When retrieving log messages from SVN, we also need to (attempt to) reencode the UTF-8 log message back to the user-specified commit encoding. Note, handling i18n.logoutputencoding for "git svn log" also needs to be done in a future change. Also, this change only deals with the encoding of commit messages and nothing else (path names, blob content, ...). In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com> James North <tocapicha@gmail.com> wrote: > Hi, > > I'm using git-svn on a system with ISO-8859-1 encoding. The problem is > when I try to use "git svn dcommit" to send changes to a remote svn > (also ISO-8859-1). > > Seems like git-svn is sending commit messages with utf-8 (just a > guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a > de cami?\243n" > > I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the > warning when doing "git svn dcommit" but messages still are sent with > wrong encoding. Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
Thanks to Jose Carlos Garcia Sogo and Björn Steinbrink for the bug report. On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote: > Hi, > > Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this > svn repo fails for him: > https://sucs.org/~welshbyte/svn/backuptool/trunk > > I can reproduce that here with: > git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1) > > The error message I get is: > Apache got a malformed URI: Unusable URI: it does not refer to this > repository at /usr/local/libexec/git-core/git-svn line 4057 > > strace revealed that git-svn url-encodes ~ while svn does not do that. > > For svn we have: > write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\"> > <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>... > > While git-svn shows: > write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\"> > <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>... Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
- 31 10月, 2008 1 次提交
-
-
由 Deskin Miller 提交于
Signed-off-by: NDeskin Miller <deskinm@umich.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 10月, 2008 1 次提交
-
-
由 Deskin Miller 提交于
Signed-off-by: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 10月, 2008 1 次提交
-
-
由 Florian Ragwitz 提交于
[ew: fixed a warning to stderr causing t9108 to fail] Signed-off-by: NFlorian Ragwitz <rafl@debian.org> Signed-off-by: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 01 10月, 2008 1 次提交
-
-
由 Luc Heinrich 提交于
When doing a set-tree and there is no revision to commit to, the following unrelated error message is displayed: "Undefined subroutine &Git::SVN::fatal called at /opt/local/libexec/git-core/git-svn line 2575." The following patch fixes the problem and allows the real error message to be shown. Signed-off-by: NLuc Heinrich <luc@honk-honk.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 22 9月, 2008 1 次提交
-
-
由 Deskin Miller 提交于
Suppose you're using git-svn to work with a certain SVN repository. Since you don't like 'git-svn fetch' to take forever, and you don't want to accidentally interrupt it and end up corrupting your repository, you set up a remote Git repository to mirror the SVN repository, which does its own 'git-svn fetch' on a cronjob; now you can 'git-fetch' from the Git mirror into your local repository, and still dcommit to SVN when you have changes to push. After you do this, though, git-svn will get very confused if you ever try to do 'git-svn fetch' in your local repository again, since its rev_map will differ from the branch's head, and it will be unable to fetch new commits from SVN because of the metadata conflict. But all the necessary metadata are there in the Git commit message; git-svn already knows how to rebuild rev_map files that get blown away, by using the metadata. This patch teaches git-svn do a partial rebuild of the rev_map to match the true state of the branch, if it ever is used to fetch again. This will only work for projects not using either noMetadata or useSvmProps configuration options; if you are using these options, git-svn will fall back to the previous behaviour. Signed-off-by: NDeskin Miller <deskinm@umich.edu> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 9月, 2008 2 次提交
-
-
由 Eric Wong 提交于
Apparently do_switch() tolerates the lack of escaping in less funky branch names. For the really strange and scary ones, we need to escape them properly. It strangely maintains compatible with the existing handling of branch names with spaces and exclamation marks. Reported-by: m.skoric@web.de ($gmane/94677) Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Alec Berryman 提交于
Not doing so caused the "Malformed network data" error when a directoy was deleted and replaced with a copy from an older version. Signed-off-by: NAlec Berryman <alec@thened.net> Acked-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 9月, 2008 2 次提交
-
-
由 Marcus Griep 提交于
Signed-off-by: NMarcus Griep <marcus@griep.us> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Marcus Griep 提交于
Perl 5.8.0 ships with File::Temp 0.13, which does not have the new() interface introduced in 0.14, as pointed out by Tom G. Christensen. This modifies Git.pm to use the more established tempfile() interface and updates 'git svn' to match. Signed-off-by: NMarcus Griep <marcus@griep.us> Acked-by: NEric Wong <normalperson@yhbt.net> Tested-by: NTom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 9月, 2008 2 次提交
-
-
由 Eric Wong 提交于
Apparently do_switch() tolerates the lack of escaping in less funky branch names. For the really strange and scary ones, we need to escape them properly. It strangely maintains compatible with the existing handling of branch names with spaces and exclamation marks. Reported-by: m.skoric@web.de ($gmane/94677) Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
由 Paul Talacko 提交于
Patch-by: Paul Talacko <gnuruandstuff@yahoo.co.uk>: <http://article.gmane.org/gmane.comp.version-control.git/95006> > Hello, > > There's an issue in git-svn as autoprops are not applied to > renamed files, only to added files. > > This patch fixes the bug. [ew: added test case] Signed-off-by: NEric Wong <normalperson@yhbt.net>
-
- 06 9月, 2008 5 次提交
-
-
由 Thomas Rast 提交于
Previously 'git svn info unknown-file' only announced its failure (in the SVN 1.4 style, "not a versioned resource"), and exited successfully. It is desirable to actually exit with failure, so change the code to exit(1) under this condition. Since that is already halfway SVN 1.5 compatibility, also change the error output to match 1.5. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Thomas Rast 提交于
Changes 'git svn info' to always URL-escape the 'URL' and 'Repository' fields and --url output, like SVN (at least 1.5) does. Note that reusing the escape_url() further down in Git::SVN::Ra is not possible because it only triggers for http(s) URLs. I did not know whether extending it to all schemes would break SVN access anywhere, so I made a new one that quotes in all schemes. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Thomas Rast 提交于
Previously 'git svn info <path>' would always treat the <path> as relative to the working directory root, with a default of ".". This does not match the behaviour of 'svn info'. Prepend $(git rev-parse --show-prefix) to the path used inside cmd_info to make it relative to the current working directory. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Thomas Rast 提交于
Since 711521e2 'git svn dcommit' attempts to use the upstream information to determine the SVN URL, before it verifies that it even found an upstream. Move up the corresponding check. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Acked-by: NEric Wong <normalperson@yhbt.net>
-
由 Eric Wong 提交于
Not checking the error code of a function used to transform and send data makes me nervous. It currently returns "undef" on success; so die if we get any result other than "undef" because it's likely something went wrong somewhere. I really wish this function returned an MD5 like send_stream (or better yet, SHA1) for verification. Signed-off-by: NEric Wong <normalperson@yhbt.net>
-