| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Git has a garbage collection 'porcelain' command called 'gc' which does more
than just repack the repository. Use that in preference to 'git repack' and
also configure the repositories so that they don't use too much RAM whilst
repacking.
Also, we allow gitify_* routines to set self.needs_aggressive on their initial
imports so that we aggressively repack the first clone.
|
|
|
|
|
|
|
|
| |
This patch makes Lorry always create bare repositories where it can (Note that
it cannot for CVS imports) and to create tarballs of bare repositories (if not
disabled) which will be more efficient than bundles for creation and cloning.
We may be able to disable bundles later.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As annoying as it is to have non-fast-forward commits, it is still
a valid workflow, so it has to be allowed.
|
|
|
|
|
|
|
| |
The origin remote may not be the remote that should be pulled from
any more, it may have been changed in the .lorry.
Also since we are pushing refs/heads/*, we should be fetching the
same.
|
|
|
|
|
| |
Obviously pushing to the base-url won't work, the repository's
url needs to be generated.
|
|
|
|
|
|
|
| |
Since the remote is no longer pushed to, and should never have been
pulled from, any code for managing these remotes is no longer used.
So the function for creating this remote and anything that checks
for the remote can be removed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than pushing to the remote 'gitorious', it is better to push
to the remote specified in lorry's config, since it may have changed
since the repository was originally mirrored, so the remote in
git's config may be out of date.
This may make the setting of the 'gitirous' remote obsolete now.
Note that the semantic difference between pushing to a remote and
pushing to a url isn't triggered because we always pass refspecs.
|
|
|
|
| |
The user may specify a relative one
|
| |
|
| |
|
|
|
|
|
|
| |
Backup the git repository before running mirror and if any part
of mirroring fails, restore the .git repository to its previous
state and keep the failed mirror for debugging.
|
|
|
|
|
|
|
|
|
| |
The marks correspond to the import state of the git repository,
the .git directory is where the current state of the git repo is kept,
so it makes sense for the marks to be in there.
This is partly to allow the git state to be backed up before
a repository is processed in case it is left in an inconsistent state.
|
|
|
|
|
|
|
|
|
|
|
| |
If refspecs are listed, pass them to push_to_mirror_server, if not
allow push_to_mirror_server to use its default refspecs
Also fix test cases:
- refs/tags/rc* is not a valid refspec,
* can only substitute a whole directory
- git-for-each-ref needs the whole ref path, master is not the
same as refs/heads/master
|
|
|
|
|
|
|
|
|
|
| |
Previously it was set in the add_remote stage, this means that the
respecs used to push don't appear in the logs and a change in the
lorry file would need the config changing
This logic should be equivalent for what gets pushed as the push
refspecs set in config are only used if refspecs aren't specified
in the push command line.
|
| |
|
|\ |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Drop --gitorious-base-url and introduce --mirror-base-url-fetch and
--mirror-base-url-push instead. The remote is still called 'gitorious'
internally, we should probably change that to 'mirror-server' or
'mirror'.
Other than that, these two options allow to use different URLs for
pushing and pulling. The pulling URL is also used for naming the
bundles.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Without this, I always got a "refs/heads/origin is an invalid SHA1"
error. From the git-cvsimport manual:
-a
Import all commits, including recent ones. cvsimport by
default skips commits that have a timestamp less than 10
minutes ago.
|
|/
|
|
|
|
|
|
| |
lorry was failing to cope with missing or relative
working directory. After fix if no directory is
given it will show a message that no working directory
in path and will use "workd" directory. It will also
create the directory if it isn't present.
|
| |
|
|
|
|
| |
the exit code will be number of mirror failed
|
| |
|
|
|
|
|
|
|
| |
Lorry fails as soon one mirror encounters exception.
Resolve:
Exception handled when some thing goes wrong with mirror and
move to the other mirror.
|
|
|
|
|
|
|
|
| |
A bundle policy and destination can be specified in settings
It will bundle up tags and branches
Some changes to fetching were required, now it only fetches origin and expects that
the refspec fetches into local refs. svn support has been altered to support this
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The branches generated by git-svn appear to be lightweight tags
These are just a reference to a commit, the script to convert these
into full tags may not create the same sha1 for each tag.
This shows that git-svn is not properly handling tags
there is no such thing as a remote tag, so they have to be fetched
into refs/tags
I could change the refspecs to do this, but given this is just an
intermediate stage before they are pushed to another repository it
would only be visible to people poking their noses in the working area
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
git push defaults to pushing matching branches, this will not push new branches
git push --all will push all local branches, but not every repo has all the remote
branches mirrored by local branches
refspecs can be configured to give better control over what git push does
So now when gitorious is added as a remote its refspecs can be changed
it defaults to pushing branches and tags but it can be changed to give finer control
git-svn uses refspecs to push the remote branches
it could have been made to fetch svn refs as local refs, but that may have
introduced bugs and would require altering the trunk fetch refpec
when currently it is ok to add new refspecs for tags and branches
|
|
|
|
|
| |
the svn-remote is called svn, have the branches in refs/remotes/svn for consistency
with normal remotes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Glob expressions can be used to specify branches, but git svn clone/init will append /* to
them unless they have a * in them. It is possible to have globs without.
netpbm has branches in its root directory, so the glob
{advanced,stable,super-stable} should select only those directories
as branches, but they become {a,s,ss}/*, so subdirectories of each become
branches
The workaround is to manually add the glob expression to config
so it is cloned then branches are added, then re fetched
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
git svn fetch updates the remote tracking branch
it does not alter the master branch to include the changes
so git svn rebase must be used to do this
It may be possible to just push the remote tracking branch to gitorious
but other imports push the working branches, so this keeps it simpler
without that much extra overhead as the rebase should be cheap
This also adds a couple of extra options, to get command output before
the program finishes, useful for long programs
|
|
|
|
| |
So it is cloned into $project/git rather than $project/git/$url
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a layout field to the lorry spec
if it is omitted it is assumed that the url points to the trunk
if layout is "standard" then url/trunk url/tags and url/branches
point to the trunk, tags and branches
if layout is a dict then the trunk, branches and tags fields
are the corresponding paths
Strange layouts can be handled by a wildcard * in the path
So if there are branches in branches, but the Build/source is
the only part wanted then "branches": "branches/*/Build/source"
will only pull that
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
adds a repack setting so if it is too expensive an operation it can be turned off
run git-repack after the gitify step, maybe it should check whether it needed updating
but that may not be simple
|
| |
|
|
|
|
|
| |
adds the marks files when converting, I don't know what they are all for
This also fixes lorry importing bzr repos
|
| |
|