tools/git-repo.git/docs, branch v2.0

docs: document internal manifests.git/config settings

2020-02-10T00:12:17+00:00

Change-Id: I6b32d925756375a9335522ff33376cb5f7ed1157 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254073 Tested-by: Mike Frysinger Reviewed-by: David Pursehouse

docs: add a developer reference for .repo/ paths

2020-02-09T03:55:47+00:00

Currently the only reference for these is the source which can be a pita when needing to refer to something quickly. Change-Id: I52baeb9a4935814cf99fa9a9b3102e8e46cddb0d Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/253972 Tested-by: Mike Frysinger Reviewed-by: David Pursehouse

Add a way to override the remote using

2020-02-04T22:42:28+00:00

This commit supports for the 'remote' attribute in . This avoids the need to perform a followed by a in local manifests. Change-Id: I9f9347913337ec9d159bc264d15ce97881ae5398 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/253092 Tested-by: Kyunam Jo Reviewed-by: Mike Frysinger

manifest: add basic path checks for &

2020-02-04T20:34:01+00:00

Reject paths in & that point outside of their respective scopes. This validates paths while parsing the manifest as this should be quick & cheap: we don't access the filesystem as this code runs before we've synced. Bug: https://crbug.com/gerrit/11218 Change-Id: I8e17bb91f3f5b905a9d76391b29fbab4cb77aa58 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/232932 Tested-by: Mike Frysinger Reviewed-by: Mike Frysinger Reviewed-by: Michael Mortensen

docs: add Windows support info

2019-12-05T01:02:08+00:00

Change-Id: I82a1bec3a29d622c76b5709b96bbe8bff8aa427f Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/247573 Tested-by: Mike Frysinger Reviewed-by: David Pursehouse

python-support: adjust major versions

2019-10-11T06:56:03+00:00

The plan previously documented was <=1.13.x is Python 2 and >=1.14.x is Python 3. Other projects that migrated Python versions and drop support for older have tended to take a more drastic version jump to make it clearer to users. So lets adjust the plan to say <=1.x will support Python 2, and >=2.x will be Python 3-only. This also allows us to harmonize the repo launcher version. It is currently sitting at v1.26 and has been incremented independently of the repo version for the life of the project. While we might know these lower nuances, pretty much no one else does and it just leads to confusion: do I know version 1.26 or version 1.13.7? Or do I have both? What does that even mean? Once we update the major version to 2.0.0, we can also adjust the launcher script to 2.0.0, and then the launcher release process will be tied to a new repo release in general. Bug: https://crbug.com/gerrit/10418 Change-Id: Idb2257371a06e56d2923cf717345c028f49176a2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/240372 Reviewed-by: David Pursehouse Tested-by: Mike Frysinger

manifest-format: document implicit directory creation w/ &

2019-08-02T04:21:40+00:00

Bug: https://crbug.com/gerrit/11218 Change-Id: Ie96b4c484d9fbfd550c580c3d02971dc088dd8b0 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/233052 Reviewed-by: David Pursehouse Tested-by: Jonathan Nieder

manifest-format: clarify & restrictions

2019-08-01T04:06:04+00:00

While we don't (yet) explicitly enforce all of these, make sure we document the expected behavior so we can all agree on it. Bug: https://crbug.com/gerrit/11218 Change-Id: Ife8298702fa445ac055ef43c6d62706a9cb199ce Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/232893 Reviewed-by: David Pursehouse Tested-by: Mike Frysinger

hooks: support external hooks running different Python version

2019-07-27T01:10:40+00:00

As we convert repo to support Python 3, the version of Python that we use might not be the version that repo hooks users have written for. Since repo upgrades are not immediate, and not easily under direct control of end users (relative to the projects maintaining the hook code), allow hook authors to declare the version of Python that they want to use. Now repo will read the shebang from the hook script and compare it against the version of Python repo itself is running under. If they differ, we'll try to execute a separate instance of Python and have it load & execute the hook. If things are compatible, then we still use the inprocess execution logic that we have today. This allows repo hook users to upgrade on their own schedule (they could even upgrade to Python 3 ahead of us) without having to worry about their supported version being exactly in sync with repo's. Bug: https://crbug.com/gerrit/10418 Change-Id: I97c7c96b64fb2ee465c39b90e9bdcc76394a146a Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/228432 Reviewed-by: David Pursehouse Tested-by: Mike Frysinger

docs: start a release document

2019-06-13T03:18:10+00:00

Change-Id: I884639665c020338ec9ceeb1add5c3b862583674