Migration to Git

[Andrew Gerrand]

Hi contributors,

As you might have noticed, the migration to Git and GitHub is underway.

What is done:

The core repository has moved:

  https://go.googlesource.com/go (canonical)

  https://github.com/golang/go (mirror)

The sub-repositories have moved:

  https://go.googlesource.com/tools

  https://github.com/golang/tools

  (and so on, for s/tools/REPO/)

And the golang.org/x/... redirects have been updated.

The issue tracker has moved:

  https://github.com/golang/go/issues

As with the previous tracker, this should be used for tracking sub-repo issues also.

There is a new build dashboard monitoring the git repos:

  https://build.golang.org/git/

(This will replace the current dashboard after the 1.4 release.)

The new code review system is up:

  https://go-review.googlesource.com

The code review tool is available:

  go get golang.org/x/review/git-review

(Although the documentation is not ready yet, my apologies.)

There are still many things to be done. Among them:

- Update contributor docs.

- Update source installation docs.

- Update the various README files.

- Update the various golang.org/change/... shortcuts

- Migrate the go-wiki to github.com/golang/go/wiki

- The dashboard builders aren't building sub-repos properly.

We're aware of these things, and we have them under control.

Things may be a bit rocky for a few days.

With that said, if you see something you think might be broken or wrong, please reply to this thread.

Note that we are still in the pre-1.4 freeze.

We are going to cut the 1.4 release from the Mercurial repos in the usual way, and then apply the changes (if any) to the git repos.

Andrew

[Yassine Ennebati]

Great work ! Thanks

[mattn]

I pushed patch of windows fix for git-review.

https://go-review.googlesource.com/#/c/1177/

How to post this to golang-codereviews? git review mail ? Yes, I did already.

[Jan Mercl]

On Mon Dec 08 2014 at 8:47:25 Andrew Gerrand <a...@golang.org> wrote:

With that said, if you see something you think might be broken or wrong, please reply to this thread.

I checked one issue[0] I've reported recently and it seems the migrated[1] report text is cut in half, approximately. As the missing parts are also the "What happened" and "What should have happened instead" reproduction steps, the new version of the issue is no more useful.

  [0]: https://code.google.com/p/go/issues/detail?id=9099

  [1]: https://github.com/golang/go/issues/9099

-j

[Andrew Gerrand]

Well, that's a bother!

I've fixed the comment; nothing was lost, it was just a < symbol opening an HTML tag that was never closed.

Details: we switched from using a markdown ``` to a <pre> tag somewhere down the migration process, and that's when the markdown converter's heuristics stopped escaping the <. I'll find comments of this nature and fix them. (I've fixed yours.)

[stemm...@gmail.com]

Nice work, thanks!

I noticed that all the tags in the git repo are lightweight tags, however annotated tags are recommended for tagging releases[0]. Lightweight tags are ignored when, for example, using git describe. Was this done intentionally? It might not be so easy to fix this now that the repo is public as git will never replace existing tags locally when they are changed in a remote. However, maybe this could be changed for future releases?

- Joël

[0]: http://git-scm.com/docs/git-tag

[Pierre Durand]

On branch release-branch.go1.3, files in /bin or /pkg are not git ignored.

Le lundi 8 décembre 2014 08:47:26 UTC+1, Andrew Gerrand a écrit :

[Jan Mercl]

On Mon Dec 08 2014 at 10:27:45 Andrew Gerrand <a...@golang.org> wrote:

I've fixed the comment; nothing was lost, it was just a < symbol opening an HTML tag that was never closed.

Details: we switched from using a markdown ``` to a <pre> tag somewhere down the migration process, and that's when the markdown converter's heuristics stopped escaping the <. I'll find comments of this nature and fix them. (I've fixed yours.)

Thank you very much.

-j 

[David Symonds]

`git describe` does use lightweight tags if you pass it --tags or
--all, and they work fine as refs in every explicit situation. It's
certainly possible that we'll use annotated tags in the future; is
there some other particular reason you want annotated tags? (e.g. I
doubt we'll be signing tags.)

[Andrew Gerrand]

The HTML entity escaping issue is quite widespread throughout the issues. I am going to make the go GitHub repo private for now, so that I can work with GitHub to correct this.

[stemm...@gmail.com]

I'm aware of the --tags flag, the reason I mentioned it is because annotated tags are commonly used in these cases. Even if you don't sign tags, an annotated tag is created as its own object in the git database. This means the tag will have an author and timestamp associated to it (otherwise you'd see the author and timestamp of the commit that was tagged). Not that big of an issue for me personally, but I thought I might as well mention it since the migration just happened.

[David Symonds]

On 8 December 2014 at 20:48, <stemm...@gmail.com> wrote:

> I'm aware of the --tags flag, the reason I mentioned it is because annotated
> tags are commonly used in these cases. Even if you don't sign tags, an
> annotated tag is created as its own object in the git database. This means
> the tag will have an author and timestamp associated to it (otherwise you'd
> see the author and timestamp of the commit that was tagged). Not that big of
> an issue for me personally, but I thought I might as well mention it since
> the migration just happened.

Yes, I understand that you get those things from annotated tags. I
don't think it matters to the Go project, though. Just curious if you
had a specific use case in mind.

[Andrew Gerrand]

The issues have been fixed up and the repo is once again public. Thanks all.

[pie...@plyce.com]

On the go1.3 branch, files in /bin or /pkg are not git ignored.

[roger peppe]

One issue that I'll mention in case you're not
aware of it is that the source code links
from golang.org don't seem to work any more.

For instance, I get a file not found error from
http://golang.org/src/net/http/server.go

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Andrew Gerrand]

Thanks for pointing that out, Rog. It should be fixed.

[Brendan Tracey]

On google code, I had open some issues and starred others. On github, I am not subscribed to any issues. Should I be, or is this an unfortunate loss in the transfer?

[alb.do...@gmail.com]

Should all the comments containing '<' be fully visible on github now? Because I randomly found one that
seems to be currently cut in half.

[minux]

Could we make github issues and comments still go to the golang-bugs mailing list?

[Russ Cox]

On Mon, Dec 8, 2014 at 3:20 PM, minux <mi...@golang.org> wrote:

Could we make github issues and comments still go to the golang-bugs mailing list?

Do you know how to do that? I couldn't figure it out. It looks like maybe you just have to 'Watch' the repo yourself. That might be more useful anyway, since Reply will work.

​

[Sebastien Douche]

On Mon, Dec 8, 2014 at 9:25 PM, Russ Cox <r...@golang.org> wrote:
>> Could we make github issues and comments still go to the golang-bugs mailing list?
>
> Do you know how to do that?

GitHub -> Settings -> Webhooks & Services -> Add Service -> Email

Same steps for IRC or Twitter.

--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche

[Russ Cox]

On Mon, Dec 8, 2014 at 3:47 PM, Sebastien Douche <sdo...@gmail.com> wrote:

On Mon, Dec 8, 2014 at 9:25 PM, Russ Cox <r...@golang.org> wrote:
>> Could we make github issues and comments still go to the golang-bugs mailing list?
>
> Do you know how to do that?

GitHub -> Settings -> Webhooks & Services -> Add Service -> Email

Same steps for IRC or Twitter.

I did that and it seemed to have no effect. I can't for the life of me figure out how to "hook" it up to something. In any event, https://api.github.com/hooks suggests that it doesn't support the issue and issue_comment events, so probably that's not useful. It may be that we should retire golang-bugs and just have people 'Watch' the repo. That wasn't an option on code.google.com/p/go, hence the list. One less moving part doesn't seem like a bad thing.

Russ

[Michael Hudson-Doyle]

minux <mi...@golang.org> writes:

> Could we make github issues and comments still go to the golang-bugs
> mailing list?

Relatedly, would it be possible to set up a mailing list that gets
commit mails for the repo? AIUI, this is something a repository admin
has to do:

https://help.github.com/articles/receiving-email-notifications-for-pushes-to-a-repository/

(if there is some way I can subscribe to such mails without a repo admin
doing anything, I'd love to hear about it)

Cheers,
mwh

[minux]

It seems the emails generated by gerrit is not ordered correctly, which makes it hard to follow the review on the golang-codereviews mailing list.

[minux]

On Dec 8, 2014 4:27 PM, "Michael Hudson-Doyle" <michael...@canonical.com> wrote:
> minux <mi...@golang.org> writes:
> > Could we make github issues and comments still go to the golang-bugs
> > mailing list?
> Relatedly, would it be possible to set up a mailing list that gets
> commit mails for the repo? 

There is a golang-commits mailing list for that purpose, but I don't know if that will also be deprecated after the github move.

I assume gerrit can generate emails for every commit.

[Ian Lance Taylor]

On Mon, Dec 8, 2014 at 2:02 PM, minux <mi...@golang.org> wrote:
>
> It seems the emails generated by gerrit is not ordered correctly, which
> makes it hard to follow the review on the golang-codereviews mailing list.

Every contributor is being moderated on the golang-codereviews list
for the first message they send. I think that once that clears up
most reviews will be ordered as they should.

Ian

[minux]

It seems my own comments to issues will not be sent as email even if I watched the repo

for all "notifications".

so I still prefer the golang-bugs mailing list where i can search everything in a single place.

[minux]

On Mon, Dec 8, 2014 at 5:06 PM, minux <mi...@golang.org> wrote:

On Dec 8, 2014 4:27 PM, "Michael Hudson-Doyle" <michael...@canonical.com> wrote:
> minux <mi...@golang.org> writes:
> > Could we make github issues and comments still go to the golang-bugs
> > mailing list?
> Relatedly, would it be possible to set up a mailing list that gets
> commit mails for the repo? 
There is a golang-commits mailing list for that purpose, but I don't know if that will also be deprecated after the github move.

Update: the mailing list is golang-checkins, not golang-commits.

[Andrew Gerrand]

On 9 December 2014 at 13:09, minux <mi...@golang.org> wrote:

so I still prefer the golang-bugs mailing list where i can search everything in a single place.

I'm inclined to agree, but I don't think GitHub supports it.

[minux]

Could we disable github comments on commits?

comments should be posted to the gerrit, IMO.

[Russ Cox]

On Mon, Dec 8, 2014 at 10:40 PM, minux <mi...@golang.org> wrote:

Could we disable github comments on commits?

comments should be posted to the gerrit, IMO.

I didn't know that was a thing. If you tell me how, I will do it. :-)

Or we could have our GitHub bot watch for those comments and relay them to Gerrit.

Russ

[Nathan Youngman]

If the webhook thing doesn't work, one possibility would be to setup the GopherBot user (https://github.com/gopherbot) to watch the repository with email notifications.

It's possible to add another email address, like golang-checkins:

https://github.com/settings/emails

And send email for all notifications for watched repositories:

https://github.com/settings/notifications

Of course individuals can do this as well.

Nathan.

[Nathan Youngman]

I've never seen a setting to disable comments on commits. Might want to see wait-and-see because commenting on commits outside of pull requests may not be that common.

With regards to the watch -> email, that will include notifications of issues and issue comments. It's probably better to do email through Gerrit.

Nathan.

[minux]

Andrew, https://code.google.com/p/go/issues/detail?id=7857#c4

is missing on the respective github issue: golang.org/issue/7857.

[Brad Fitzpatrick]

Not too surprising given the timestamp. It came in during the migration.

On Mon, Dec 8, 2014 at 10:49 PM, minux <mi...@golang.org> wrote:

Andrew, https://code.google.com/p/go/issues/detail?id=7857#c4

is missing on the respective github issue: golang.org/issue/7857.

--

[Michael Hudson-Doyle]

minux <mi...@golang.org> writes:

> On Dec 8, 2014 4:27 PM, "Michael Hudson-Doyle" <michael...@canonical.com>
> wrote:
>> minux <mi...@golang.org> writes:
>> > Could we make github issues and comments still go to the golang-bugs
>> > mailing list?
>> Relatedly, would it be possible to set up a mailing list that gets
>> commit mails for the repo?
> There is a golang-commits mailing list for that purpose, but I don't know
> if that will also be deprecated after the github move.

Ah, I'll keep an eye on that (well, -checkins).

> I assume gerrit can generate emails for every commit.

Ah yes, it can, but including diffs in the email requires a gerrit
config change IIRC.

Cheers,
mwh

[minux]

Hi Andrew,

After spent past several hours trying to hack a script that could reproduce

the exact same git repository, I finally understand the task is far from trivial.

Thanks.

For the record, it seems the following transformations has been applied:

1. golang-hg <sha1> header

2. remove Committer: from commit message, add committer header

3. Replaces Updates/Fixes issue X with Updates/Fixes #X.

4. s/https?:\/\/codereview.appspot.com\//https:\/\/golang.org\/cl\//g

5. s/\n\n\n+/\n\n/g.

Btw, I found a bug in the git migration:

git commit 2261021be1b7ecc0c0fbd4a62250e2dfe5b81eb5, hg commit ae1b85976f27b92c0dbc331ff7f6f775c8eea5a6

the committer should be rsc, but the git records iant as committer. It is because "Committer: " line in the undo CL message.

The "Committer: " should be the last line to take effect.

[David du Colombier]

Andrew,

Is there a way to set the labels on the GitHub issue tracker? They
seem read only.

--
David du Colombier

[Scott Redig]

I've noticed some non-critical problems with the labels in the issue tracker.

https://github.com/golang/go/labels

It looks like github's default labels are present in addition to the converted labels.  This has lead to the duplicate of "help wanted" (github default) verses "helpwanted" (imported).  "bug", "enhancement", and "question" are github defaults but have no open or closed issues on them.  It would also probably be a good idea to to apply github's existing color scheme to the labels, eg, make bug tags red.  There's also a little tag duplication from the converted tags:

"compiler-bug" (4 closed) vs "compilerbug" (23 open, 301 closed)

"package-bug" (7 closed) vs "packagebug" (12 open, 168 closed)

"package-change" (1 closed) vs "packagechange" (21 open, 82 closed)

"prioritysomeday" (1 closed) vs 'priority-someday" (81 open, 60 closed)

"go.talks" (1 closed) vs "repo-talks" (9 open, 1 closed)

There's also several labels which are only used in one issue:

-firstworldproblems
-ponies

-mystery

Scott

With that said, if you see something you think might be broken or wrong, please reply to this thread.

Note that we are still in the pre-1.4 freeze.

We are going to cut the 1.4 release from the Mercurial repos in the usual way, and then apply the changes (if any) to the git repos.

Andrew

[Fabrizio Milo aka misto]

- Migrate the go-wiki to github.com/golang/go/wiki

Will this be a manual process or will it be done with a script ?

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
LinkedIn: http://linkedin.com/in/fmilo
Twitter: @fabmilo
Github: http://github.com/Mistobaan/
-----------------------
Simplicity, consistency, and repetition - that's how you get through.
(Jack Welch)
Perfection must be reached by degrees; she requires the slow hand of
time (Voltaire)
The best way to predict the future is to invent it (Alan Kay)

[Andrew Gerrand]

You need to be a collaborator on the golang/go project to edit issue labels. We will be adding people who were "committers" on Google Code as collaborators on GitHub, but we're not quite ready to do that yet.

[Andrew Gerrand]

That's an unfortunate bug, but it's too late for us to fix it now. :-(

I can send you the script we used to do the conversion, if you're interested.

[Andrew Gerrand]

On 10 December 2014 at 04:12, Scott Redig <lare...@gmail.com> wrote:

I've noticed some non-critical problems with the labels in the issue tracker.

https://github.com/golang/go/labels

Yep, we intend to rationalise these soon. 

 

[Liam]

At least 5 hrefs to the issue tracker on https://golang.org/project/ need to be updated.

[minux]

On Tue, Dec 9, 2014 at 4:40 PM, Andrew Gerrand <a...@golang.org> wrote:

That's an unfortunate bug, but it's too late for us to fix it now. :-(

It's not a big problem though. :)

I can send you the script we used to do the conversion, if you're interested.

Although I've hacked one for my own forks, I still appreciate if the official script

could be released. I know other people that use forks to develop large-scale

changes and releasing the official script used to do the translation could

help them to migrate to git. Or I can clean up my script and release them.

(my approach is a bit quick-n-dirty, because I couldn't figure out how to insert

the golang-hg header with git fast-import, I patched git-2.2.0/fast-import.c to add

a dedicate command for that. I'm probably missing something.)

Thanks for the work!

[Nathan Youngman]

How do people become "committers"?

Nathan.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-dev/T3nDf-QqCrU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Nathan Youngman 
Email: he...@nathany.com
Web: http://www.nathany.com

[Brad Fitzpatrick]

We grant it to people after a period of sustained contributions.

You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Andrew Gerrand]

I believe the official line is "You become a committer when we get tired of submitting your changes for you."

In the new gerrit world they are known as 'approvers' and on github 'collaborators'.

[minux]

On Tue, Dec 9, 2014 at 7:12 PM, Andrew Gerrand <a...@golang.org> wrote:

I believe the official line is "You become a committer when we get tired of submitting your changes for you."

I'm curious. As submitting changes in Gerrit is just one or two? clicks, will the bar become (even implicitly) higher

after the transition to git?

[Andrew Gerrand]

Probably. It doesn't really matter.

In other open source projects, being a "committer" was a source of pride, largely because they didn't use code review. If you had the commit bit, it meant you were trusted enough to commit your changes directly to the repo.

In the Go project everyones code is reviewed, so the commit bit (or, rather, "approver" status) is more about convenience than anything else.

[Andrew Gerrand]

In this new world, though, the approver status on Gerrit and collaborator status on GitHub have different permissions. The former allows you to submit code, and the latter allows you to edit issue labels, so there's no reason they should be tightly coupled other than consistency. With that said, the roles and permissions were conflated in the old world and everything worked fine, so I'm inclined to leave it that way.

[Nathan Youngman]

There are exp/fsnotify bugs that I think can be closed, eg.

https://github.com/golang/go/issues/8147

Guess I'll need to do some commits to Go to gain collaborator status. :-D

[Russ Cox]

On Tue, Dec 9, 2014 at 7:43 PM, Nathan Youngman <he...@nathany.com> wrote:

There are exp/fsnotify bugs that I think can be closed, eg.

https://github.com/golang/go/issues/8147

Guess I'll need to do some commits to Go to gain collaborator status. :-D

Please don't. It's not a game.

Russ

[Nathan Youngman]

Yah. I wasn't being serious.

As far as tickets for exp/fsnotify that can be closed, at some point I'll just go add comments and someone else can close them if they agree.

Nathan.

[Nathan Youngman]

So by the looks of things, 1.4 and the move to GitHub are all happening at the same time. 

The wiki links to Go development dashboard... what's the plan for it?

The website (http://godoc-test.golang.org/) links to http://build.golang.org/ which doesn't default to git yet (/git).

Nathan.

[minux]

On Thu, Dec 11, 2014 at 12:31 AM, Nathan Youngman <he...@nathany.com> wrote:

So by the looks of things, 1.4 and the move to GitHub are all happening at the same time. 

That's the only time where the migration won't negatively impact the development (much).

The website (http://godoc-test.golang.org/) links to http://build.golang.org/ which doesn't default to git yet (/git).

It's defaulting to hg because it needs to test the 1.4 release, which is still done from the hg

repository. 

[Jan Mercl]

On Mon Dec 08 2014 at 8:47:25 Andrew Gerrand <a...@golang.org> wrote:

> With that said, if you see something you think

> might be broken or wrong, please reply to this thread.

Today I noticed one more, although minor, glitch: Starring an issue in the pre github version was a way to subscribe to it - get mail notice when anything/anyone updated the issue. Handy for eg. watching progress on blocking-something issues, especially for older ones with little or no recent activity. Github has the subscribe mechanism as well, but the previous, existing subscriptions seem to have not been migrated.

If the old subscription information is still available somewhere, it would be nice to migrate it to github subscriptions if/where/when possible. I hope it's possible at least when the github user granted full account access to golang.

I, for one, had an estimated three digit number of subscriptions...

-j

[Andrew Gerrand]

On 16 December 2014 at 20:35, Jan Mercl <0xj...@gmail.com> wrote:

If the old subscription information is still available somewhere, it would be nice to migrate it to github subscriptions if/where/when possible.

It is not available. There's nothing we can do about this. Sorry.

[Liam]

Every code.google issue got a comment linking the new github page. Could you generate comments linking the github subscribe URL?

[Andrew Gerrand]

What would that accomplish? There's a subscribe button on every issue page. 

[Liam Breck]

On Wed, Dec 17, 2014 at 3:20 PM, Andrew Gerrand <a...@golang.org> wrote:

Every code.google issue got a comment linking the new github page. Could you generate comments linking the github subscribe URL?

What would that accomplish? There's a subscribe button on every issue page. 

Single-click subscription from the email message to current subscribers.

[minux]

I found another potential discrepancy for the issues, but i'm not sure.

In https://github.com/golang/go/issues/8938,

the first labels were added by a user named ainar-g, however, looking

at the original issue, https://code.google.com/p/go/issues/detail?id=8938,

that user should be user griesemer instead (unless both are gri :))

[Russ Cox]

This is a known problem with the import. We lost some information about who added what label. That's just how it is.

Russ

[Brad Fitzpatrick]

It's still there in the comment text at least.

--