Go modules and forks

I'm tinkering with a Go project ( let's call it foobar ), which has a dependency upon yet another Go project ( let's call it snafu )  in the same organisation.

For the moment, I've got a fork of snafu in my own org - david-hay - and wanted to update go.mod in the foobar project to leverage it.

I knew I had to update go.mod either manually or use go mod edit --replace source=target but couldn't get past the exception: -

go: -replace=github.com/org/snafu=github.com/david-hay/snafu: unversioned new path must be local directory

It turned out, as ever, that I was holding it wrong ...

I needed to explicitly provide a "version" - in this context, that was a branch e.g. main at which to point the target during go mod edit --replace like this: -

go mod edit --replace github.com/org/snafu=github.com/david-hay/snafu@main

In other words, the right-hand side of the --replace directive needed to include four things: -

- domain e.g. github.com

- organization e.g. david-hay

- project/repo e.g. snafu

- branch e.g. main

like this: -

...

replace github.com/org/snafu => github.com/david-hay/snafu main

When I then ran go mod tidy, this went off to GitHub and pulled down the latest release from that branch in my fork: -

go: downloading github.com/david-hay/snafu v1.11.39-0.20230116121922-46267d910e38

and updated go.mod with: -

replace github.com/org/snafu => github.com/david-hay/snafu v1.11.39-0.20230116121922-46267d910e38

In other words, it replaced the branch with the release ... which is nice

With thanks to this: -

Pointing to a fork of a Go module

Fun with Git and branching

In very brief terms, I hit an issue last week where I'd created four branches in a repo, having cloned the main branch of the upstream repo.

Therefore, I'd done something like this: -

git clone -b main git@github.com:snafu/foobar@github.com

cd ~/foobar

git fetch origin && git rebase origin/main

to bring the main branch down to my Mac.

I'd then created my first branch: -

git branch dave1

git switch dave1

and added/changed some code, committed it, and pushed my new branch upstream.

I then went ahead and created a second branch: -

git branch dave2

git switch dave2

git fetch origin && git rebase origin/main

and again added/changed some code, committed it, and pushed the new branch upstream

All seemed fine ...

And I did the same for two more branches - dave3 and dave4 - with a PR for each branch being reviewed/approved and merged into main.

And then I found, when merging in separate Pull Request, that my changes from dave2 overwrote the changes made in dave1.

Which was weird....

A colleague helped explain ...

I see the 4 PRs were created from a shared branch instead of independently being created from main. That could explain the unexpected behavior where they kept rewriting each other. 

He went onto explain how to avoid the issue ...

When you run git checkout -b branchname it creates a branch branching off of your current branch.

I am used to running git checkout main; git checkout -b branchname to ensure my branches are direct branches off of main. That helps rebase them based on other PRs merging to main.

which worked a treat

So, now I've learned this, and am trying hard to add this to my "muscle memory" ...

git clone -b main git@github.com:snafu/foobar@github.com

cd foobar

git fetch origin && git rebase origin/main

git checkout main; git checkout -b dave1

etc.

We shall see if that sticks ....