gormt reads column comments for gorm tags, ships config.yml inside its release zips, and builds amd64 only

The help output stops mid-parenthesis and never mentions -u

The flag table in the README covers `-d`, `-f`, `-F`, `-g`, `-h`, `-H`, `-o`, `-p`, `--port`, `-s`, `-b` and `-l`, and stops on the line `-l, --url string url标签(js`. The parenthesis is never closed and no flags follow it, so the list ends mid-description. Two things stand out in what is there.

The example run given later passes a user flag that the table does not contain: `./gormt -H=127.0.0.1 -d=oauth_db -p=qwer -u=root --port=3306 -F=true`. There is no `-u` entry in the flag list. And `-s, --singular` carries the description 是否禁用表名复数, which reads as whether to disable table name pluralisation, so the label and the meaning point in opposite directions. The `-H` entry even warns about its own case, that it must be uppercase.

The sample config ends on a key with no value

The default configuration block is thirteen keys, and the last line has no colon and no value:

out_dir : "./model"  # out dir
url_tag : json # web url tag(json,db(https://github.com/google/go-querystring))
language :  # language(English,中 文)
db_tag : gorm # DB tag(gorm,db)
simple : false #simple output
is_out_sql : false # Whether to output sql
is_out_func : true # Whether to output function
is_foreign_key : true # Whether to mark foreign key or not
is_gui : false # Whether to operate on gui
is_table_name : false # Whether to out GetTableName/column function
is_null_to_point : false # database is 'DEFAULT NULL' then set element type as point
is_web_tag: false
is_web_tag_pk_hidden

The note above it points elsewhere for the truth: for the latest version of the config format, check /data/config/MyIni.go. A file that names its own source of truth as a Go struct is telling you the README sample is a snapshot, and the trailing key without a value is what such a snapshot looks like after a field was added.

Config keys and command flags do not line up

Most config keys carry an `is_` prefix and a boolean meaning: `is_out_sql`, `is_out_func`, `is_foreign_key`, `is_gui`, `is_table_name`, `is_null_to_point`, `is_web_tag`, `is_web_tag_pk_hidden`. The flags are short and lettered instead, `-f` for foreign key export, `-F` for function export, `-g` for the gui mode, `-o` for the output directory.

Several keys have no flag counterpart at all. `db_tag` chooses between gorm and db tags, `language` switches between English and 中文, `simple` toggles simple output, `is_null_to_point` turns `DEFAULT NULL` columns into pointer types, and `is_out_sql` writes the SQL alongside the structs. A person who edits config.yml to turn those on, then passes `-g=false` on the command line expecting the flags to override everything, is working from two different mental models of the same tool.

Column comments are the input format

The generated tags come from how you write the column comment in MySQL. A comment starting with `[@gorm default:'test']` becomes a default. The fuller form is `[@gorm default:'test';->;<-:create]this is my notes`, where the arrow markers declare read and create permissions on the field. A foreign key is declared as `[@fk tableName.columnName]this is my notes`, which is how the association_foreignkey and foreignkey pairs end up in the output struct.

The README demonstration shows the result: a `user_info_tbl_id` column carrying an `index` tag and a sibling `UserInfoTbl` field carrying `gorm:"association_foreignkey:user_info_tbl_id;foreignkey:id"`. Plain column comments travel through untouched as Go comments, which is why the sample output carries Chinese text such as 帐号类型:0手机号，1邮件 into the struct fields. The tool can also enrich data types, with a pointer at data/view/cnf/def.go for that.

The Makefile publishes amd64 binaries for all three platforms

The build section offers `make windows`, `make linux`, `make mac` or `go generate`. Every one of those targets sets GOARCH=amd64, so there is no linux arm64 binary and no darwin arm64 binary in the build file, on a project whose go.mod asks for go 1.24.0 with toolchain go1.24.4.

The CGO setting also differs per platform. Windows and linux build with CGO_ENABLED=0, while mac builds with CGO_ENABLED=1, which is why the README carries a note that Windows does not support utf-8 style ASCII model output and tells you to run `CHCP 65001` to switch the console encoding. The `all` target does not build anything itself, it calls `make tar`, and the tar recipe builds the three platforms again without the `-ldflags "-s -w"` that the named targets pass, so the packaged archives are not stripped.

The password is a flag, and config.yml travels inside every zip

Credentials are handled in two ways, and both are worth avoiding in a shared environment. The password is a command line flag, `-p, --password string`, and the documented example passes it inline: `-p=qwer`. Command lines are visible in process listings and land in shell history.

The other route is the config file. Each archive the Makefile produces bundles the config file next to the binary, `tar czvf gormt_windows.zip gormt.exe config.yml`, and the same pattern repeats for the mac and linux archives. A config.yml that holds a password is therefore a config.yml that gets zipped and uploaded. There is a config.yml in the repository root and a .gitignore, but nothing in the README says which keys are safe to commit, so that decision lands on whoever sets the tool up.

The newest release tag predates the current code by years

The two listed releases are v2.1.gorm from 2021-06-27 and v1.gorm from 2020-09-25, while the last push on the default branch is dated 2026-07-10. Neither tag name follows the usual three number form, and the downloadable archives that README points at are attached to those tags, so what you install from a release is several years behind the branch you would read for current behaviour.

The maintenance target in the Makefile pushes in the other direction. `make master` runs `go get -u` against the master branch of the shared public package and of gorm itself, plus the sqlserver and sqlite drivers, so following that target pulls untagged upstream code into go.mod. The pinned versions in go.mod are already pseudo-versions rather than tags, and the require block carries cobra v1.1.3 next to gorm at a 2025 pseudo-version.

Editorial conclusion

gormt earns its place when you want foreign key associations and generated accessor functions rather than plain structs, and when you control the column comment conventions in your schema. Before adopting it, read data/config/MyIni.go instead of the sample config in the README, keep the database password out of both argv and the config file you commit, and check that your platform has a build target at all, because every Makefile target is amd64. Treat the generated code as a starting point that lands in version control, not as output you regenerate silently on every pull.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes