repo 1.12.23 released

[Conley Owens]

A new version of repo (v1.12.23) has been released. You may let your
client update itself eventually on a sync or you can run 'repo
selfupdate'. There is no corresponding launcher change.

changelog:
* Added more robust smart sync support
* Added more robust `repo mirror` support
* Added more robust encoding/decoding support for output
* Added several improved error messages
* Added more robust support for handling unexpected git errors
* Added the --optimized-fetch flag to `repo sync` that does not fetch
if you already have the target sha1 (this is not default behavior
because some tools rely on repo sync fetching from the upstream branch
every time)
* Fixed a bug with `repo cherry-pick`

Please respond here if you run into any issues.

Thanks!
~cco3

[Dean Wheatley]

Hi there,

After this update, repo deleted all of the objects on my AOSP mirror that are not present on the upstream AOSP sources.

Before this version (1.12.23) this didn't happen (my original references weren't touched); repo sync would just pull down new upstream references, and leave my original ones alone.

I don't see this behavior change in the changelog.

Can you please elaborate whether this change was intended?

Dean

[Dean Wheatley]

I see that this functionality change was added in v1.12.23 due to the inclusion of https://gerrit.googlesource.com/git-repo/+/b4d43b9f664d6472b6c1e91c98f951037d00cea5 .

For our purposes, the "stale refs" referred to the commit msg aren't stale; we don't want to prune them.

[Wink Saville]

Currently when you use curl to get repo from https://source.android.com/source/downloading.html the version is v1.22 and the launcher is v1.21:

$ repo init -u https://android.googlesource.com/platform/manifest

$ repo --version

repo version v1.12.22

       (from https://gerrit.googlesource.com/git-repo)

repo launcher version 1.21

       (from /home/wink/bin/repo)

git version 2.1.4

Python 2.7.9 (default, Apr  2 2015, 15:33:21) 

[GCC 4.9.2]

You don't get version 1.23 until after doing a repo selfupdate:

$ repo selfupdate

remote: Counting objects: 1, done        

remote: Finding sources: 100% (17/17)           

remote: Total 17 (delta 5), reused 17 (delta 5)        

From https://gerrit.googlesource.com/git-repo

   80e3a37..b3d6e67  master     -> origin/master

   4ccad75..97836cf  stable     -> origin/stable

 * [new tag]         v1.12.23   -> v1.12.23

info: A new version of repo is available

project .repo/repo/

Updating 4ccad75..97836cf

Fast-forward

 error.py               |  4 +--

 git_command.py         |  7 ++++-

 git_config.py          |  2 +-

 main.py                |  7 +++++

 manifest_xml.py        | 12 +++++---

 project.py             | 83 ++++++++++++++++++++++++++++++++++++++------------

 subcmds/cherry_pick.py |  1 +

 subcmds/forall.py      | 40 ++++++++++++++++++++----

 subcmds/init.py        |  4 +--

 subcmds/sync.py        | 34 ++++++++++++++++-----

 10 files changed, 150 insertions(+), 44 deletions(-)

info: Restarting repo with latest version

$ repo --version

repo version v1.12.23

       (from https://gerrit.googlesource.com/git-repo)

repo launcher version 1.21

       (from /home/wink/bin/repo)

git version 2.1.4

Python 2.7.9 (default, Apr  2 2015, 15:33:21) 

[GCC 4.9.2]

When will the default version be v1.23?

-- Wink

[Juliano Quaglio]

I also had all my local branches pruned by repo/git with the update.

Is this the intended behaviour?

How are we supposed to work in a scenario of a local server using a local mirror AND local branches???

[David Pursehouse]

This change was intentional to fix the use case where refs are deleted on the origin remote but remain in the local mirror after a sync.

It looks like people are using repo sync to update gits on production git servers that also have other refs (which IMHO is not a particularly good idea, but that's another story) so I've uploaded a revert of the commit that added the change in behaviour [1].  I'll upload another commit later to re-add the functionality, but make it optional.

[1] https://gerrit-review.googlesource.com/#/c/69701/

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Juliano Quaglio]

Thanks, David.

I know it's a bit off-topic, but what do you consider a good idea?

We should have a mirror (== 'vanilla copy' of AOSP) AND a production git server that syncs with that mirror?

To use a setup like that, the production server should be synced with 'repo sync' or use directly 'git fetch'?

[David Pursehouse]

On Tue, Jul 21, 2015 at 10:48 PM Juliano Quaglio <juliano...@gmail.com> wrote:

Thanks, David.

I know it's a bit off-topic, but what do you consider a good idea?

We should have a mirror (== 'vanilla copy' of AOSP) AND a production git server that syncs with that mirror?

To use a setup like that, the production server should be synced with 'repo sync' or use directly 'git fetch'?

For syncing external repositories (i.e. aosp, etc), we git fetch from the origin to a local clone and then push from there to the production server (gerrit) with git push.

We use repo mirror for example to make local mirrors on user workstations to improve fetch/clone performance.

This is why I didn't expect removal of 'stale' refs to be a problem.

[Dean Wheatley]

Thanks David for reverting the change and your suggestion.

I'd like to implement your suggested approach, but I'm not sure whether it can work with my setup. To explain further, this is my current setup:

• repo mirror AOSP into Gerrit hosted repositories: repo init -u https://android.googlesource.com/mirror/manifest --mirror; repo sync
• We do this because we want Gerrit clients to be able to checkout AOSP branches (such as master) as well as branch/tags (such as android-5.1.0_r1). If we push AOSP project references from refs/heads/<branch> to refs/heads/<remote>/<branch> then the repo manifest (init/sync) won't work properly as the manifest will look for the branch name in the dependent projects and they won't exist. 
• An example of this not working is the way Code Aurora Forum (CAF) host/mirror AOSP (https://www.codeaurora.org/cgit/quic/la). CAF push all AOSP refs into "aosp-new/*". Sure, they host all the refs, but it breaks when someone tries to sync using an aosp-new/* manifest branch. Here are the steps:
• repo init -u git://codeaurora.org/platform/manifest.git -b aosp-new/master
• repo sync

                    This leads to "fatal: Couldn't find remote ref refs/heads/master" errors during repo sync

• So, we get around this by doing the following:
• Mirror AOSP using repo. Syncing using the mirror/manifest is very convenient, because it keeps track of new projects to sync.
• We add new branches into refs/heads/<standard-prefix>/<actual-branch-name> and tags into refs/tags/<standard-prefix>/<actual-tag-name>
• This works fine as we do not expect AOSP to create branches/tags with the <standard-prefix>. To date, there have been no naming clashes.

• Getting back to your suggestion:
• Using your approach of git fetch (even repo mirror?) to local clone and then git push from there to Gerrit. 
• Do you see any problems with keeping the 'stale' refs on Gerrit (the production server)?
• Are AOSP wanting to delete references and then use the same names later? In which case, the git push should use the --force option?
• git push --prune won't work in my situation as that would delete the <standard-prefix> refs on the production server.

Thanks for your help.

[Conley Owens]

David's change has been released.

[Alexandre Boeglin]

Hi,

On Friday, July 17, 2015 at 12:02:44 AM UTC+2, Conley Owens wrote:

Please respond here if you run into any issues.

Not exactly a new issue, but the following change seems to have been forgotten: https://gerrit-review.googlesource.com/64021

It would be nice to have it merged eventually, as it hasn't received any negative comment since February.

Best regards,

Alex

[Sam Lin]

Dear Dean Wheatley Sir,

I have the same problem, could you tell me how to do  "Getting back to your suggestion:" method's SOP???

Thanks a lot!

B.R.

Sam Lin

Dean Wheatley於 2015年7月22日星期三 UTC+8上午7時34分12秒寫道：

[Sam Lin]

Dear Sir,

Sorry to trouble you~~!!  

Could you help to tell me why repo had two different version?

It's mean one gerrit server always have two repo execution file??

Thanks a lot!!

B.R.

Sam Lin

Wink Saville於 2015年7月21日星期二 UTC+8上午3時09分19秒寫道：