The revisionExpr field now holds an expression from the manifest,
such as "refs/heads/master", while revisionId holds the current
commit-ish SHA-1 of the revisionExpr. Currently that is only
filled in if the manifest points directly to a SHA-1.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The trick of looking at the reflog for the remote tracking branch
and only going back one commit works some of the time, but not all of
the time. Its sort of relying on the fact that the user didn't use
`repo sync -n` or `git fetch` to only update the tracking branches
and skip the working directory update.
Doing this right requires looking through the history of the SHA-1
source (what the upstream used to be) and finding a spot where the
DAG diveraged away suddenly, and consider that to be the rewind
point. That's really difficult to do, as we don't have a clear
picture of what that old point was.
A close approximation is to list all of the commits that are in
HEAD, but not the new upstream, and rebase all of those where the
committer email address is this user's email address. In most cases,
this will effectively rebase only the user's new original work.
If the user is the project maintainer and rewound the branch
themselves, and they don't want all of the commits they have created
to be rebased onto the new upstream, they should handle the rebase
on their own, after the sync is complete.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now feed Project a RemoteSpec, instead of the Remote directly
from the XmlManifest. This way the RemoteSpec already has the
full project URL, rather than just the base, permitting other
types of manifests to produce the URL in their own style.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We'll soon be supporting two different manifest formats, but we
can't immediately remove support for the current XML one that is
in wide spread use within Android.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way we can put it in another directory than the config file
itself, e.g. hide it inside ".git" when parsing a ".gitmodules"
file from the working tree.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This can be useful when pulling apart a configuration file, like
finding all entries which match submodule.*.*.
Signed-off-by: Shawn O. Pearce <sop@google.com>
These aren't that widely used, and actually make it difficult for
users to fully mirror a forest of repositories, and then permit
someone else to clone off that forest, rather then the original
upstream servers.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We haven't supported this in a while, but the parser was still here.
Its all dead code, so strip it out.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Extensive discussion with users lead to the fact that needing to
supply -a to view what they really wanted to see was just wrong.
Signed-off-by: Shawn O. Pearce <sop@google.com>
I only tested this with ssh://hostname/ style URLs, so I failed
to test ssh://user@hostname/ format, which failed if the hostname
portion was longer than 1 character.
Signed-off-by: Shawn O. Pearce <sop@google.com>
If the SSH URL doesn't contain a port number, but uses the ssh://
or git+ssh:// syntax we raised a Python runtime error due to the
'port' local variable not being assigned a value. Default it to
the IANA assigned port for SSH, 22.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Performance improvements in repo sync caused us to skip out of the
initial Sync_LocalHalf without ever running CopyFiles, so we didn't
create the top level Makefile in new clients whose manifest request
one with a <copyfile> element.
Now we run CopyFiles after the initial read-tree that populates
the project working directory.
Signed-off-by: Shawn O. Pearce <sop@google.com>
If the current branch is published, but all published commits are
merged into the manifest revision, but there is also at least one
unpublished commit on the current branch, we should rebase the
unpublished commit, rather than creating a merge commit.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The level 2 headings (denoted by ~) indent the heading two spaces,
but continue to use the bold formatter to offset them from the
other surrounding text.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Mac OS X sets TMPDIR to a very long path within /var, so long
that a socket created in that location is too big for a struct
sockaddr_un on the platform, resulting in OpenSSH being unable
to create or bind to a socket in that location.
Instead we try to use the very short and very common /tmp, but
fall back to the guessed default if /tmp does not exist.
Signed-off-by: Shawn O. Pearce <sop@google.com>
By creating a background ssh "control master" process which lives
for the duration of our sync cycle we can easily cut the time for
a no-op sync of 132 projects from 60s to 18s.
Bug: REPO-11
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way its clear the command did something, and reported
that it had nothing to show you, because you have no active
branches in this client.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Most projects will have their branch heads matching in all branches,
so switching between them should be just a matter of updating the
work tree's HEAD symref. This can be done in pure Python, saving
quite a bit of time over forking 'git checkout'.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This is mostly useful if the number of projects to switch is many
(e.g. all of Android) and a large number of them are behind the
current manifest revision. We wind up needing to run git just to
make the working tree match, and that often makes the command take
a couple of seconds longer than we'd like.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Its quite common for most projects to be matching the current
manifest revision, as most developers only modify one or two projects
at any one time. We can speed up `repo start foo` (that impacts
the entire client) by performing most of the branch creation and
switch operations in pure Python, and thus avoid 4 forks per project.
Signed-off-by: Shawn O. Pearce <sop@google.com>
When trying to read log output from many projects at once it can
be difficult to make sense of which messages came from where.
For many professional developers it is common to want to view the
last week's worth of your work, so you can write a weekly summary
of your activity for your status report.
This is easier with the new -p option:
repo forall -pc git log --reverse --since=1.week.ago --author=sop
produces a report of all commits written by me in the last week,
formatted in a paged output display, with headers inserted in
front of each project's output.
Where this can be even more useful is with git log's pickaxe,
e.g. now we can use:
repo forall -pc git log -Sbar v1.0..v1.1
to locate all additions or removals of the symbol 'bar' since v1.0,
up to and including v1.1. Before displaying the matching commits in
a project, a project header is shown, giving the user some context
information for the matching results.
Signed-off-by: Shawn O. Pearce <sop@google.com>
With the <remove-project> element we can remove projects, and
fully replace them with a different definition. So this note
is out of date.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Generally we only show the project path, relative from the top of the
client. Showing the project name may be confusing for the end-user.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This gives the user the last chance to confirm where the change is
going to be sent to. Knowing the review server URL will help the
user decide if continuing with the upload makes sense.
Signed-off-by: Shawn O. Pearce <sop@google.com>
These used to be used back when we had Gerrit 1.x support and used
HTTP based uploads to transmit changes for review. Since we moved
entirely to Gerrit 2.x, these are no longer called.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Its unlikely that a new version of repo will be delivered in any
given day, so we now check only once every 24 hours to see if repo
has been updated. This reduces the sync cost, as we no longer need
to contact the repo distribution servers every time we do a sync.
repo selfupdate can still be used to force a check.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Usually repo is upgraded only once a week, if that often. Most of
the time we invoke HasChanges on the repo project (or even on the
manifest project) the current HEAD will resolve to the same SHA-1
as the remote tracking ref, and there are therefore no changes.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The point of the progress meter is to let the user know that the
task is progressing, and give them a chance to estimate when it will
be complete. If the task completes in under 0.5 seconds then it
is sufficiently fast enough that the user doesn't need to be kept
up-to-date on its progress; in fact showing the meter may just slow
the task down waiting on the tty to redraw.
We now delay the progress meter 0.5 seconds (or 1 second if the
Python time.time() function isn't accurate enough) to avoid any
really fast tasks, like a no-op local sync.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The trace output often interfers with the progress meter, so its
easier to just disable the progress meter if trace is active.
Its already verbose enough to let the user know we are working,
which is all the progress meter is there for anyway.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The value of the varible TRACE was copied during the import, which
happens before the --trace option can be processed. So instead we
now use a function to determine if the value is set, as the function
can be safely copied early during import.
Signed-off-by: Shawn O. Pearce <sop@google.com>
These are not as expensive as spawning a git command, but they are
not free either. We want to keep track of how many times we wind
up calling them on any particular operation.
Signed-off-by: Shawn O. Pearce <sop@google.com>
If the m/BRANCH ref is already pointing at the value set in the
manifest there is no reason to set it again. Leave it alone,
thus saving a full fork+exec call.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now cache the output of `git config --list` for each of our
GitConfig instances in a Python pickle file. These can be read
back in using only the Python interpreter at a much faster rate
than we can fork+exec the git config process.
If the corresponding git config file has a newer modification
timestamp than the pickle file, we delete the pickle file and
regenerate it. This ensures that any edits made by the user
will be taken into account the next time we consult the file.
This reduces the time for a no-op repo sync from 0.847s to 0.269s.
Signed-off-by: Shawn O. Pearce <sop@google.com>
