x/tools/cmd/goimports: removes imports ending in ".git" or whatever vcs

[gopherbot]

by xofyarg:

What does 'go version' print?

go version go1.3.1 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. use a custom git repo: foo.com/bar.git
2. import "foo.com/bar.git" and add some code using it, say bar.Do()
3. call goimports

What happened?

it removes the import line above

What should have happened instead?

keep the import line

[bradfitz]

Comment 1:

The final path component of your import should be the same as your package name. 
"bar.git" isn't a valid package name.
This doesn't have anything to do with the git repo being private or not.
Can you give more details? Actual minimal example, and details of what the package name
actually is?

[gopherbot]

Comment 2 by xofyarg:

If I strip the extension from the import path, then it is not go get-able. Here's a
quote from `go help importpath':
> For code hosted on other servers, import paths may either be qualified
> with the version control type, or the go tool can dynamically fetch
> the import path over https/http and discover where the code resides
> from a <meta> tag in the HTML.
> 
> To declare the code location, an import path of the form
> 
>         repository.vcs/path
> 
> specifies the given repository, with or without the .vcs suffix,
> using the named version control system, and then the path inside
> that repository.  The supported version control systems are:
> 
>         Bazaar      .bzr
>         Git         .git
>         Mercurial   .hg
>         Subversion  .svn
> 
> For example,
> 
>         import "example.org/user/foo.hg"
The go get command has some popular repositories hardcoded, to support custom repo, I
need to show the repo type.
The package is in our private server(sorry, not accessable from outside), and we have
some code like this: http://play.golang.org/p/6IiGpjOjgN

[ianlancetaylor]

Comment 3:

Labels changed: added repo-tools.

[dmitshur]

My first guess is that it might be the regexp that matches imports doesn't take this possibility into account.

[heschi]

Triaging old goimports bugs: I'm pretty sure this should be fixed by now, and a quick test seems to confirm it. Please comment if you disagree.