| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scenario: a repository contains a ref: refs/heads/foo and we
have that in our repository cache.
Action: upstream deletes that ref and then pushes a new refs
at refs/heads/foo/bar.
Action: we attempt to update the git and the update fails because
git remote update cannot cope with the 'kind' change of
refs/heads/foo from ref to directory.
Remedy: If we get an exception from the remote update --prune we
try the less efficient but more resilient combination of
first pruning and then updating.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|