So I decided to sort out giving the teams access to their git repositories. It's a work in progress at the moment, but there is currently a fairly major show-stopper involving the IDE.
All of the team git repositories can currently be accessed by people in the "mentors" group (a.k.a. 'blueshirts') through the following URL:
(The 'master' may disappear in the future from these URLs, who knows. Don't expect it to stay the same until we actually ship.)
Mentors can both push and pull through that. Pushing to that repository etc works fine. However, the IDE appears to get extremely confused. Here's some things that I have done:
* git clone 1000/master/vision-test.git over http * Push a commit to that repository over http * Click on the file I edited (robot.py) in the IDE * Observed that the changes I made to the file were not there. * Logged in and out of the IDE, observed that the changes still weren't visible in the IDE * Cloned the repository over http again to make doubly sure that my commit had actually been pushed * Edited robot.py in the IDE (on a different line), and committed that * Observed that the commit from the IDE got completely lost -- not visible in either the master git repository nor the IDE * (Tried editing the file again in the IDE to see the same results)
So it seems that the IDE does not enjoy this situation. I am not happy with shipping git access out to teams until this situation is resolved.
Furthermore, when the IDE creates a new git repository, please can it configure receive.denyNonFastForwards to "true" in that repository. Allowing non-fast-forwards is generally a bad idea, and is especially so when exposing these to newbies. (All our /srv/git repositories will deny non-fast-forwards.)
On Mon, Nov 7, 2011 at 4:07 AM, Rob Spanton <rspan...@zepler.net> wrote: > Furthermore, when the IDE creates a new git repository, please can it > configure receive.denyNonFastForwards to "true" in that repository.
I've raised this as trac ticket 982 [1], so it should be dealt with fairly soon. It's worth noting that I'd also raised the external repo access as #980 [2].
On Mon, 2011-11-07 at 19:31 +0000, Peter Law wrote: > On Mon, Nov 7, 2011 at 4:07 AM, Rob Spanton <rspan...@zepler.net> wrote: > > Furthermore, when the IDE creates a new git repository, please can it > > configure receive.denyNonFastForwards to "true" in that repository.
> I've raised this as trac ticket 982 [1], so it should be dealt with > fairly soon. It's worth noting that I'd also raised the external repo > access as #980 [2].
Just in case skim-readers are misled -- these tickets that Peter has registered are not to do with the issue that's blocking the git repositories being accessible. (Go back and read my original post to see the main issue.)
On Mon, 2011-11-07 at 04:07 +0000, Rob Spanton wrote: > * Observed that the commit from the IDE got completely lost -- not > visible in either the master git repository nor the IDE > * (Tried editing the file again in the IDE to see the same > results)
Here's some log output from the IDE that one gets when opening a file from the repository I pushed into http://pastebin.com/K0QQxqcD
Note that it attempts to push into the master repo (which is going to fail, because it's behind), fails, and then doesn't really appear to change its behaviour despite this...
On Tue, Nov 8, 2011 at 4:28 PM, Rob Spanton <rspan...@zepler.net> wrote: > On Mon, 2011-11-07 at 04:07 +0000, Rob Spanton wrote: >> * Observed that the commit from the IDE got completely lost -- not >> visible in either the master git repository nor the IDE >> * (Tried editing the file again in the IDE to see the same >> results)
> Here's some log output from the IDE that one gets when opening a file > from the repository I pushed into http://pastebin.com/K0QQxqcD
Thanks, this pretty much confirms what I'd expected having eyeballed the user repos. I found that the commit you made had been fetched but not merged, so it knew what was in the remote repo. Furthermore the changes had been applied & staged so that the working tree matched it, but didn't have your changes in the local branch history. How this occurred I've no idea.
Alistair said he'd have a look since he's the git guru. I'm wondering now whether the shared nature of the repos would affect this at all.
> * Observed that the commit from the IDE got completely lost -- not > visible in either the master git repository nor the IDE > * (Tried editing the file again in the IDE to see the same > results)
Based on the state that the repos are in, I think that we can fix them by running: $ git reset HEAD on each one. I've created a script (optimus:/home/plaw/tidy) based on the repack script that's poped up in ide/repos that could do this.
If one of the www-admins could run this on repos/1000/ (this is where it's currently targetted) to prove it works this would be appreciated.
I wrote: > Based on the state that the repos are in, I think that we can fix them > by running: > $ git reset HEAD > on each one.
Further investigations into some of the other repos that aren't working shows that while this is one of the issues in the vision-test repo, it isn't the main issue that's causing the issues.
I've created (yet) another trac ticket (#986, [1]) that actually tracs this issue.
I wrote: > So it seems that the IDE does not enjoy this situation. I am not > happy with shipping git access out to teams until this situation is > resolved.
These issues are now resolved. I've reconfigured all the existing git repositories as necessary, and the IDE now configures new git repositories in the right way.
Team git repository access is now live and documented [1].
Please note that the URL format has changed since my first post in this thread. I employed some mod_rewritage to remove the superflous 'master' component of the URLs.
Rob wrote: > Team git repository access is now live and documented [1].
On the linked doc page:
> To get your code onto your robot, you will need to use the IDE's export feature as usual.
I'd like to remove this requirement, and to that end I'd already created a helper within the IDE (ages back). After they've pushed, there is an endpoint 'proj/zip' that will create the zip they want and redirect them to it. Currently it expects input in the same format as the rest of the IDE, but this could probably be wrapped if we wanted to offer this functionality.
> Rob wrote: >> Team git repository access is now live and documented [1]. I wrote: > On the linked doc page: >> To get your code onto your robot, you will need to use the IDE's export feature as usual.
> I'd like to remove this requirement, and to that end I'd already > created a helper within the IDE (ages back). After they've pushed, > there is an endpoint 'proj/zip' that will create the zip they want and > redirect them to it. Currently it expects input in the same format as > the rest of the IDE, but this could probably be wrapped if we wanted > to offer this functionality.
I've now moved this to being a new trac ticket #1054 [1].
