The source (target) of the symlink is specified relative to a project
within a tree, and the destination is specified relative to the top
of the tree, so it should always be possible to create a relative symlink
to the target file. Relative symlinks will allow moving an entire tree
without breaking the symlink, and copying a tree (with -p) without leaving
a symlink to the old tree.
Change-Id: I16492a8b59a137d2abe43ca78e3b212e2c835599
Pressing ctrl-c during repo sync often hangs for 30 to 45 seconds
due to the time.sleep and retry in _RemoteFetch. If git exits with
a signal, for example -2 for SIGINT triggered by ctrl-c, skip the
sleep and retry.
Change-Id: I32da12c2dcc96d9cc0b12a066e824b12ebfb52a0
In 2fb6466f79 an optimisation was
added to avoid fetching from remotes if the project is fixed to
a revision and the revision is already available locally.
This causes problems for users who expect all objects to be
fetched by default.
Change the logic so that the optimized behaviour is only enabled if
an option is explicitly given to repo sync.
Change-Id: I3b2794ddd8e0071b1787e166463cd8347ca9e24f
When syncing a mirror repo, add the --prune option to the fetch
command to force removal of stale refs from the mirror.
Change-Id: I4b43b2a5c86b9915627887c16f6569066f3ab978
Appending the branch to the fetch spec causes sync of a mirror to
fail for projects that don't have an explicit revision specified,
and don't have a branch of the same name as the default revision.
For example, a manifest defining a default revision:
<default revision="master">
having a project without an explicit revision:
<project name="path/to/project">
and not having a branch named "master", will cause repo sync to
fail for that project with the error:
Couldn't find remote ref refs/heads/master
Modify the logic to not append the branch onto the fetch spec when
syncing to a mirror.
Change-Id: I5c4457bd125519abf27abe682dea62ad708978c9
When running repo branch, the git merge line (in many circumstances)
is set to the revision of the project specified in the manifest. If
this is a branch name that is not fully-qualified, we will end up with
something like "merge = master" instead of "merge = refs/heads/master".
This change examines the revision if we are going to use that and
changes branch short names to fully qualified branch names.
Change-Id: Ie1be94fb8d45df8eeac44a47f729a3819a05fa81
Switch the GitCommand program to always capture the output for stdout
and stderr. And by default print the output while running.
The options capture_stdout and capture_stderr have effectively become
options to supress the printing of stdout and stderr.
Update the 'git fetch' to use '--progress' so that the progress messages
will be displayed. git checks if the output location isatty() and if it
is not a TTY it will by default not print the progress messages.
Change-Id: Ifdae138e008f80a59195f9f43c911a1a5210ec60
This reverts commit 38e4387f8e.
A "repo init" followed by "repo sync" is meant to be as safe as
"git clone". In particular it should not run arbitrary code provided
by the manifest owner.
It would still be nice to have support for manifest-defined git hooks
--- they'd just need a prompt like the upload RepoHook has. Hopefully
a later change can bring them back.
Change-Id: I5ecd90fb5c2ed64f103d856d1ffcba38a47b062d
Signed-off-by: Jonathan Nieder <jrn@google.com>
Currently, paths longer than 39 chars have no space after them so it looks
like this:
project path/branch master
Change-Id: I4c1bb13648ac099ade8a8d4ebafa04131571f842
The stderr output generated by git during a RemoteFetch was not being
printed. This information is useful so print it.
Change-Id: I6e6ce12c4a57e5ca2359f76ce14f2fcbbc37a5ef
If the repo project is synced with partial depth, then the tags
won't be fetched and users will be told the newest sha1 in the
stable branch isn't signed.
Change-Id: I107df97b4836b928c76aa33a700fa35d1705ae09
Handle the case when this error occurs:
error: some local refs could not be updated; try running
'git remote prune origin' to remove any old, conflicting branches
This is usually caused by a reference getting changed from a file to a
directory.
For example:
Initially someone creates a branch 'foo' and it is stored as:
.git/refs/remotes/origin/foo
Then later on it is decided to change the layout structure where 'foo'
is a directory with branches below it:
.git/refs/remotes/origin/foo/master
The problem occurs when someone still has
'.git/refs/remotes/origin/foo' on their system and does a repo sync.
When this occurs the error message for needing to do a
'git remote prune origin' occurs.
Now when doing a 'git fetch' if the error message from git says that a
'git remote prune' is needed, it will do the prune and then retry the
fetch.
Change-Id: I4c6f5aa6bd932f0ef7a39134400bedd52e82f633
Signed-off-by: John L. Villalovos <john.l.villalovos@intel.com>
When working within a team or corporation it is often
useful/required to use predefined git templates. This
change teaches repo to use a per-remote git hook template
structure.
The implementation is done as a continuation of the
existing projecthook functionality. The terminology is
therefore defined as projecthooks.
The downloaded projecthooks are stored in the .repo
directory as a metaproject separating them from the users
project forest.
The projecthooks are downloaded and set up when doing a
repo init and updated for each new repo init.
When downloading a mirror the projecthooks gits are
not added to the bare forest since the intention is to
ensure that the latest are used (allows for company policy
enforcement).
The projecthooks are defined in the manifest file in the
remote element as a subnode, the name refers to the
project name on the server referred to in the remote.
<remote name="myremote ..>
<projecthook name="myprojecthookgit" revision="myrevision"/>
</remote>
The hooks found in the projecthook revision supersede
the stock hooks found in repo. This removes the need for
updating the projecthook gits for repo stock hook changes.
Change-Id: I6796b7b0342c1f83c35f4b3e46782581b069a561
Signed-off-by: Patrik Ryd <patrik.ryd@stericsson.com>
Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
Currently, we only use the depth flag when cloning. The result is that when
new project history has merges, the entire history of the merged branch is
brought in and the project becomes unshallow very quickly. --depth and
clone-depth are often used to save on space, not just network load, so this
seems less than ideal.
This change uses --depth on every fetch (when the user has depth specified),
not just the initial clone. The result is that the given project stays
consistently shallow as opposed to growing over time, especially when merges
are involved.
Change-Id: Iac706cfdad4a555c72f9d9f1119195d38d91df12
When doing a shallow checkout SHA1 pinned repos with repo init --depth=1 and
repo sync -c, repo would try to fetch only some reference and fail if the exact
SHA1 repo was missing.
Instead, when depth is set, fetch only the specific commit.
Change-Id: If3f799d0e78c03faea47f796380bb5e367b11998
We currently delete all hooks in .git/hooks for each project before
symlink'ing in the standard project hooks. This can be annoying for
users who have installed custom git hooks.
There's no reason to delete all existing hooks. Just rip out the
deletion code.
Change-Id: I5062a6cd20af700f6d6a17b11ad6c94853987c57
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The persistent proxy may choose to present a per-process cookie file
that gets cleaned up after the process exits, to help with the fact
that libcurl cannot save cookies atomically when a cookie file is
shared across processes. We were letting this cleanup happen
immediately by closing stdin as soon as we read the configuration
option, resulting in a nonexistent cookie file by the time we use the
config option.
Work around this by converting the cookie logic to a context manager
method, which closes the process only when we're done with the cookie
file.
Change-Id: I12a88b25cc19621ef8161337144c1b264264211a
The invalid clone.bundle file warning is not typically user actionable,
and can be confusing. So don't show it when -q flag is in effect.
Change-Id: If9fef4085391acf54b63c75029ec0e161c38eb86
This reverts commit 565480588d.
We are reverting this change for 2 reasons:
1) It introduced a bug for users using sync -c with a reference mirror.
2) The fetch specs have recently changed to cause git to properly fail
when we request a non-existent branch of a manifest, removing the need
for this change.
Change-Id: I0f63da9bfb40cf5ffafb7979f1b8c929a738fc7b
When there are uncommitted files in the tree, 'repo upload' stops to
ask if it is OK to continue, but does not report the actual names of
uncommitted files.
This patch adds plumbing to have the outstanding file names reported
if desired.
BUG=None
TEST=verified that 'repo upload' properly operates with the following
conditions present in the tree:
. file(s) modified locally
. file(s) added to index, but not committed
. files not known to git
. no modified files (the upload proceeds as expected)
Change-Id: If65d5f8e8bcb3300c16d85dc5d7017758545f80d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@google.com>
While not typical, some users might have an upstream that isn't in
the usual refs/heads/* namespace. There's no reason not to use
those refs as the value for the upstream attribute, so support
doing so.
Change-Id: I5b119f1135c3268c20e7c4084682e860d3ee1fb1
If a user reinits to a different manifest or the manifest updates so
that a project no longer has a fixed depth, we need to use --unshallow
when we fetch.
Change-Id: I6d3f15e5464b5eaad9205654bc24354947a78aea
Some projects use multiple remotes.
In some cases these remotes have different naming conventions.
Add an option to define a revision in the remote configuration.
The `project` revision takes precedence over `remote` and `default`.
The `remote` revision takes precedence over `default`.
The `default` revision acts as a fall back as it originally did.
Change-Id: I2b376160d45d48b0bab840c02a3eef1a1e32cf6d
iterator.next() was replaced with iterator.__next__() in Python 3.
Use next(iterator) instead which will select the correct method for
returning the next item.
Change-Id: I6d0c89c8b32e817e5897fe87332933dacf22027b
A recent optimization (2fb6466f79) skips
performing a remote fetch if we already know we have the sha1 we want.
However, that optimization skipped initialization steps that ensure HEAD
points to the correct sha1. This change makes sure not to skip those
steps.
Here is an example of how to test this change:
"""""""""
url=<manifest url>
branch1=<branch name>
branch2=<branch name>
project=<project with revision set to different sha1 in each branch>
repo init -u $url -b $branch1 --mirror
repo sync $project
first=$(cd $project.git; git rev-parse HEAD)
repo init -b $branch2
repo sync $project
second=$(cd platform/build.git; git rev-parse HEAD)
if [[ $first == $second ]]
then
echo 'problem!'
else
echo 'no problem!'
fi
"""""""""
This fixes the bug that kept clients from doing things like `git log`
in projects using the clone-depth feature.
Change-Id: Ib4024a7b82ceaa7eb7b8935b007b3e8225e0aea8
It's just like copyfile and runs at the same time as copyfile but
instead of copying it creates a symlink instead. This is needed
because copyfile copies the target of the link as opposed to the
symlink itself.
Change-Id: I7bff2aa23f0d80d9d51061045bd9c86a9b741ac5
If a manifest includes projects with a clone-depth=1 attribute, and a
workspace is initialised from that manifest using the --mirror option,
any workspaces initialised and synced from the mirror will fail with:
fatal: attempt to fetch/clone from a shallow repository
on the projects that had the clone-depth.
Ignore the clone-depth attribute when fetching from the remote to a
mirror workspace. Thus the mirror will be synched with a complete
clone of all the repositories.
Change-Id: I638b77e4894f5eda137d31fa6358eec53cf4654a
Currently, the --no-tags option is ignored if the user asks to only
fetch the current branch. There is no reason for this restriction. Fix
it.
Change-Id: Ibaaeae85ebe9955ed49325940461d630d794b990
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The old "manifest required for this command -- please run
init" is replaced by a more helpful message that lists the
command repo was trying to execute (with arguments) as well
as the str() of the NoManifestException. For example:
> error: in `sync`: [Errno 2] No such file or directory:
> 'path/to/.repo/manifests/.git/HEAD'
> error: manifest missing or unreadable -- please run init
Other failure points in basic command parsing and dispatch
are more clearly explained in the same fashion.
Change-Id: I6212e5c648bc5d57e27145d55a5391ca565e4149
