Closed erbridge closed 9 years ago
We currently need the packages in the the backend for the tests.
I put the subfolders in so you can run go test github.com/limetext/lime-backend/lib/...
without hitting errors due to there being other files in the root that aren't being tested (e.g. GoSublime). Try running go test github.com/limetext/lime/...
to see what I mean.
I see, but there are just few tests relying on them and they should use testdata folder imo also this removes the go test github.com/limetext/lime-backend/lib/...
problem for backend repo at least.
You also get errors like this:
tasks/build/gen_loaders.go:24: main redeclared in this block
previous declaration at tasks/build/fix.go:68
tasks/build/gen_python_api.go:394: main redeclared in this block
previous declaration at tasks/build/gen_loaders.go:24
At least if we have a subdirectory, we're able to later include files that might be problematic in the root, without having to move everything around. There's also an neatness to having a relatively empty root directory, IMO.
Having said that, I'm not strongly swayed against having it in the root if we can avoid import, build and testing issues.
I had some time, so I did the work to split out the projects as I described above. I didn't bother preserving the commit history, since it would have been a lot of hard work for little gain (as long as this project remains around).
History would be nice, but I'm ok with referencing the fork-point in the commit message as was done. History could be added in the future if anyone is feeling masochistic enough (IIRC I hacked it for the limetext/text repo via filter-branch and lots of trial'n'error), or if someone happens to be a git expert and knows of a simple and straight-forward way to do it.
I started trying to filter out the history, but realised that it would be unreliable due to files moving around, and I couldn't work out how to follow moves sensibly. Google didn't reveal any nice way of doing it, either.
FWIW I tried to get history working and re-pushed the lime-backend repo (twice...). Github still doesn't follow renames, but for example git log --follow lib/view.go
does so atleast we have that now
Nice.
Related to #537.
I propose the following structure:
We should also try to preserve history using
git subtree
orgit filter-branch
for proper attribution and change history.I'll do the work to make this happen, but is this a good structure to go with?