New repo version v1.12.17

[Conley Owens]

A new version of repo (v1.12.17) 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 a global --color option
* Added an extend-project manifest tag modify existing projects
* Added per-remote default revisions
* Added a --jobs flag to `repo forall`
* Added support for non-HEADs refs, eg: "refs/blobs/etc"
* Added ability to specify a target on smart syncs
* Improved Python3 support
* Improved persistent-https://and rpc:// support
* Improved shallow clone support
* Improved support for manifest-specified sha1 revisions
* Improved `repo upload` output
* Improved clone.bundle fetching behavior
* Improved `repo manifest` output
* Moved from pickle to json for various caches (insignificant effect
on speed and let's users read values more easily)
* General code cleanup

Please respond here if you run into any issues.

Thanks!
~cco3

[Alexandre Boeglin]

Hello,

On Tuesday, January 27, 2015 at 10:44:08 PM UTC+1, Conley Owens wrote:

A new version of repo (v1.12.17) has been released.

changelog:

* Added support for non-HEADs refs, eg: "refs/blobs/etc"

Please respond here if you run into any issues.

We've been using repo to manage the several repositories of our project for some time now, and it seems that 1.12.17 is no longer working for us.

Specifically, the commit we're having issues with is 04e52d6 (Always fetch the specific revision given - Don't assume the revision is in refs/heads/).

The issue is that in our case, we like to put "pretty" sha1s in our manifest, generated using "git describe --tags --long". It used to work well, as long as we didn't try to use the "current_branch_only" option of git fetch.

The problem we have with 1.12.17 is with the _RemoteFetch method of the Project class, around line 1845: since the ID_RE regex doesn't match the revisions in our manifest, is_sha1 is false, and an erroneous reference gets added to the git fetch command.

After thinking about a clean way to solve this issue for  a bit, I think the issue is with the following conditional block:

      if not branch.startswith('refs/'):

        branch = R_HEADS + branch

      spec.append(str((u'+%s:' % branch) + remote.ToLocal(branch)))

Since "refs/heads/*" has already been added to spec a few lines above, I think this is redundant and is could simply be removed in the case branch does not start with "refs/". Unless current_branch_only is set, of course.

A proposed fix is attached.

Best regards,

Alex

[Conley Owens]

Could you please push your patch to our project on Gerrit?
http://gerrit-review.googlesource.org/git-repo

> --
> --
> 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.

[Alexandre Boeglin]

Ok, it has been pushed as https://gerrit-review.googlesource.com/64021

Best regards,

Alex

[Conley Owens]

Thanks, Alexandre!

On Mon, Feb 2, 2015 at 7:24 AM, Alexandre Boeglin

[Makson Lee]

On Wednesday, January 28, 2015 at 5:44:08 AM UTC+8, Conley Owens wrote:

* Added support for non-HEADs refs, eg: "refs/blobs/etc"

If the revision in the manifest point to a SHA1 which exist on a non-HEADs refs, eg: "refs/sandbox/user1/workspace1", you will get "not a valid SHA1" error when running "repo sync".

In our case, we try to create our own sandbox branch in each git repository, then we create a static manifest (repo manifest -r -o default.xml) and put it to sandbox branch in manifest repository, finally we want to download it with commands like following, anything i am doing wrong?

repo init -u git://gerrit-master/manifest -b refs/sandbox/user1/workspace1
repo sync
 

[Conley Owens]

Have you tried using the upstream attribute?

"""
Attribute `upstream`: Name of the Git ref in which a sha1
can be found. Used when syncing a revision locked manifest in
-c mode to avoid having to sync the entire ref space.

[Makson Lee]

On Thursday, February 12, 2015 at 3:42:54 AM UTC+8, Conley Owens wrote:

Have you tried using the upstream attribute?

"""
Attribute `upstream`: Name of the Git ref in which a sha1
can be found.  Used when syncing a revision locked manifest in
-c mode to avoid having to sync the entire ref space.
"""

Thank you, added the upstream fixed the issue, but i didn't run repo sync in -c mode, why we still need the upstream attribute?

[Conley Owens]

Good question. Sounds like a bug.