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>
'upstream' attribute is now transferred to the new manifest xml
that is created when using command 'repo manifest -o -'.
Manifest help is updated for the attributes 'sync-c','sync-s' and
'sync-j'.
Bug: Issue 164
Change-Id: If63f781e91d25c5b5b5ea0696b0c04337b0a686a
When current is "split" (i.e. some projects are current while others are not):
- Disable 'not in' printout (i.e. will print out all projects)
- Disable printing of multiple projects on one line
- Print current projects in green, non-current in white
Since using color to differentiate current from non-current in "split" cases:
- In non-split cases also print out project names in color (green for current
white for non-current)
Change-Id: Ia6b826612c708447cecfe5954dc767f7b2ea2ea7
Enable '--jobs' ('-j') option in the forall subcommand. For -jn
where n > 1, the '-p' option can no longer guarantee the
continuity of console output between the project header and the
output from the worker process.
SIG_INT is sent to all worker processes upon keyboard interrupt
(Ctrl+C).
Bug: Issue 105
Change-Id: If09afa2ed639d481ede64f28b641dc80d0b89a5c
Currently, if a local manifest wants to add groups to an existing
project, it must use remove-project and then re-add the project with
the new groups. This makes the local manifest more fragile, requiring
updates to the local manifest if the original manifest changes.
Add a new extend-project tag, which supports adding groups to an
existing project.
Change-Id: Ib4d1352efd722a65dd263d02644b9ea5ab6ed400
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
Use JSON as it is shown to be much faster than pickle.
Also clean up the loading and saving functions.
Change-Id: I45b3dee7b4d59a1c0e0d38d4a83b543ac5839390
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
Only warn about using Python 3 when running the repo script directly.
This prevents the user being warned twice.
Change-Id: I2ee51ea2fa0127ea310598320e460ec9f38c6488
dict.keys() produces a dict_keys object in Python 3, which does
not support .sort(). Use sorted() which will give the same outcome.
Change-Id: If6b33db07a31995b4e44959209d08d8fb74ae339
dict.values() produce dict_values objects rather than list objects.
Convert this to a list to maintain functionality with certain functions.
Change-Id: Ie76269e19f8d68479a1d7ae03aa965252d759a9e
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
For long-running forall commands sometimes it's useful to know which
iteration is currently running. Add REPO_I and REPO_COUNT environment
variables to reflect the current iteration count as well as the total
number of iterations so that the user can build simple status
indicators.
Example:
$ repo forall -c 'echo $REPO_I / $REPO_COUNT; git gc'
1 / 579
Counting objects: 41, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (41/41), done.
Total 41 (delta 21), reused 41 (delta 21)
2 / 579
Counting objects: 53410, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10423/10423), done.
Writing objects: 100% (53410/53410), done.
Total 53410 (delta 42513), reused 53410 (delta 42513)
3 / 579
...
Change-Id: I9f28b0d8b7debe423eed3b4bc1198b23e40c0c50
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Part of the cleanup path for _Init is removing the .repo
directory. However, _Init can fail before creating the .repo directory,
so trying to remove it raises another exception:
fatal: invalid branch name 'refs/changes/53/55053/4'
Traceback (most recent call last):
File "/home/mitchelh/bin/repo", line 775, in <module>
main(sys.argv[1:])
File "/home/mitchelh/bin/repo", line 749, in main
os.rmdir(repodir)
OSError: [Errno 2] No such file or directory: '.repo'
Fix this by only removing .repo if it actually exists.
Change-Id: Ia251d29e9c73e013eb296501d11c36263457e235
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
For complex .gitconfig url rewrites, multiple insteadOf lines may be
used for a url. Search all of them for the right rewrite.
Change-Id: If5e9ecd054e86226924b0baf513801cd57c389cd
The `review.URL.autocopy` setting sends email notification to the
named reviewers, but does not add them as reviewer on the uploaded
change.
Add a new setting `review.URL.autoreviewer`. The named reviewers
will be added as reviewer on the uploaded change.
Change-Id: I3fddfb49edf346f8724fe15b84be8c39d43e7e65
Signed-off-by: bijia <bijia@xiaomi.com>
In existing workspaces where the manifest specifies a commit id in the
manifest, we can avoid doing a fetch from the remote if we have the
commit locally. This substantially improves sync times for fully
specified manifests.
Change-Id: Ide216f28a545e00e0b493ce90ed0019513c61613
Commit 8d201 "repo: Support multiple branches for the same project."
(Change id is I5e2f4e1a7abb56f9d3f310fa6fd0c17019330ecd) caused missing
mirroring manifest repository when 'repo sync' after 'repo init --mirror'.
When the function _AddMetaProjectMirror() is called to add two of
meta projects - git-repo itself and manifest repository to mirror,
it didn't add them into self._paths which has list of projects to be
sync'ed by 'repo sync'.
In addition, because member var of Project 'relpath' is used as a key
of self._paths, it should be set with proper value other than None.
Since this is only for meta projects which are not described in manifest
xml, 'relpath' is name of the projects.
Change-Id: Icc3b9e6739a78114ec70bf54fe645f79df972686
Signed-off-by: Kwanhong Lee <kwanhong.lee@windriver.com>
This command allows a deeper diff between two manifest projects.
In addition to changed projects, it displays the logs of the
commits between both revisions for each project.
Change-Id: I86d30602cfbc654f8c84db2be5d8a30cb90f1398
Signed-off-by: Julien Campergue <julien.campergue@parrot.com>
The fetch logic is now shared between the jobs == 1 and
jobs > 1 cases. This refactoring also fixes a bug where
opts.force_broken was not honored when jobs > 1.
Change-Id: Ic886f3c3c00f3d8fc73a65366328fed3c44dc3be
When we do an initial fetch and have not specified any branch etc,
the following fetch command will not error:
git fetch origin --tags +refs/heads/*:refs/remotes/origin/*
In this change we make sure something got fetched and if not we report
an error.
This fixes the bug that occurs when we init using a bad manifest url and
then are unable to init again (because a manifest project has been
inited with no manifest).
Change-Id: I6f8aaefc83a1837beb10b1ac90bea96dc8e61156
Currently if you run repo download -c on a change and the cherry-pick
runs into a merge conflict a Traceback is produced:
rob@rob-i5-lm ~/Programming/repo_test/repo1 $ repo download -c repo1 3/1
From ssh://rob-i5-lm:29418/repo1
* branch refs/changes/03/3/1 -> FETCH_HEAD
error: could not apply 0c8b474... 2
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Traceback (most recent call last):
File "/home/rob/Programming/git-repo/main.py", line 408, in <module>
_Main(sys.argv[1:])
File "/home/rob/Programming/git-repo/main.py", line 384, in _Main
result = repo._Run(argv) or 0
File "/home/rob/Programming/git-repo/main.py", line 143, in _Run
result = cmd.Execute(copts, cargs)
File "/home/rob/Programming/git-repo/subcmds/download.py", line 90, in Execute
project._CherryPick(dl.commit)
File "/home/rob/Programming/git-repo/project.py", line 1943, in _CherryPick
raise GitError('%s cherry-pick %s ' % (self.name, rev))
error.GitError: repo1 cherry-pick 0c8b4740f876f8f8372bbaed430f02b6ba8b1898
This amount of error message is confusing to users and has the side effect
of the git message telling you the actual issue being ignored.
This change introduces a message stating that the cherry-pick couldn't
be completed removing the Traceback.
To reproduce the issue create a change that causes a conflict with one currently
in review and use repo download -c to cherry-pick the conflicting change.
Change-Id: I8ddf4e0c8ad9bd04b1af5360313f67cc053f7d6a
