@git@ should return tag if the current commit == the tag, otherwise return just short commit without the tag

[dkarlovi]

Bug report

Question	Answer
Box version	4.6.5
PHP version	8.3.19
Platform with version	Linux Fedora, Docker
Github Repo	-

Currently, all @git_*@ placeholders will use the latest tag and optionally append the short commit if there's a commit done after the tag. But IMO this is not correct: tag is a pointer to a specific commit and you're either on that commit or you're not.

If you are, producing the tag is correct. If you're not, producing the tag is not correct.

For example, currently I have a tag

0.3.2

and have added a commit (in a separate branch), my version now became

0.3.2@b9d260b

but this is not 0.3.2, it's b9d260b, tag 0.3.2 is a very specific commit which this commit isn't. I see this as a bug in the current behavior, but I guess a new placeholder with this behavior could be introduced, making this a feature? But I'd then argue there's already some placeholders which are too similar to differentiate without really looking into what they do git and git_version.

box.json.dist

{
   "files": [
       "config/autoload_runtime.php.template",
       "config/bundles.php",
       "config/services.yaml"
   ],
   "git": "git",
   "compression": "GZ"
}

[theofidry]

I'm a bit confused tbh.

If I checkout a tag:

$ git checkout 10.2.5
$ git describe --tags HEAD
> 10.2.5

Now if I checkout a new branch from that and add a commit:

$ git checkout -b test-commit
$ touch demo && git add . && git commit -m 'test'
$ git describe --tags HEAD
10.2.5-1-gd07440daa

Under the hood it is what Box does https://github.com/box-project/box/blob/main/src/Configuration/Configuration.php#L2116. If there is no hash it won't pick it.

I am confused however at the git_tag one as I don't see it filtering out the potential hash... But I guess if there is a hash it's not a clean tag?

[dkarlovi]

You don't need to checkout the tag, it works like that regardless:

$ git branch
* main
$ git checkout -b test-commit
Switched to a new branch 'test-commit'
$ git describe --tags HEAD
0.3.3
$ touch demo && git add . && git commit -m 'test'
[test-commit 9c4cdd0] test
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 demo
$ git describe --tags HEAD
0.3.3-1-g9c4cdd0

It's basically saying

This is basically 0.3.3 + some stuff.

But what I'm saying is, that doesn't make sense, I don't know why Git does it like that, but Box shouldn't propagate this behavior.

Box should:

• name the tag if you're exactly on the commit the tag is made on
• name the hash anywhere else

[theofidry]

name the tag if you're exactly on the commit the tag is made on

But that's the case?

I believe you get 0.3.3-1-g9c4cdd0 because you are not on that tag. 0.3.3-1-g9c4cdd0 means you are on the commit g9c4cdd0 which is 1 commit after 0.3.3.

This git information relies on the current state of the git history, so if you want to build a PHAR with Box for a tag, you should make sure you are on that tag, not a different commit.

That said I don't have the logs but I believe it's the same thing for Box, so I need to check why you have that on GitHub Actions in a release job

[dkarlovi]

you are on the commit g9c4cdd0 which is 1 commit after 0.3.3.

Right, but why is it mentioning 0.3.3 at all?

you should make sure you are on that tag, not a different commit.

Yes, that part works as expected, the issue is when I'm not on the tag, it's still saying I am on the tag + one commit, which is totally misleading IMO.

[theofidry]

That's what git-version is though. Must say the docs could be more explicit here, and maybe it's a more sensible default.

Let's change it although we can't outright swap it as I expect a few complains otherwise

[asgrim]

Box should:

* name the tag if you're **exactly** on the commit the tag is made on

* name the hash anywhere else

I personally disagree, but I do acknowledge that, if you're not familiar with how git describe --tags works, it isn't immediately obvious why it works this way. Box's behaviour for @git@ is consistent with how git describe --tags works (although it does throw away the "number of commits away" aspect), and believe it should be kept as is to avoid BC breaks and to keep consistency with git describe --tags.

I guess a new placeholder with this behavior could be introduced

I'd concur that this suggested behaviour could be a new template, e.g. @git_tag_or_commit@ or something better named, and document the distinction clearly?

If you change the existing template behaviour of @git@, you break BC for anyone that may use the tag|tag@commit format etc which IMO is a big no-no.

[dkarlovi]

Just because Git does a dumb thing doesn't mean Box needs to propagate exactly the same behavior, this is one of those "if your friends jumped off a bridge, would you jump too?" situations.

We already agreed this would be a new token instead of changing the existing one, no?

[asgrim]

Just because Git does a dumb thing

Maybe dumb in your opinion, sure. I personally don't think it is dumb, it is a useful command in Git, I've used it multiple times in various places for various reasons. Thank you and have a nice day!

[dkarlovi]

That goes without saying: everything said in this thread is just some guy's opinion.