I'm writing a MIDI parser that splits apart MIDI files and adjusts the volume on different tracks to allow for specific voice isolation to help practicing. I'm using a Go library, EasyMIDI. However, I ran into a use case that the library didn't cover, so I forked the repo and made changes that should fix my issues in the short term.
I'm able to successfully build when using my forked Github URL in my go.mod and import statements, but the code changes I made aren't being reflected. I added the function GetChannel() to an interface, and so should see it listed as an option. When I click into the source for another function that was originally implemented, I see that my VSCode is referencing the non-forked repo when grabbing the code (see screen snippet below).
As you can see on the left, there is no GetChannel() function. If I click on "algo!guy" and select "!try431", I do see the changes I made and pushed to my fork. How do I get my code to recognize that I want my forked repo so I can get access to these changes I've made?
Edit: Thought I might as well throw in the go.mod and go.sum files that are generated upon a go build.
go.mod
module github.com/Try431/acc-midi-splitter
go 1.12
require github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087
go.sum
github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087 h1:dXDwjgIHMgL4zow9ixgTslZ3cWZHHIu3+FurDjDC6wA=
github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087/go.mod h1:c/dd/WkUR9yfzjC9sPO9J0vh5TzTmE8ryAvEviTDwgg=
github.com/algoGuy/EasyMIDI v0.0.0-20180322051653-708ca39e7399 h1:f0h3xTKQjrTzAUwqMJr1TY3lk3gTK8R4v7ZjcSMiwm8=
github.com/algoGuy/EasyMIDI v0.0.0-20180322051653-708ca39e7399/go.mod h1:z6svyEeOasADFxg4gn6funK2OBjocr62B4J7ZPodCPs=
I've tried deleting the algoGuy lines in the go.sum, but obviously the lines are put back on a go build.
You can use a replace statement in go.mod:
replace original => fork
This should make references to the original repo in the forked source lookup from the forked repo.
Related
I am using Circle CI to test my project. The project is a simple Go application consisting of a few packages and a main.go file. When referencing packages within my project I simply import them as "projectName/packageName" in the code. This works fine locally, however, when I push to git and it gets built on Circle CI I get the following errors.
package crypto-compare-go/handlers: unrecognized import path
"crypto-compare-go/handlers" (import path does not begin with
hostname)
I fixed this by prepending github.com/myGitUsername/projectName to my local package imports, this means that when I'm developing locally If I change one of the packages within my project, I have to push to git, then pull to be able to use them even though they are all under the same parent project folder. This seems like a slow, very inefficient process.
Has anyone had this problem with Circle CI before?
I fixed this by prepending github.com/myGitUsername/projectName to my local package imports, this means that when I'm developing locally If I change one of the packages within my project, I have to push to git, then pull to be able to use them even though they are all under the same parent project folder. This seems like a slow, very inefficient process.
Nope. You get this wrong. Your go will use the local $GOPATH/src/github.com/myGitUsername/projectName dir to compile. You access github.com only if you run go get -u <package path>. It is documented in How to Write Go Code.
Note that you don't need to publish your code to a remote repository
before you can build it. It's just a good habit to organize your code
as if you will publish it someday. In practice you can choose any
arbitrary path name, as long as it is unique to the standard library
and greater Go ecosystem.
I am starting in Golang development. Right now my boss gave me the repository of a project that other developer made, now he's gone of the company and I am not able to ask him some things related to it. Right now I have a confussion about the project structure that he pushed to the repo, the structure is the next:
|-MyApp
|--bin
|--pkg
|--src
|----api (the code of the app)
|----github.com
|----golang.org
|----gopkg.in
To me, it's exaclty as the estructure of the Go, 1.- in the repo should not be only the api folder?
If I go to the api folder and make go run main.go I get a message that some packages are not found even when they are in the folder, 2.-how I specify the packages in the go run command?
3.- Is a good practice to set this kind of structure for the golang projects? I see in the code that he exported the packages only with "package1", if I copy and paste the code of the app inside the golang workspace then I have to specify the name of the folder to export the packages, example: "myApp/package1" so there I have that doubt. Thank you
That all depends. There is not a single right way for everything.
It seems as if this repo decided to vendor everything, the whole GOPATH. That is okay but with the "modern" vendor folder today one would do it probably differently.
Never do go run. That's for toy programs only. Build your software with go build and go install. These command work on package path.
For everything else: Please see the official documentation https://golang.org/doc/code.html and stick to it (which means you should move stuff around a bit).
I am working on a Swift based XCode project that is synced with Git based master repository. One of my team member has added few files, to the master which I have pulled.
I find those files in my project directory, but not in my project. When I am manually trying to add these files to the project, in that case, I am getting Modify tag on my project, then I am unable to pull new changes from master.
This is very annoying. How do I take care of this.
Also, how do we make sure as a team that everyone of us is working separately on different module, and make surely everyone is able to commit/pull each other's changes.
The project folder with M tag is prohibiting us from doing so.
Edit 1
I have followed steps for this as well
git rm -r --cached ProjectName.xcodeproj
git commit -m "Removed file that shouldn't be tracked"
Even after doing this,
I had made changes in File1.swift, with my team member's changes in File2.swift
He had already committed it, I wanted to pull those changes, however due to changes in File1.swift I was unable to pull it.In order to make it work, I had to discard changes in File1.swift and then only I was able to pull those changes. If this is so, then it is defeating the purpose of using git
Xcode project files
The Xcode project file, or to be more precise, the pbxproj file inside the xcodeproj container keeps track of all files (among other things). Unlike Eclipse, Xcode does not monitor your source/project folder for changes thus does not update the list of files which can lead to inconsistencies after a merge.
Merge conflicts
If your team member adds or removes a file in his local copy of the repository and pushes his changes to the server, he basically overwrittes the pbxproj and therefore updates the list of files of the Xcode project. If you pull those changes there are two possible scenarios:
Git can merge the changes automatically which usually means it will keep your copy of the pbxproj file without the updated file references.
Git cannot merge the changes and therefore indicates a merge conflict that you need to resolve yourself. Depending on the differences and amount of changes these merge conflicts can be pretty annoying to resolve. Sometimes it might be easier to just delete your copy of the pbxproj file, use the one from the server and reapply your local changes, e.g., add file references.
In both cases you might need to compare your pbxproj file against the one from the server and merge things by hand. And yes, your project file will be marked with an M (for modified) which is perfectly fine. Just commit your changes and you are good to go again.
One more thing: Whenever you want to pull changes from the git server you can either stash your changes (git stash) or commit them.
Avoiding merge conflicts
In case you want to avoid merge conflicts in the future, I recommend having a look at the following tools.
Cocoapods
Cocoapods can be used to modularise your project into smaller pieces by creating private Pods. The benefit of this technique: You do not have to keep track of newly added or removed files. Just run pod update and you are up and running again. There are several blog posts that describe this technique in detail, e.g., here
phoenx
At my former company we had a pretty huge codebase and ran into some trouble when using Cocoapods. Therefore, we have developed our own meta-build system called phoenx. Phoenx can generate Xcode project and workspace setups of arbitrary complexity. It uses metadata files (something like Podfiles and Podspecs) to generate the projects etc. . Build settings will be stored in xcconfig files. At the moment it does not provide any setup tool so you have to invest a bit of time to write the xcconfig and metadata files by hand. We are working on a more convenient way to use it though. If you want to give it a try you can install it via sudo gem install phoenx. Documentation is available on GitHub.
Hope that helps!
I am trying to have a local copy of current code base of mgo.v2. https://gopkg.in/mgo.v2 says to install using go get gopkg.in/mgo.v2. I forked it from https://github.com/go-mgo/mgo/tree/v2 and trying to install it from go get forked repo from git but it changes the package structure(changes from /src/gopkg.in --> /src/github.com) and it fails saying
src/github.com/eateshk/mgo.v2/error.go:4: "ERROR: the correct import path is gopkg.in/mgo.v2 ... " evaluated but not used
I understand the error, but what's the solution for this ?
This is a common problem when forking go packages. Canonical or "vanity" imports require the code to live in the specified path or they won't compile. The only solution is to remove the // import "gopkg.in/whatever" comment that exists somewhere.
There are other problems with your approach as well. imports within their repository will resolve back to the original repo and cause all kinds of confusion unless you rewrite them.
Rather, I suggest an alternate approach. The only place this can live on disk without causing problems is $GOPATH/src/gopkg.in/mgo.v2. Anything else will cause problems. So:
go get gopkg.in/mgo.v2
cd $GOPATH/src/gopkg.in/mgo.v2
git remote add mine your_git_fork
Now you can pull upstream changes from origin and push your changes to mine. It feels a bit odd, but it really is the only way to work from a fork without causing tons of extra pain by rewriting things.
I use Linux as primary operating system and I also have to work on a Windows virtual machine with Eclipse 3.7.
We're working with subversion but with Linux I'm happily using git-svn with Emacs+magit, which works great.
So I would like to be able to work on the same code from both OS, and only do the real version control management on Linux.
So I had the following thought:
1. share the directory with virtualbox
2. create the projects pointing to the shared directory
Well that doesn't work, because the dumb thing wants to copy everything.
So I tried to use virtual folders which seemed a good idea, but now some scripts are badly failing because they don't find the hard-coded paths.
So I don't know anymore what to try, any idea?
EDIT:
My last attempt in the last edit would not work, so I have a simpler question.
Given a git/svn/whatever repository checkout, why can't I simply tell to Eclipse create a project there without touching the files?
Is it so hard for Eclipse to create it's .project in that position?
And since there is clearly no "supported" way to do it, is there maybe any workaround?
From my experience, the stages are the following (using Indigo version):
1. Create new empty project
2. Click File->import->file system
3. in the import window import file system, check the files you want into the new project folder
4. Click on advanced in the import window and tick "create links in workspace"
The new project should contain links to the original directory.
Eclipse modifies and compiles source in its workspace. The first level of the workspace is the project directories, + a .metadata which is local only to that workspace instance. Traditionally, the workspace contains the projects it works on.
Eclipse also supports 2 linked modes. In one, when you create the project in the workspace you give it an absolute path to somewhere else on the file system. This is handy if you have eclipse projects in a git repo, for example.
In the other mode, you create the project in your workspace locally. Then you link your folders (source, resources, whatever) to somewhere else on the filesystem. This is useful for projects that don't want to save the eclipse specific files (.project, .classpath, etc) in their SCM.
You have to create a different workspace on each OS (there's no way around that). But you could create the projects in each workspace and link to the common location (I don't recommend it, but it would be do-able).
Same problem here and finally got a solution!
1) clone your repo but not directly to your workspace, in my case I used workspace2 instead of workspace.
2) On eclipse, import all the projects on workspace2, but don't mark the "copy files to workspace", so the source code is left on workspace2.
3) On git you will see changes appeared, on project.options files (only file date is changed) and in .path files (some lines changed its order). As all of them are irrelevant changes, reset the local branch discarding those changes.
Thats all, git sees no more changes and eclipse open the files properly!
I ran into a weird problem worth commenting here: after importing i went to "git gui" to see changes, and the first file changed was a "project.options" file that only changed its date but the diff was empty (as the content was unchanged). There is a bug on git that makes git gui enter on an infinite loop: while it detect changes on file and diff is empty, a rescan is performed, then the same change is detected and enter on a rescan loop.
There is a patch to solve this, but it was easier just to add a silly comment on that only file (not in all your project.options) and then "git gui" was happy again and i could reset the changes on the branch.