tools/git-repo.git, branch v2.22

Add multi-manifest support with element

2022-02-17T21:57:55+00:00

To be addressed in another change: - a partial `repo sync` (with a list of projects/paths to sync) requires `--this-tree-only`. Change-Id: I6c7400bf001540e9d7694fa70934f8f204cb5f57 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/322657 Tested-by: LaMont Jones Reviewed-by: Mike Frysinger

Move local-manifest check to manifest_xml.py

2022-02-15T22:15:42+00:00

This removes the need for git_superproject to include manifest_xml, and puts the logic for local_manifest detection in one place. Change-Id: I4d33ded0542ceea4606a1ea24304f678de20c59e Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/330499 Tested-by: LaMont Jones Reviewed-by: Raman Tenneti

project.py: pass --recurse-submodules={value}

2022-02-10T23:57:45+00:00

If submodules is False, explicitly pass '=no'. Uninitialized submodules may cause the default option to fail. Change-Id: Ia00bcba5b69c4b65195f4c469c686a3ef9a4a3ad Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/330159 Reviewed-by: Xin Li Tested-by: LaMont Jones

project: mark gc.log as safe to discard when migrating .git/

2022-01-26T16:46:03+00:00

This is just a log file that, while useful for humans when gc aborts, doesn't contain any data, so it's safe to throw away. Bug: https://crbug.com/gerrit/15619 Change-Id: Ia95e0e281f52260668f7a80b5d5f990e32a8597a Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328999 Tested-by: Mike Frysinger Reviewed-by: Peter Kjellerstedt Reviewed-by: Mike Frysinger

init: add an option --enable-git-lfs-filter

2022-01-26T01:47:20+00:00

It was reported that git-lfs did not work with git-repo. Specifically, `git read-tree -u` run by `repo sync` would fail git-lfs's smudge filter. See https://github.com/github/git-lfs/issues/1422. In fact, by the time `git read-tree -u` is run, the repository is not bare. It is just that, the working directory is not the same as the .git directory. git-lfs's filter should work. No one seems to have delved into that issue. Today, with newer versions of git-repo and git-lfs, that issue will not reproduce. Tested with - git 2.33, git-lfs 2.13 on macOS - git 2.17, git-lfs 2.3 on ubuntu So, it seems fine to add an option --enable-git-lfs-filter, default to false, and stat that it may not work with older versions of git and git-lfs in the help doc. Bug: https://crbug.com/gerrit/14516 Change-Id: I8d21854eeeea541e072f63d6b10ad1253b1a9826 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328359 Tested-by: XD Trol Reviewed-by: Mike Frysinger

init: make bad --repo-rev settings more clear

2022-01-25T18:54:42+00:00

If the user passes a bad --repo-rev setting in a new checkout, add a tip to the error message that their option is probably bad instead of just saying "unable to resolve". If the user has already initialized a checkout, we'd display a raw traceback which would confuse them. Swallow that and also include the --repo-rev tip. Bug: https://crbug.com/gerrit/15610 Change-Id: I5d72513c7b37bf9bb5d19862fcdfaf0d1f44e886 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328820 Reviewed-by: Jack Neus Tested-by: Mike Frysinger

project: Ignore failure to remove the sample hooks

2022-01-22T06:13:10+00:00

Removing the sample hooks is just clean up, so if repo cannot remove a sample hook that should not cause it to fail. Change-Id: I716b977da091c22b8f53e134f4fbc114116f9a65 Signed-off-by: Peter Kjellerstedt Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328635 Reviewed-by: Mike Frysinger

branches: Fix "not in" handling

2022-01-21T17:20:21+00:00

If the branch is current, or present in less than half of the projects, list which projects it is *in*. Otherwise, correctly detect which projects (by relpath) it is not in. Previously, the "not in" path would incorrectly list all projects. Change-Id: Ia153856f577035a51f538b7bf5d3135b70c69d52 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328199 Tested-by: LaMont Jones Reviewed-by: Xin Li

project: store objects in project-objects directly

2022-01-19T17:24:51+00:00

In order to stop sharing objects/ directly between shared projects, we have to fetch the remote objects into project-objects/ manually. So instead of running git operations in the individual project dirs and relying on .git/objects being symlinked to project-objects/, tell git to store any objects it fetches in project-objects/. We do this by leveraging the GIT_OBJECT_DIRECTORY override. This has been in git forever, or at least since v1.7.2 which is what we already hard require. This tells git to save new objects to the specified path no matter where it's being run otherwise. We still otherwise run git in the project-specific dir so that it can find the right set of refs that it wants to compare against, including local refs. For that reason, we also have to leverage GIT_ALTERNATE_OBJECT_DIRECTORIES to tell git where to find objects that are not in the upstream remote. This way git doesn't blow up when it can't find objects only associated with local commits. As it stands right now, the practical result is the same: since we symlink the project objects/ dir to the project-objects/ tree, the default objects dir, the one we set $GIT_OBJECT_DIRECTORY to, and the one we set $GIT_ALTERNATE_OBJECT_DIRECTORIES to are actually all the same. So this commit by itself should be safe. But in a follow up commit, we can replace the symlink with a separate dir and git will keep working. Bug: https://crbug.com/gerrit/15553 Change-Id: Ie4e654aec3e1ee307eee925a54908a2db6a5869f Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328100 Reviewed-by: Jack Neus Tested-by: Mike Frysinger

project: move --reference handling to project-objects

2022-01-13T18:27:28+00:00

When using --reference, the path is written to objects/info/alternates. The path is accessed inconsistently -- sometimes through projects/ (via self.gitdir) and sometimes through project-objects/ (via self.objdir). This works because projects/.../objects is a symlink to the objects dir under project-objects/. Change all accesses to go through self.objdir. This will allow us to stop symlinking projects/.../objects without the reference dir logic breaking. The projects/ path is going to use its alternates file for its own needs. Bug: https://crbug.com/gerrit/15553 Change-Id: I6b452ad1aaffec74ecb7ac1bb9baa3a3a52e076c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/328099 Tested-by: Mike Frysinger Reviewed-by: Jack Neus