# Regression test for https://golang.org/issue/34086:
# 'go mod tidy' produced different go.mod file from other
# subcommands when certain kinds of cycles were present
# in the build graph.

env GO111MODULE=on

cp go.mod go.mod.orig
go mod tidy
cmp go.mod go.mod.orig

# If the go.mod file is already tidy, 'go mod graph' should not modify it.
go mod graph
cmp go.mod go.mod.orig

-- go.mod --
module root

go 1.13

replace (
	a v0.1.0 => ./a1
	b v0.1.0 => ./b1
	b v0.2.0 => ./b2
	c v0.1.0 => ./c1
	c v0.2.0 => ./c2
)

require (
	a v0.1.0
	b v0.2.0 // indirect
)
-- main.go --
package main

import _ "a"

func main() {}

-- a1/go.mod --
module a

go 1.13

require b v0.1.0
-- a1/a.go --
package a

import _ "c"
-- b1/go.mod --
module b

go 1.13

require c v0.1.0
-- b2/go.mod --
module b

go 1.13

require c v0.2.0
-- c1/go.mod --
module c

go 1.13
-- c2/c.go --
package c
-- c2/go.mod --
module c

go 1.13

require b v0.2.0
-- c2/c.go --
package c