tools/git-repo.git/project.py, branch v2.19

project: migrate worktree .git/ dirs to symlinks

2021-12-01T15:27:16+00:00

Historically we created a .git/ subdir in each source checkout and symlinked individual files to the .repo/projects/ paths. This layer of indirection isn't actually needed: the .repo/projects/ paths are guaranteed to only ever have a 1-to-1 mapping with the actual git checkout. So we don't need to worry about having files in .git/ be isolated. To that end, change how we manage the actual project checkouts from a dir full of symlinks (and a few files) to a symlink to the internal .repo/projects/ dir. This makes the code simpler & faster. The directory structure we have today is: .repo/ project-objects/chromiumos/third_party/kernel.git/ projects/src/third_party/kernel/ v3.8.git/ config description -> …/project-objects/…/config FETCH_HEAD HEAD hooks/ -> …/project-objects/…/hooks/ info/ -> …/project-objects/…/info/ logs/ objects/ -> …/project-objects/…/objects/ packed-refs refs/ rr-cache/ -> …/project-objects/…/rr-cache/ src/third_party/kernel/ v3.8/ .git/ config -> …/projects/…/v3.8.git/config description -> …/project-objects/…/v3.8.git/description HEAD hooks/ -> …/project-objects/…/v3.8.git/hooks/ index info/ -> …/project-objects/…/v3.8.git/info/ logs/ -> …/projects/…/v3.8.git/logs/ objects/ -> …/project-objects/…/v3.8.git/objects/ packed-refs -> …/projects/…/v3.8.git/packed-refs refs/ -> …/projects/…/v3.8.git/refs/ rr-cache/ -> …/project-objects/…/v3.8.git/rr-cache/ The directory structure we have after this commit: .repo/ src/third_party/kernel/ v3.8/ .git -> …/projects/…/v3.8.git Bug: https://crbug.com/gerrit/15273 Change-Id: I9dd8def23fbfb2f4cb209a93f8b1b2b24002a444 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/323695 Reviewed-by: Mike Nichols Reviewed-by: Xin Li Tested-by: Mike Frysinger

sync: Handle tag ref in "upstream" field

2021-11-16T20:43:57+00:00

repo sync only handles a git tag properly when it is in the "revision" field. However, "revision locked manifests" (`repo manifest --revision-as-HEAD`) specifies the tag in the "upstream" field. The issue is that this tag is not fetched. Only the commit that the tag points to is fetched. This cases issues as self._CheckForImmutableRevision() runs and comes to the conclusion that the tag was changed while in fact, it was just not fetched. This causes a full sync. File docs/manifest-format.md, section Element-project: > 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. Project elements not setting their own upstream will inherit this value. Change-Id: I0507d3a5f30aee8920a9f820bafedb48dd5db554 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/323620 Reviewed-by: Mike Frysinger Tested-by: Robin Schneider

project: init hooks in objdir only

2021-11-15T19:50:18+00:00

objdir is the .repo/project-objects/ dir based on the remote path. gitdir is the .repo/projects/ dir based on the local source checkout path. When we setup the gitdir, we symlink "hooks" to the one in the objdir. But when we go to initialize the hooks, we do it via gitdir. There is a 1-to-many mapping from project-objects to projects, so initializing via gitdir can be repetitive. Collapse the hook init logic to the objdir init path. Change-Id: I828fca60ce6e125d6706c709cdb2797faa40aa50 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/323815 Reviewed-by: Raman Tenneti Tested-by: Mike Frysinger

project: fix format string in error message

2021-11-05T16:59:14+00:00

BUG=None Change-Id: I0b195fd919c6db8cb3547e8d6f4c733f2bd4a535 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/322735 Tested-by: LaMont Jones Reviewed-by: Xin Li

Update revisionId if required when using extend-project

2021-09-28T20:12:00+00:00

When a hard revision ID is provided in a regular project tag then the revisionId is updated as well if it is a commit hash. The difference is that if the revisionExpr is a commit, git-repo needs to update refs/remotes/m/master with update-ref not symbolic-ref, as the latter must refer to another ref, not to a specific commit. Change-Id: I215a62dabb30225e480ad2c731416d775fc0c750 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/310963 Tested-by: Michael Kelly Reviewed-by: Mike Frysinger

Add 'dest-path' to extend-project to support changing path

2021-09-28T20:12:00+00:00

This allows us to move the repository to a new location in the source tree without having to remove-project + add a new project tag. Change-Id: I4dba6151842e57f6f2b8fe60cda260ecea68b7b4 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/310962 Reviewed-by: Mike Frysinger Tested-by: Michael Kelly

make file removal a bit more robust

2021-09-28T16:06:50+00:00

Some of the file removal calls are subject to race conditions (if something else deletes the file), so extend our remove API to have an option to ignore ENOENT errors. Then update a bunch of random call sites to use this new functionality. Change-Id: I31a9090e135452033135337a202a4fc2dbf8b63c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/319195 Reviewed-by: Sean McAllister Tested-by: Mike Frysinger

repo: properly handle remote annotations in manifest_xml

2021-07-23T18:03:11+00:00

BUG=b:192664812 TEST=tests/ Change-Id: I1aa50260f4a00d3cebbd531141e1626825e70127 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/312643 Tested-by: Jack Neus Reviewed-by: Mike Frysinger

Force a fetch when superproject has a newer SHA1 for remote branch.

2021-07-20T23:26:01+00:00

For older git-repo versions, we might have only fetched the SHA1 revision that was provided by the project, but have remote branch left intact as long as they exist. When the remote branch become stale, some repo operations like rebase would fail, and repo sync would not correct this situation. Fix this by tightening the requirement to also require the superproject provided SHA1 be an ancestor or equal to the tip-of-tree of the remote branch. Bug: [google internal] b/193798453 Change-Id: Ie34c5d860dabb1cbd9f822da929088ec69c79cf6 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/312642 Tested-by: Xin Li Reviewed-by: Raman Tenneti

Fix an issue when syncing with --use-superproject and clone bundles.

2021-06-30T15:31:15+00:00

It is possible that a clone bundle contained the object referenced by the branch in the manifest and in the superproject, but not the branch itself (for example, the branch may be newly created from an existing branch, or is not vislble to the user downloading the clone bundle). When --use-superproject is enabled, because we are overriding revisionExpr with the SHA1 revision provided by the superproject, the verification step would succeed, but because the expected branch do not exist, it would confuse git-repo at a later time, as it is expecting the remote branch to exist in the local clone. In project.py, fix this by making SetRevisionId() to always remember the actual branch name and verify it in _CheckForImmutableRevision() so that we only skip the fetch step when both objects exists locally. Bug: [google internal] b/191974277 Change-Id: I49d3ca0667f524c8c45f416492faf95b1dd822fb Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/310802 Reviewed-by: Raman Tenneti Reviewed-by: Mike Frysinger Tested-by: Xin Li