Many functions and operators in perl set $_, so its value cannot be relied upon
after calling arbitrary functions. The solution is simply to copy the value of
$_ into a local variable that will not get overwritten.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git only tracks the histories of full directories, not
that of individual files. Sometimes, SVN users will
place[1] a regular file in the directory designated
for subdirectories of branches or tags.
Thanks to jrockway on #git for pointing this out.
[1] mistakenly or otherwise, such as a README
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These are harmless but annoying. They were introduced in
512b620bd9
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When an explicit --revision argument is specified, do not fetch
past the specified range into the beginning of history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This bug has been around since the the conversion to use the
Git.pm library back in October or November. Eventually I'd like
"git rev-list/log" to have the option to not truncate overly
long messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When patches are merged from another git-svn managed branch,
they will have the git-svn-id: metadata line in them (generated
by git-format-patch).
When doing rebase or dcommit via git-svn, this would cause
git-svn to find the wrong upstream branch. We now verify
that the commit is consistent with the value in the .rev_db
file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.
Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we're on an invalid HEAD, we should detect this and avoid
attempting to continue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We ignore errors if the path we're tracking did not exist for
a particular revision range, but we still print out warnings
telling the user about that.
As pointed out by Seth Falcon, this amounts to a lot of warnings
that could confuse and worry users. I'm not entirely comfortable
completely silencing the warnings, but showing one warning per
path that we track should be reasonable.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should fix fetching for people who did not use
"git svn --minimize" or cannot connect to the repository root
due to the lack of permissions.
I'm not sure what I was on when I made the change to the
rel_path() function in 4e9f6cc78e
that made it die() when we weren't connected to the repository
root :x
Thanks to Sven Verdoolaege for reporting this bug.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This avoids fetching new revisions remotely, and is usefuly
versus plain "git rebase" because the user does not have to
specify which remote head to rebase against.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using do_switch:
We only need to ensure the index is clean and set to that of the
parent tree) we rely on being able to reconstruct full files
with deltas transferred over the network.
When using do_update:
We may safely unlink the index if we are fetching an entire
new tree with do_update. Having an old index (from a
previously deleted/abandoned directory) around can cause
irrelevant files to be mistakenly kept.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Clearing the pool of the previous SVN::Ra connection we have
seems to to fix mysterious connection dropping errors when
reconnecting to different paths of svn:// repositories hosted by
rubyforge.org.
Note: I'm not sure *why* this fixes things things,
but it does for me.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs caused this to fail:
* GIT_DIR was set incorrectly after entering the target directory
* Avoid double chdir-ing when clone is called with an explicit path
* create target subdirectory *before* running git-init when using
the multi-init path
Signed-off-by: Eric Wong <normalperson@yhbt.net>
http://foo@blah.com/path is the same as http://blah.com/path, so
remove usernames from URLs before storing them in commits, and when
reading them from commits.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If we are run inside a subdirectory of a working tree, we'll
chdir to the top first before touching anything. This also
prevents the accidental creation of .git directories inside
subdirectories since they need metadata.
Noticed by maio on #git
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows the user to run git-svn show-ignore on there
current HEAD without needing to remember which branch/ref they
branched from with -i. Also, find_by_url should correctly
handle cases where the URL passed to it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since the options that affect the way metadata is handled in
git-svn, should be consistently set/unset throughout history
imported by git-svn; it makes sense to allow the user to set
certain options from the command-line that will write to the
config file when initially creating the repository.
Also, fix some formatting issues while we're updating
documentation.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svm:mirror is not useful at all for us. Parts of the old unit
test were broken and based on my misunderstanding of the
svm:mirror property.
When we read svm:source; make sure we correctly handle the '!'
in it: it is used to separate the path of the repository root
from the virtual path within the repository. We don't need
to make that distinction, honestly!
We also ensure that subdirectories are also mirrored with the
correct URL if we're using useSvmProps.
We have a new test that uses dumped repo that was really
created using SVN::Mirror to avoid ambiguities and
mis-understandings about the svm: properties.
Note: trailing whitespace in the svm.dump file is unfortunately
a reality and required by SVN; so please ignore it when applying
this patch.
Also, ensure that the -R/--remote/--svn-remote flag is always
in effect if explicitly passed via the command-line. This
allows us to track logically different mirrors sharing the
same URL (probably common with SVN::Mirror/SVK users).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to useSvmProps, but far simpler in
implementation because svnsync retains a 1:1
between revision numbers and relative paths within
the repository
Config keys: svn.useSvnsyncProps
svn-remote.<repo>.useSvnsyncProps
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This feature allows users to create repositories from alternate
URLs. For example, an administrator could run git-svn on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
Config key: svn-remote.<remote>.rewriteRoot
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having it named as 'config' prevents us from tracking a
ref named 'config', which is a huge mistake.
On the non-technical side, the word 'config' implies that
a user can freely modify it; but that's not the case
here.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Fixed logic for renaming old .rev_db -> .rev_db.$uuid
* correctly handle manual migrations for those who decide to
start use globbing to handle branches/tags over individual
'fetch' keys
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This works similarly to 'svn update' or 'git pull' except that
it preserves linear history with 'git rebase' instead of 'git
merge' for ease of dcommit-ing with git-svn.
While we're at it, put the working_head_info() logic
into its own function and allow --fetch-all/--all for
dcommit and rebase (which will fetch all refs in the
current [svn-remote] instead of just the working one).
Note that the '-a' switch (short for --fetch-all/--all) has been
removed as it conflicts with the non-svn 'git fetch'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
On newly-created repositories, 'refs/heads/master' does not
point to anything. This can be confusing to new users; so we
update 'master' to point to the last imported ref after fetching
is done.
Once 'master' is valid; we assume HEAD points to it; and if
the repository is not bare, then checkout the files if the
working tree is clean and unused.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force the showing of the --minimize flag as an option in the
'migrate' help.
Also, fix the usage function to correctly filter out
the deprecated aliases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows users to use SVM (SVN::Mirror) to mirror a remote
repository to use dcommit to commit to the repository that SVM
was mirroring. When dcommit is used in this manner, the automatic
fetch + rebase/reset does not happen; in which case the user will
have to manually invoke svm/svk, run 'git svn fetch', and finally
'git rebase'.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The newer default value should should lower memory usage for
large fetches and also help with fetching from less reliable
servers. Previously the value was 1000 and memory usage
got a bit high on some repositories and fetching became
less reliable in some cases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, some changes to avoid creating dead dirs under
.git/svn/. We now create all directories as late as
possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* avoid skipping modification-only changes in fetch
* correctly fetch when we only have branches and tags
to glob from (no fetch keys defined)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init is now just an alias that requires -T/-t/-b;
all options that 'init' can now accept.
This will hopefully simplify usage and reduce typing.
Also, allow the --shared option in 'init' to take an optional
argument now that 'git-init --shared' supports an optional
argument.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-fetch is deprecated, "fetch -a" is easier to type
By default, fetch will fetch everything from its default
[svn-remote]; if fetch [--all|-a] is specified, then it will
fetch from all svn remotes. Refspecs on the command-line
(like git-fetch) are not supported.
Also, enable -r/--revision arguments for fetch so
users can shoot themselves in the foot^W^W^W^W^W
skip some history and do the equivalent of a shallow
clone/fetch they're not interested in.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Similar in spirit to the recent dcommit change, we now
look at 'HEAD' by default to look for a GIT_SVN_ID
so the user won't have to pass -i <GIT_SVN_ID> argument.
We are also more tolerant of of people passing bare remote names
as a result (just $GIT_SVN_ID without the -i)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Merge commits can be created when following certain parents,
(most notably 'R' cases) and we definitely don't want to exclude
them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* dcommit no longer requires the correct -i/GIT_SVN_ID option
passed to it. Since you're committing from HEAD (or another
commit that is a parent of HEAD), you'll be able to find
a commit with metadata information containing the SVN URL
that your HEAD was descended from anyways.
* I don't think dcommit ever worked for people using the
noMetadata option; so I don't think relying on metadata
is an issue.
* useSvmProps users shouldn't commit to SVN::Mirror created
repositories anyways, right?
* Users of globbing should automatically be able to commit
to paths that are not explicitly set in .git/config
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init did not write a svn-remote.<remote>.url config
entry without a --trunk argument.
Also, The svm:mirror property is used by SVN::Mirror to track
the path of the repository that we are mirroring. We need to
append that to the source (which is (presumably) just the URL of
the repository root).
Lastly, we now look harder for svm:(source|mirror|uuid) properties
in sub and parent directories. Since our relative path could
be tweaked.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Even if nothing touched paths we care about in a fetch;
increment the maxRev like we do with rev_db since
we don't like having to run get_log on revisions we've
seen before.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We need a separate .rev_db file for each repository we're
tracking. This allows us to track the same logical path off
multiple mirrors. We preserve a symlink to the old .rev_db
(no-UUID) if we're (auto-)migrating from an old version to
preserve backwards compatibility.
Also, get rid of the uuid() wrapper since we cache UUID in our
private config, and the SVN::Ra::get_uuid() function memoizes
the return value per-connection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Make sure we flush our userspace buffers and and fsync(2)
.rev_db information to disk if we use these options because
we really don't want to lose this information.
Also, disallow --use-svm-props and --no-metadata from the
command-line because history will be inconsistent if they're
only used occasionally. If a user wants to use these options,
they must be set in the config so they're always on.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Available options are currently:
svn-remote.<remote>.{noMetadata,useSvmProps,followParent}
These boolean switches will override options set globally in
[svn], and even override options set on the command-line (this
should probably change in the future, however).
Note that the noMetadata and useSvmProps options conflict. It's
both technically and logically impossible to use them together.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Pass --use-svm-props or set the svn.usesvmprops key with git-config
to enable using properties set by SVN::Mirror when it mirrored the
upstream URL.
This is heavily based on work from Sam Vilain:
> From: Sam Vilain <sam@vilain.net>
> Date: Sun, 11 Feb 2007 12:34:45 +1300
> Subject: [PATCH] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
>
> If an SVN revision has a property, "svm:headrev", it is likely that
> the revision was created by SVN::Mirror (a part of SVK). The property
> contains a repository UUID and a revision. We want to make it look
> like we are mirroring the original URL, so introduce a helper function
> that returns the original identity URL and UUID, and use it when
> generating commit messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I may resurrect it for dcommit at some point, but nobody really
uses set-tree anymore and I don't feel like introducing more
complexity into the code at this point.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs were found and fixed while getting this to work:
* Remember the 'R'(eplace) case of actions and treat it like we
would an 'A'(dd) case.
* Fix a small case of follow-parent missing a parent if a
subdirectory was modified in the revision where the parent was
copied.
* dirents returned by get_dir sometimes expire if the data
structure is too big and the pool is destroyed, so we
cache get_dir (along with check_path and get_revprops)
temporarily along with its pool.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I incorrectly used $path/? and $path/* to strip off leading
directories, but places where $path = 'branches/0.17' would
incorrectly strip changes to 'branches/0.17.1' as well.
For globs, we require that our '*' is its own path component
(surrounded by '/' or nothing). Enforce this when --prefix= is
passed to us, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--no-follow-parent disables and reverts it back to the old
default behavior of not following parents (if you don't care for
full history).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We don't need them anymore, all the rough points of
the --follow-parent implementation have been worked out.
The only improvement in the future will probably be
--follow-parent-harder, which will track subdirectories and
follow individual file history (so annotate/blame can be
complete); but that is still a ways off.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These checks were needed before git-svn got smarter about
match_paths() and using path information returned by get_log().
We also have extra checking against fetching revisions
out-of-order these days; so we don't have to worry about that as
much. We also check for tree deletions in match_paths() and
skip those as well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We can have a branch that was deleted, then re-added under the
same name but copied from another path, in which case we'll have
multiple parents (we don't want to break the original ref, nor
lose copypath info).
Add a test for this, too, of course.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to the way git proper handles refs, except we
use the keys 'branches' and 'tags' to distinguish when we want
to use wildcards.
The left-hand side of the ':' contains the remote path, and must
have one asterisk ('*') in it for the branch name. The asterisk
may be in any component of the path as long as is it on its own
directory level.
The right-hand side contains the refname and must have the
asterisk as the last path component.
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is an optimization that should conserve network
bandwidth on certain repositories and configurations.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It can be confusing and redundant, since historically the
default remote ref (not remote itself) has been "git-svn", too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since fetch_loop_common starts from the lowest revision number
in a group of Git::SVN objects; we want to avoid refetching
get_log for current users for things we've already cut it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This was originally needed before we used the delta fetcher and
had a less-clean follow-parent implementation that could leave
holes in the history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It looks better (like [remote "origin"]) instead of whatever
refname came up first in our directory traversal. Of course
--remote= overrides this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having 'fetch' entries in the config file created from
--follow-parent is wasteful because it can cause *future* of
invocations to follow revisions we were never interested in
in the first place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using buffered IO for reading 40-41 bytes at a time isn't very
efficient. Buffering writes for a short duration is alright
since we close() right away and buffers will be flushed.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Prefill .rev_db to the maximum revision we tried to fetch;
and take advantage of that so we can avoid using get_log()
on ranges we've already seen (and have deemed uninteresting).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Defer any signals that cause termination while they are
updating; and put the update-ref call as close to the rename()
as possible. Also, make things extra-safe (but slower) for
people using --no-metadata since they can't rely on .rev_db
being rebuilt if it's clobbered (well, I'm calling update-ref
with the -m flag for reflogs, we don't yet have a way to rebuild
.rev_db from reflogs.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Passing very large strings as arguments is bad for memory usage
as it never seems to get freed in Perl. The .rev_db format is
already not optimized for projects with sparse history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
get_log with explicit paths is the safest way to get revisions
that change a particular path we're interested in.
Unfortunately that means we still have to run get_log multiple
times for each path we're interested in, and even more if
a path gets deleted.
The first argument of get_log() is an array reference, but we
shouldn't use more than one element in that array ref because
the non-existence of _one_ of those paths for a particular range
would cause an error for all paths in that range, so yes, we
need multiple get_log calls to be on the safe side...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--svn-remote allows the default remote name to be overridden (useful
for tracking multiple SVN repositories).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We no longer delete the top-level directory even if it got
deleted from the upstream repository. In gs_do_update; we
double-check that the path we're tracking exists at both
endpoints before proceeding. We have also added additional
protection against fetching revisions out-of-order.
To simplify our internal interfaces, I've disabled passing the
'recursive' flag to the gs_do_{switch,update} wrapper functions
since we always want it in git-svn. We also pass the
entire Git::SVN object rather than just the path because it
helped me debug.
When printing progress, the refname is printed out to make
it less confusing when multi-fetch is running.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since refs/remotes/* are not automatically cloned, we expect the
user to be capable of copying those references themselves
anyways.
Also removed the documentation for --ignore-nodate while we're
at it; it has also been made automatic.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We were still skipping path information from get_log if we are
tracking /r9270/drunk/subversion/bindings/..., but got something
like this in the log:
A /r9270/drunk (from /r9270/trunk:14)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I can't seem to figure out what I or the SVN libraries are doing
wrong, but it appears to be related to reparent and probably
some global structure that gets reset if multiple SVN
connections are being used.
So now, in order to use do_switch; we'll open a new connection
to the repository with the complete URL; but we can't seem to
ever use an existing Ra object after another one has been
created...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We don't need our own error handler for other operations. Also
add a message about the successfully do_switch or do_update in
follow-parent for debugging do_switch failures with svn:// and
svn+ssh:// connections.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Historically, git-svn did not always use Digest::MD5 because
it did not use the SVN::Delta::Editor interfaces. Nowadays
it does, and the requires make strace more noisy.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using path names as refnames breaks horribly if a user is
tracking one large, toplevel directory, and a lower-level
directory is followed from another project is a parent
of another ref, as it will cause refnames such as:
'refs/remotes/trunk/path/to/stuff', which will conflict
with a refname of 'refs/remotes/trunk'.
Now we just append @$revno to the end of it the current
refname. And if we have followed back to a grandparent, then
we'll strip any existing '@$parent_revno' strings before
appending our own '@$revno' string to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The do_update or do_switch functions in SVN only allow for a
single path component; so 'path/to/deep/dir' would be
interpreted as 'path'.
SVN 1.4.x has a reparent function that can let us change the
session to use a higher-level root of the repository, so we can
use that for do_switch (which still doesn't seem to work in SVN
1.4.3 (a fix was attempted, but they missed the rest of the
typemap changes needed in trunk...)).
On the do_update side, we can use set_path on higher level
directories and set them to a newer revision so they don't get
updated. We can't do this with do_switch, either, because the
relative path we're tracking can change (directory moving into
a child of itself).
Because of these changes, we need to double check that our Fetch
editor is correctly performing stripping on any prefixed paths
from update, otherwise we'll just die() because that would be
a bug.
Added a test case which helped me notice and fix problems with
do_switch, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, this should allow for the tracking of new, but empty
directories where we would want to see the log message.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since single fetching is a special case of multi-fetch,
share code with it and the fetch loop into Git::SVN::Ra
since it uses a single Ra connection and multiple
Git::SVN objects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Before, we needed a separate svn_ra instance to run
our check_path calls once the editor was active; but
we can avoid that by running all the check_path calls
before our editor is active.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I broke this part with the URL minimization; since
git-svn will now try to connect to the root of
the repository and will end up writing files
there if it can...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn_log_changed_path_t structs were being used out of scope
outside of svn_ra_get_log (because I wanted to eventually be
able to use git-svn with only a single connection to the
repository). So now we dup them into a hash.
This was fixed while making --follow-parent fetches more
efficient. I've moved parsing of the command-line --revision
argument outside of the Git::SVN module so Git::SVN::fetch() can
be used in more places (such as find_parent_branch).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn has never been able to handle deleted branches very well
because svn_ra_get_log() is all-or-nothing, meaning that if the
max revision passed to it does not contain the path we're
tracking, we miss all the revisions in the repository.
Branches fetched using --follow-parent still do this
sub-optimally (will be fixed soon). --follow-parent will soon
become the default, so we will assume that when using get_log();
We will also avoid tracking revprops for revisions with no
path-related changes since otherwise we just end up pulling
logs to paths we don't care about.
Also added a test for this to t9104-git-svn-follow-parent.sh and
correctly commit the log message in the preceeding test (which
conflicted with a filename).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
They simply aren't interesting to track, and this will allow
us to avoid get_log().
Since r0 is covered by this, we need to update the tests to not
rely on r0 (which is always empty).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Introducing Git::IndexInfo. This module will probably be useful
outside of git-svn, so I'm not putting it in the Git::SVN
namespace.
This will allow me to more easily avoid the use of get_log() in
the future and simply run do_update in incrementing ranges.
get_log() should be avoided because there are cases where
moved/deleted directories do not track correctly (until
--follow-parent is run on a new branch).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This means that tracking the path of:
/another-larger/trunk/thunk/bump/thud inside a repository
would follow:
/larger-parent/trunk/thunk/bump/thud
even if the svn log output looks like this:
--------------------------------------------
Changed paths:
A /another-larger (from /larger-parent:5)
--------------------------------------------
Note: the usage of get_log() in git-svn still makes a
an assumption that shouldn't be made with regard to
revisions existing for a particular path.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows connections to be used more efficiently and not require
users to run 'git-svn migrate --minimize' for new repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tests always ran 'git init' before we ran so that repo-config
would always have something to read. However that does not work
in real-world situations where the user expects 'git svn init'
to work without running 'git init' first.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It's not really useful anymore now that we have a better
--follow-parent for the valid cases. Any other use
of it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having multiple fetch refspecs pointing to the same local ref
would be a very bad thing. Start avoiding the use of fatal() or
exit() inside the modules so we can libify more easily.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
