Insufficient information in --version to distinguish between release and development instances

[zancas]

Reproduction steps

1. Build helix from source.

2. Invoke helix --version against the instance built from source, e.g.:

${GITREPO_ROOT}/target/debug/hx --version
helix 0.4.1

3. Invoke helix --version against the instance installed from a release, e.g. (on Arch):

/usr/bin/helix --version
helix 0.4.1

Fix:
Make --version report more specific version information, perhaps:

$(RELEASETAG)-$(BUILD_CANDIDATE)_$(10CHARSBUILDHASH)

e.g.

0.4.1-rc1-8442e653f5

for a development build instance, and:

0.4.1 for a released instance.

[pickfire]

I wanted to do that originally but then decided that it is easier to just ask the developer to report it himself using git describe.

[EpocSquadron]

I don't think relying on git describe is enough. In my case for instance I build from the helix-git AUR package in a temporary directory (exists in memory, goes away after reboot if I don't rm -rf it manually). The version number encoded by the package is nonsense in order to make it always report out of date, since it is a vcs package. Thus I have no way of figuring out the exact commit from which I built helix. (I have a different machine where I build from source manually and run the editor with cargo run rather than a package, but that's just for working on the editor itself)

We could request the packager make the commit sha the package version instead, but that only fixes one case, and probably isn't totally clear to implement. I think as helix gets more popular more such edge cases will appear.

[archseer]

@pickfire Looks like we could do this in build.rs without complicated proc macros, what was the problem with this again? I remember there was some issues:

// build.rs
use std::process::Command;
fn main() {
    // note: add error checking yourself.
    let output = Command::new("git").args(&["rev-parse", "--short", "HEAD"]).output().unwrap();
    let git_hash = String::from_utf8(output.stdout).unwrap();
    println!("cargo:rustc-env=GIT_HASH={}", git_hash);
}

// main.rs
fn main() {
    println!("{}", env!("GIT_HASH"));
    // output something like:
    // 7480b50f3c75eeed88323ec6a718d7baac76290d
}

[archseer]

(needs some error checking so we fallback to "" if the code is not part of a git repository)

[archseer]

The version number encoded by the package is nonsense in order to make it always report out of date, since it is a vcs package.

It's good practice to include the git sha in the pkgver: https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function

[pickfire]

@pickfire Looks like we could do this in build.rs without complicated proc macros, what was the problem with this again? I remember there was some issues:

I did what you did there. Also, note that we may want git describe --dirty (the dirty part) since we don't know whether or not files are changed locally.

I find git describe --dirty useful because it can show us which commit is it and how far is it from the last tag. And with --dirty we know if they applied some patches.