Externalize bindata.go to an auto-generated file #33

New Issue

GiteaMirror · 2025-11-02T03:05:06-06:00

GiteaMirror commented

2025-11-02 03:05:06 -06:00

Originally created by @thibaultmeyer on GitHub (Nov 5, 2016).

I think bindata.go dont have to be committed on repository and must be auto-generated during the make process.

It become a mess when two (or more) Pull Requests update different files (eg : app.ini for the first commit and add new files for the second) because the bindata.go file cause merge error each time.

Originally created by @thibaultmeyer on GitHub (Nov 5, 2016). I think `bindata.go` dont have to be committed on repository and must be auto-generated during the make process. It become a mess when two (or more) Pull Requests update different files (eg : app.ini for the first commit and add new files for the second) because the `bindata.go` file cause merge error each time.

GiteaMirror added the issue/duplicate label 2025-11-02 03:05:06 -06:00

GiteaMirror closed this issue

2025-11-02 03:05:06 -06:00

GiteaMirror commented

2025-11-02 03:05:07 -06:00

@strk commented on GitHub (Nov 5, 2016):

I generally agree on never keeping anything that's not source code into the repository.
What I've understood is that bindata.go is there to allow for "go get" to get you a compiled binary, so basically a workaround to a "go get" limitation. But I don't have further references about this limitation and other possible workarounds.

In all cases, I think it is acceptable to go get ...; less README.md; make;

@strk commented on GitHub (Nov 5, 2016): I generally agree on never keeping anything that's not source code into the repository. What I've understood is that bindata.go is there to allow for "go get" to get you a compiled binary, so basically a workaround to a "go get" limitation. But I don't have further references about this limitation and other possible workarounds. In all cases, I think it is acceptable to `go get ...; less README.md; make;`

GiteaMirror commented

2025-11-02 03:05:07 -06:00

@tboerger commented on GitHub (Nov 5, 2016):

I don't agree on that. There are no other ways to stay go gettable than adding bindata to the repo.

If there are other ways around we can talk about that.

@tboerger commented on GitHub (Nov 5, 2016): I don't agree on that. There are no other ways to stay go gettable than adding bindata to the repo. If there are other ways around we can talk about that.

GiteaMirror commented

2025-11-02 03:05:07 -06:00

@tboerger commented on GitHub (Nov 5, 2016):

BTW, go get will fail without the bindata because the imports can't be accomplished

@tboerger commented on GitHub (Nov 5, 2016): BTW, go get will fail without the bindata because the imports can't be accomplished

GiteaMirror commented

2025-11-02 03:05:07 -06:00

@strk commented on GitHub (Nov 5, 2016):

@tboerger it will fail but will have downloaded all the sources, right ?

@strk commented on GitHub (Nov 5, 2016): @tboerger it will fail but will have downloaded all the sources, right ?

GiteaMirror commented

2025-11-02 03:05:07 -06:00

@tboerger commented on GitHub (Nov 5, 2016):

But if I go get something I expect to have it working without reading the readme to find out what else needs to be done

@tboerger commented on GitHub (Nov 5, 2016): But if I go get something I expect to have it working without reading the readme to find out what else needs to be done

GiteaMirror commented

2025-11-02 03:05:07 -06:00

@strk commented on GitHub (Nov 5, 2016):

I'm not a long Go user enough to know what one would have to expect by "go get". I've read it's not a package manager, but I do see it being used as such

@strk commented on GitHub (Nov 5, 2016): I'm not a long Go user enough to know what one would have to expect by "go get". I've read it's not a package manager, but I do see it being used as such

GiteaMirror commented

2025-11-02 03:05:08 -06:00

@strk commented on GitHub (Nov 5, 2016):

For the PR mess (conflicts and changelogs size), I shall note that @Unkwon used to only update bindata.go before releases, and not accepting those updates in the PRs themselves.

@strk commented on GitHub (Nov 5, 2016): For the PR mess (conflicts and changelogs size), I shall note that @Unkwon used to only update bindata.go before releases, and not accepting those updates in the PRs themselves.

GiteaMirror commented

2025-11-02 03:05:08 -06:00

@tboerger commented on GitHub (Nov 5, 2016):

I would suggest an additional commit made by the CI system that updates the bindata.

@tboerger commented on GitHub (Nov 5, 2016): I would suggest an additional commit made by the CI system that updates the bindata.

GiteaMirror commented

2025-11-02 03:05:08 -06:00

@strk commented on GitHub (Nov 5, 2016):

If bindata.go has to stay, +1 for the CI system automation (only if it would change).
But I'd really prefer to give-up go-get'ability than keeping generated files in the repo.
How about making bindata.go usage optional, so to retain go-getability while still allowing bindata.go usage upon request ?

@strk commented on GitHub (Nov 5, 2016): If bindata.go has to stay, +1 for the CI system automation (only if it would change). But I'd really prefer to give-up go-get'ability than keeping generated files in the repo. How about making bindata.go usage optional, so to retain go-getability while still allowing bindata.go usage upon request ?

GiteaMirror commented

2025-11-02 03:05:08 -06:00

@strk commented on GitHub (Nov 5, 2016):

@tboerger is the optional bindata.go what you'd get with build tags ? (https://github.com/go-gitea/gitea/pull/74#issuecomment-258598101)

@strk commented on GitHub (Nov 5, 2016): @tboerger is the optional bindata.go what you'd get with build tags ? (https://github.com/go-gitea/gitea/pull/74#issuecomment-258598101)

GiteaMirror commented

2025-11-02 03:05:08 -06:00

@strk commented on GitHub (Nov 5, 2016):

My take on the optional embedding of files is in this PR: https://github.com/go-gitea/gitea/pull/78
I've understood @tboerger is also working on making embedding optional in his #74, but I think that PR also adds public and templates into the bindata, so maybe it make sense to divide the work in two steps, for easier reviews ?

@strk commented on GitHub (Nov 5, 2016): My take on the optional embedding of files is in this PR: https://github.com/go-gitea/gitea/pull/78 I've understood @tboerger is also working on making embedding optional in his #74, but I think that PR also adds `public` and `templates` into the bindata, so maybe it make sense to divide the work in two steps, for easier reviews ?

GiteaMirror commented

2025-11-02 03:05:09 -06:00

@strk commented on GitHub (Nov 5, 2016):

For reference, @tboerger PR about conditional bindata embedding is #30 (came out in gitter chat)

@strk commented on GitHub (Nov 5, 2016): For reference, @tboerger PR about conditional bindata embedding is #30 (came out in gitter chat)

GiteaMirror commented

2025-11-02 03:05:09 -06:00

@strk commented on GitHub (Nov 5, 2016):

So, should this be closed as a duplicate of #30 ?

@strk commented on GitHub (Nov 5, 2016): So, should this be closed as a duplicate of #30 ?

GiteaMirror commented

2025-11-02 03:05:09 -06:00