summaryrefslogtreecommitdiffstats
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* upload: allow users to set labels when uploadingMike Frysinger2020-02-241-1/+2
| | | | | | | | | Bug: https://crbug.com/gerrit/11801 Change-Id: I060465105b4e68ddfc815e572f62bf5dac2c1ffd Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/256614 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* docs: update Windows infoMike Frysinger2020-02-221-4/+29
| | | | | | | | | | Add a section on worktrees to avoid symlink problems, and note that Python 3 is now a hard requirement. Change-Id: I83811db88692127c40cec8270f6f9486c639dc3f Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/256314 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* manifest_xml: change .repo/manifest.xml to a plain fileMike Frysinger2020-02-221-3/+10
| | | | | | | | | | | | | | | | Changing this to a file instead of using a symlink serves two purposes: * We can insert some comments & doc links to help users learn what this is for, discover relevant documentation, and to discourage them from modifying things. * Windows requires Administrator access to use symlinks. With this last change, Windows users can get repo client checkouts with the new --worktree option and not need symlinks anywhere at all. Which means they no longer need to be an Administrator in order to `repo sync`. Change-Id: I9bc46824fd8d4b0f446ba84bd764994ca1e597e2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/256313 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* git_config: add support for repo-specific settingsMike Frysinger2020-02-201-0/+7
| | | | | | | | | | | This allows people to write ~/.repoconfig/config akin to ~/.gitconfig and .repo/config akin to .git/config. This allows us to add settings specific to repo without mixing up git, and to persist in general. Change-Id: I1c6fbe31e63fb8ce26aa85335349c6ae5b1712c6 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/255832 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* docs: improve project-objects & worktrees layout infoMike Frysinger2020-02-191-9/+13
| | | | | | | | | | Make it clear that the paths have a .git suffix, and clarify the reason for not using remote servers in the layout. Change-Id: I62c6977ee6f4e1e9882d45727eb239cf5489d2b6 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/256033 Reviewed-by: Jonathan Nieder <jrn@google.com> Tested-by: Mike Frysinger <vapier@google.com>
* add experimental git worktree supportMike Frysinger2020-02-191-0/+6
| | | | | | | | | | | | | | | | | This provides initial support for using git worktrees internally instead of our own ad-hoc symlink tree. It's been lightly tested which is why it's not currently exposed via --help. When people opt-in to worktrees in an existing repo client checkout, no projects are migrated. Instead, only new projects will use the worktree method. This allows for limited testing/opting in without having to completely blow things away or get a second checkout. Bug: https://crbug.com/gerrit/11486 Change-Id: Ic3ff891b30940a6ba497b406b2a387e0a8517ed8 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254075 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: Mike Frysinger <vapier@google.com>
* upload: add support for setting hashtagsMike Frysinger2020-02-191-0/+1
| | | | | | | | | | | This allows users to specify custom hashtags when uploading, both via the CLI and via the same gitconfig settings as other upload options. Bug: https://crbug.com/gerrit/11174 Change-Id: Ia0959e25b463e5f29d704e4d06e0de793d4fc77c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/255855 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* docs: add per-project review/remote/branch settingsMike Frysinger2020-02-191-1/+59
| | | | | | | Change-Id: Iae7dc438b4a145140b4e105a61024a11e30b2c2b Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/255792 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* docs: document git/python/Ubuntu/Debian release schedulesMike Frysinger2020-02-121-1/+85
| | | | | | | | | | | | | | | | Going purely on upstream package release cycles doesn't tell the whole story: a lot of people run LTS distros which will have older versions of software we want to support. Build out a table for us to quickly reference when making decisions as to what versions of git/python we want to support, and when we can drop them. This will also help to refer users to as why we made a specific decision that might be affecting them. Change-Id: I7aea24bbefd50e358aeacf11e8c15a346c8fb8a9 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254572 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* docs: document internal manifests.git/config settingsMike Frysinger2020-02-101-0/+23
| | | | | | | Change-Id: I6b32d925756375a9335522ff33376cb5f7ed1157 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254073 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* docs: add a developer reference for .repo/ pathsMike Frysinger2020-02-091-0/+122
| | | | | | | | | | 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 <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* Add a way to override the remote using <extend-project>Kyunam Jo2020-02-041-0/+4
| | | | | | | | | | | This commit supports for the 'remote' attribute in <extend-project>. This avoids the need to perform a <remove-project> followed by a <project> in local manifests. Change-Id: I9f9347913337ec9d159bc264d15ce97881ae5398 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/253092 Tested-by: Kyunam Jo <kyunam.jo@gmail.com> Reviewed-by: Mike Frysinger <vapier@google.com>
* manifest: add basic path checks for <copyfile> & <linkfile>Mike Frysinger2020-02-041-1/+1
| | | | | | | | | | | | | | Reject paths in <copyfile> & <linkfile> 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 <vapier@google.com> Reviewed-by: Mike Frysinger <vapier@google.com> Reviewed-by: Michael Mortensen <mmortensen@google.com>
* docs: add Windows support infoMike Frysinger2019-12-051-0/+144
| | | | | | | Change-Id: I82a1bec3a29d622c76b5709b96bbe8bff8aa427f Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/247573 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* python-support: adjust major versionsMike Frysinger2019-10-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* manifest-format: document implicit directory creation w/<copyfile> & <linkfile>Mike Frysinger2019-08-021-0/+4
| | | | | | | | Bug: https://crbug.com/gerrit/11218 Change-Id: Ie96b4c484d9fbfd550c580c3d02971dc088dd8b0 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/233052 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Jonathan Nieder <jrn@google.com>
* manifest-format: clarify <copyfile> & <linkfile> restrictionsMike Frysinger2019-08-011-0/+12
| | | | | | | | | | | 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 <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* hooks: support external hooks running different Python versionMike Frysinger2019-07-272-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* docs: start a release documentMike Frysinger2019-06-121-0/+167
| | | | Change-Id: I884639665c020338ec9ceeb1add5c3b862583674
* docs: fixed typo error.Kyunam Jo2019-03-181-1/+1
| | | | Change-Id: Ic3ec1bfb150ec932e05ba5eda43537784f1fdcda
* docs: document a Python 3 migration planMike Frysinger2019-02-011-0/+32
| | | | | Bug: https://crbug.com/gerrit/10418 Change-Id: I72d82ce3a2d9af45d942bb10de82340110864ea5
* update markdown/help header formatMike Frysinger2018-10-101-28/+14
| | | | | | | Since gitiles recommends using # headers over ---/=== underlines, change the manifest-format.md over and all our help texts. Change-Id: I96391d41fba769e9f26870d497cf7cf01c8d8ab3
* manifest-format: convert to markdownMike Frysinger2018-10-052-99/+103
| | | | | | | The gitiles system doesn't render .txt files, so convert this to .md for better display online. Change-Id: Ie12e46daf008dd8c97ae2ffd21fb68bd948fe625
* manifest: Support a default upstream valueNasser Grainawi2018-05-091-0/+6
| | | | | | | It's convenient to set upstream for all projects in a manifest instead of repeating the same value for each project. Change-Id: I946b1de4efb01b351c332dfad108fa7d4f443cba
* docs: repo-hooks: fix cwd detailsMike Frysinger2018-04-251-3/+8
| | | | | | | The hooks are run from the top of the manifest checkout, not from the individual git repos. It's up to individual hooks to chdir as needed. Change-Id: I53325e0c3dcaa9c250b02b223e78d238d2cbd36d
* Add a way to override the revision of an <extend-project>Luis Hector Chavez2018-03-151-0/+4
| | | | | | | | This change adds support for the 'revision' attribute in <extend-project>. This avoids the need to perform a <remove-project> followed by a <project> in local manifests. Change-Id: Id2834fcfc1ae0d74b3347bed3618f250bf696b1f
* implement optional 'sync-tags' in the manifest fileYOUNG HO CHA2018-02-141-0/+6
| | | | | | | | Allow the 'default' and 'project' element in the manifest file to apply "--no-tags" option equivalent. Change-Id: I7e0f8c17a0e25cca744d45df049076d203c52ff5 Signed-off-by: YOUNG HO CHA <ganadist@gmail.com>
* document repo hooks mechanismMike Frysinger2017-11-101-0/+105
| | | | Change-Id: I9e25b92c846f887f515efcc706cf5a869645e0ec
* Adding include element into the top-level elementJiri tyr2017-05-271-1/+2
| | | | | | | | | | | | The documentation of the XML file format contains DTD which contains definition of all allowed elements and attributes. The "include" element is defined but it's not referenced from the top-level "manifest" element. This patch is adding the "include" element into the list of elements of the top-level "manifest" element. Change-Id: I33beb8ef2846bbf42ffd42e6ae6888828566d604
* manifest-format: fix EMPTY keyword usageMike Frysinger2016-12-281-10/+10
| | | | | | | | The keyword EMPTY doesn't use parens. BUG=git-repo:140 Change-Id: I7cd28a09c401520a72e5c244a77d9d70385f1b61
* implement optional 'pushurl' in the manifest fileSteve Rae2016-09-201-0/+7
| | | | | | | | Allow the 'remote' element in the manifest file to define an optional 'pushurl' attribute which is passed into the .git/config file. Change-Id: If342d299d371374aedc4440645798888869c9714 Signed-off-by: Steve Rae <steve.rae@raedomain.com>
* Improve documentation of manifest server RPC methodsDavid Pursehouse2016-04-131-2/+4
| | | | | | | Mention that the RPC endpoints are used when running repo sync with the --smart-sync and --smart-tag options Change-Id: I4b0b82e8b714fe923a5b325a6135f0128bf636ff
* Fix typos for manifest dtdKenny Ho2015-12-111-8/+8
| | | | Change-Id: If53721544eca570e2bcce4598cdc2670a679c681
* docs: add copyfile and linkfile elements descriptionRuslan Bilovol2015-09-101-1/+26
| | | | | | | | | | The "copyfile" element is available since 2009 and have been used in every Android manifest; the "linkfile" element is available since 2014. Now it's a good time to add both to the documentation Change-Id: Ia987edf5f69a006235fbd3f33b744e9794a6d964 Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
* Revert "Implementation of manifest defined githooks"v1.12.20Jonathan Nieder2015-03-171-14/+1
| | | | | | | | | | | | | | | This reverts commit 38e4387f8eb8cffd6359d726c38a7c524fef07e3. 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>
* Implementation of manifest defined githooksJimmie Wester2015-02-031-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Support specifying non-HEADS refs as upstreamNasser Grainawi2014-10-091-1/+1
| | | | | | | | | 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
* Merge "Add extend-project tag to support adding groups to an existing project"Conley Owens2014-09-181-0/+22
|\
| * Add extend-project tag to support adding groups to an existing projectJosh Triplett2014-06-201-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Enable transferring of attribute using command 'repo manifest -o -'Mani Chandel2014-07-241-6/+6
|/ | | | | | | | | | | '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
* Enable remotes to define their own revisionAnthony King2014-05-071-1/+7
| | | | | | | | | | | | 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
* Fix error in xml manifest doc.Warren Turkal2013-12-101-1/+1
| | | | | | | The docs on the annotations say that zero or more may exist as a child of a project, so that means that a "*" instead of a "?" should be used. Change-Id: Iff855d003dfb05cd980f285a237332914e1dad70
* Remove trailing whitespaceChirayu Desai2013-11-211-5/+5
| | | | Change-Id: I56bcb559431277d40070fa33c580c6c3525ff9bc
* Send reviews to a different branch from fetchBryan Jacobs2013-05-241-12/+24
| | | | | | | | This adds the ability to have reviews pushed to a different branch from the one on which changes are based. This is useful for "gateway" systems without smartsync. Change-Id: I3a8a0fabcaf6055e62d3fb55f89c944e2f81569f
* Allow mirror to be created in directories specified by 'path' attributeScott Fan2013-04-111-0/+7
| | | | | | | | | | | | | In some cases, especially when local manifest files exist, users may want to force the mirrored repositories to be created in folders according to their 'path' attribute in the manifest, rather than according to the name of the repositories. To enable this functionality for specified mirror, add a new attribute 'force-path' for that project in the manifest, set its value to 'true'. Change-Id: I61df8c987a23d84309b113e7d886ec90c838a6cc Signed-off-by: Scott Fan <fancp2007@gmail.com>
* Allow clone depth to be specified per projectDavid Pursehouse2013-04-101-0/+5
| | | | | | | | | | | If the clone-depth attribute is set on a project, its value will be used to set the depth when fetching the git. The value, if given, must be a positive integer. The value in the clone-depth attribute overrides any value given to repo init via the --depth command line option. Change-Id: I273015b3724213600b63e40cca4cafaa9f782ddf
* Add missing manifest format documentationDavid Pursehouse2013-01-291-0/+20
| | | | | | | Documentation of the "sync-j", "sync-c", "sync-s" and "upstream" attributes is missing/incomplete. Add it. Change-Id: I74977f819f603c520ef3818f85c3b51399cd2b94
* Represent git-submodule as nested projects, take 2Che-Liang Chiou2012-11-191-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Previous submission of this change broke Android buildbot due to incorrect regular expression for parsing git-config output. During investigation, we also found that Android, which pulls Chromium, has a workaround for Chromium's submodules; its manifest includes Chromium's submodules. This new change, in addition to fixing the regex, also take this type of workarounds into consideration; it adds a new attribute that makes repo not fetch submodules unless submodules have a project element defined in the manifest, or this attribute is overridden by a parent project element or by the default element.) We need a representation of git-submodule in repo; otherwise repo will not sync submodules, and leave workspace in a broken state. Of course this will not be a problem if all projects are owned by the owner of the manifest file, who may simply choose not to use git-submodule in all projects. However, this is not possible in practice because manifest file owner is unlikely to own all upstream projects. As git submodules are simply git repositories, it is natural to treat them as plain repo projects that live inside a repo project. That is, we could use recursively declared projects to denote the is-submodule relation of git repositories. The behavior of repo remains the same to projects that do not have a sub-project within. As for parent projects, repo fetches them and their sub-projects as normal projects, and then checks out subprojects at the commit specified in parent's commit object. The sub-project is fetched at a path relative to parent project's working directory; so the path specified in manifest file should match that of .gitmodules file. If a submodule is not registered in repo manifest, repo will derive its properties from itself and its parent project, which might not always be correct. In such cases, the subproject is called a derived subproject. To a user, a sub-project is merely a git-submodule; so all tips of working with a git-submodule apply here, too. For example, you should not run `repo sync` in a parent repository if its submodule is dirty. Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
* Minor documentation formatting and grammatical fixesDavid Pursehouse2012-11-141-3/+3
| | | | Change-Id: Iaac6377c787b3bb42242780e9d1116e718e0188d
* Fix documentation reference to local_manifest.xmlDavid Pursehouse2012-11-141-1/+1
| | | | | | | | | Documentation of the remove-project element still refers explicitly to local_manifest.xml. Change it to the more generic "a local manifest". Change-Id: I6278beab99a582fae26a4e053adc110362c714c2
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-05-14 03:44:04 +0000