phanii / git-repo Goto Github PK

Reported by Shawn Pearce <[email protected]> on Tue Mar 03 12:22:15 PST 2009
Source: JIRA REPO-14
Affected Version: 1.6.1

Create a mirror repository ("repo init --mirror").

% repo status
Traceback (most recent call last):
 File "/Volumes/Code - Case Sensitive/Android-Mirror/.repo/repo/main.py", line
202, in <m
   _Main(sys.argv[1:])
 File "/Volumes/Code - Case Sensitive/Android-Mirror/.repo/repo/main.py", line
186, in _M
   repo._Run(argv)
 File "/Volumes/Code - Case Sensitive/Android-Mirror/.repo/repo/main.py", line
96, in _Ru
   cmd.Execute(copts, cargs)
 File "/Volumes/Code - Case Sensitive/Android-Mirror/.repo/repo/subcmds/
status.py", line
   project.PrintWorkTreeStatus()
 File "/Volumes/Code - Case Sensitive/Android-Mirror/.repo/repo/project.py",
line 299, in
   if not os.path.isdir(self.worktree):
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
posixpath.p
   st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, NoneType found

Reported by Shawn Pearce <[email protected]> on Mon Feb 09 10:54:29 PST 2009
Source: JIRA REPO-8

repo should return useful exit codes and use stdout/stderr in a consistent way
in case someone wants to write a script that calls repo.

In Git we split commands into two different groups:

- plumbing:  These are scriptable commands that offer very small building
blocks of the Git system.  The command line options are usually only
--long-gnu-style and the input/output streams are formatted for easy machine
parsing, not human readability.  The commands, their options and their
stream formats are frozen in stone.

- porcelain: These are commands the human can invoke.  We can change their
options, use short options, have prettier output formats that are less
regular (and more difficult to parse).  These aren't meant to be invoked by
script writers.

We should consider doing the same thing with repo.  Especially since the
repo user interface may change and evolve a bit as we learn more about the
general Android workflow.

In terms of repo (since its all one big Python script) the plumbing commands
may just be small wrappers that convert command line arguments into
parameters for an internal "library" function.  Thus one can script repo by
either importing its library and calling the function directly in Python, or
by executing repo's plumbing command to get to the same function.  Human
commands might call multiple functions, and have a different entry point
that parses the command line arguments differently.

Reported by Shawn Pearce <[email protected]> on Mon Feb 09 10:38:15 PST 2009
Source: JIRA REPO-5

When talking about m/cupcake and m/donut, having them both in the same client
requires that we parse the manifest XML for both, so we can initialize them.

repo should parse all possible manifests and export the symbolic refs under
the m/ namespace whenever possible, to simplify compares and merges across
manifest revisions.

Reported by Brian Swetland <[email protected]> on Mon Feb 09 10:21:23 PST 
2009
Source: JIRA REPO-3

Quick fix:
- allow local_manifest.xml to indicate items to exclude from the main
manifest.xml

Best fix:
- allow a manifest.xml to specify that it's based on (or a subclass of, etc)
another manifest
- allow a manifest.xml to specify items to exclude from the manifests it
extends

Reported by Shawn Pearce <[email protected]> on Mon Mar 02 16:48:44 PST 2009
Source: JIRA REPO-11

OpenSSH on UNIX platforms can support multiplexing multiple ssh connections
onto a single TCP stream, saving the startup and teardown costs.

For applications like repo, fetching 120+ projects over SSH require forking
120+ ssh clients, probably all pointing at the same server.  Most of the time
is spent starting the SSH connection.  By using a ControlMaster connection
opened ahead of time these 120+ connections can send all of their data through
an existing stream, significantly reducing the wall-clock time required for a
no-op "repo sync".

Reported by Garret Pick <[email protected]> on Thu Feb 26 11:05:35 PST 2009
Source: JIRA REPO-9

From 
http://groups.google.com/group/repo-discuss/browse_thread/thread/20a4f3fb82f49cf
7
An error I saw from repo prune.  Note that the second time I ran it, it seemed
to work fine.

$ repo prune
Pending Branches

project bionic/
Traceback (most recent call last):
 File "/home/pickgr/master/.repo/repo/main.py", line 202, in <module>
   _Main(sys.argv[1:])
 File "/home/pickgr/master/.repo/repo/main.py", line 186, in _Main
   repo._Run(argv)
 File "/home/pickgr/master/.repo/repo/main.py", line 96, in _Run
   cmd.Execute(copts, cargs)
 File "/home/pickgr/.repo/repo/subcmds/prune.py", line 52, in Execute
 File "/home/pickgr/master/.repo/repo/project.py", line 126, in
commits
   '--')
 File "/home/pickgr/master/.repo/repo/project.py", line 1174, in
rev_list
   p.stderr))
error.GitError: platform/bionic rev-list ('--abbrev=8', '--abbrev-
commit', '--pr

$
$
$ repo prune
$ git status
# Not currently on any branch.
nothing to commit (working directory clean)
$

Reported by Dave Bort <[email protected]> on Mon Feb 09 10:36:52 PST 2009
Source: JIRA REPO-4

I've got a commit [in the repo development repository], and git diff m/
default.. shows the deltas I'm expecting, but "repo upload" just gives me "no
branches ready for upload".

$ git branch
* master

--
I'll bet its because .git/config doesn't have any remote or merge entries
listed for the branch, because you didn't create it with --track.

Make a new branch and merge your master branch into it:

 $ git branch --track for-upload m/default
 $ git checkout for-upload
 $ git merge master
 $ repo upload

This is why we have repo start (more or less), its shorter than git branch --
track.

--
Repo should provide a way to make a branch "ready for upload", and the "no
branches ready for upload" message should tell the user how to use the new
feature to recover from that state.

--
I was thinking that

repo start <branch> <sha1>

could do the repo start, and then the git reset --hard <sha1>.

It might also be nice to have a -p option (or some other way) of having it do
that on just one project.

Reported by Brian Swetland <[email protected]> on Mon Feb 09 10:17:17 PST 
2009
Source: JIRA REPO-2

I had this in my local-manifest.xml:
 <remove-project name="kernel/common"/>
 <project path="kernel" name="kernel/msm" revision="refs/heads/android-msm-
htc-2.6.24"/>

Which was a typo (I meant ...25):
bulgaria% repo sync
remote: Counting objects: 5319, done.
remote: Compressing objects: 100% (1260/1260), done.
remote: Total 4985 (delta 4119), reused 4538 (delta 3701)
Receiving objects: 100% (4985/4985), 1.07 MiB | 994 KiB/s, done.
Resolving deltas: 100% (4119/4119), completed with 200 local objects.
From git://android-git/public/kernel/msm
 * [new branch]      android-msm-2.6.25 -> korg/android-msm-2.6.25
 * [new branch]      android-msm-2.6.27 -> korg/android-msm-2.6.27
 * [new branch]      android-msm-htc-2.6.25 -> korg/android-msm-htc-2.6.25
 * [new branch]      msm-2.6.25 -> korg/msm-2.6.25
Traceback (most recent call last):
 File "/scratch/open/.repo/repo/main.py", line 202, in <module>
   _Main(sys.argv[1:])
 File "/scratch/open/.repo/repo/main.py", line 186, in _Main
   repo._Run(argv)
 File "/scratch/open/.repo/repo/main.py", line 96, in _Run
   cmd.Execute(copts, cargs)
 File "/scratch/open/.repo/repo/subcmds/sync.py", line 106, in Execute
   if not project.Sync_LocalHalf():
 File "/scratch/open/.repo/repo/project.py", line 591, in Sync_LocalHalf
   lost = self._revlist(not_rev(rev), HEAD)
 File "/scratch/open/.repo/repo/project.py", line 1000, in _revlist
   return self.work_git.rev_list(*args)
 File "/scratch/open/.repo/repo/project.py", line 1147, in rev_list
   p.stderr))
error.GitError: kernel/msm rev-list (u'^refs/remotes/korg/android-msm-
htc-2.6.24', 'HEAD'): fatal: bad revision '^refs/remotes/korg/android-msm-
htc-2.6.24'


after fixing the manifest, I got:

bulgaria% repo sync
error: refs/remotes/m/master points nowhere!
info: [kernel/msm] Discarding 2 commits


which seems to have fixed things, but sounded like it had a problem.  later
repo syncs did not fail

Reported by Shawn Pearce <[email protected]> on Mon Feb 09 10:46:28 PST 2009
Source: JIRA REPO-7

The pre-rebase hook can be used to prevent a user from rebasing changes they
have published to Gerrit.

The refs/published/$branch tip can be used to see what has been published and
forbid rebasing those parts, but we need a way to clear out refs/published if
the change is rejected in Gerrit and the user really wants to do an amend or
rebase to address review comments.

Reported by Jean-Baptiste Queru <[email protected]> on Tue Mar 03 12:13:17 PST 2009
Source: JIRA REPO-12
Affected Version: 1.6.1

I find that I'm running repo init every few hours while I work (whenever I
find myself in a situation I don't know how to recover from). I'd like to
avoid hitting the server each time, though, since it takes quite a while (and
uses some bandwidth).

Is there any way I could just keep a clean "reference" repo client (i.e. where
all I do is repo sync), and then repo init new clients from that one? That
way, creating new clients is just a bunch of local file copies, which should
be much faster than a network transfer.

Reported by mark gross <[email protected]> on Fri Feb 06 15:42:17 PST 2009
Source: JIRA REPO-1
Environment: Linux and mac os hosts.

Having named (tagged) versions of the core Android Open source project code is
needed for folks to build branches or patchsets of experimental work of the
core code base.

Of course the CTT needs to lay down tags periodically on known good enough
versions for everyone to use as baselines.

Reported by Shawn Pearce <[email protected]> on Mon Feb 09 10:43:15 PST 2009
Source: JIRA REPO-6

If a project hasn't been created by "repo sync" yet "repo status" should at
least print a message to let the user know the project is missing and needs to
be created by "repo sync".

Reported by Shawn Pearce <[email protected]> on Sat Feb 28 10:40:55 PST 2009
Source: JIRA REPO-10

From http://code.google.com/p/android/issues/detail?id=1675

repo should delete source directories of projects that get deleted from the
manifest

Repro:
-start with a master branch synced before cupcake was merged into master
-repo sync to the latest (which includes cupcake, and where a project was
moved around)
-try to build

Observed:
the old location of the project that was moved doesn't get cleared, causing
the build system to include makefiles for both the old and new location,
which creates a conflict and causes the build to fail.

Workaround:
Manually delete the offending directory

Note:
repo probably doesn't need full automation to detect the spurious
directories. The manifest could contain a list of known old project
locations that need to be deleted if they're present.

Reported by Shawn Pearce <[email protected]> on Tue Mar 03 12:17:23 PST 2009
Source: JIRA REPO-13
Affected Version: 1.6.1

If you have a manifest with no default element, and missing the necessary
revision or remote attributes on a project, a error.ManifestParseError is
raised, and it's not caught.

When it aborts there, it fails to update its clone of the manifest, so it'll
never get your fixes to add the missing bits, without manually poking at .repo