Inconsistencies using git describe --dirty #250
Comments
|
@umarcor i updated v2 so that |
|
Let me know if that fixes the issue. Otherwise the default behavior for v2 persists the auth token, so scripting authenticated git commands just works . So if you need to run |
|
@ericsciple thanks! I believe that it won't make a big difference because our scripts do check it explicitly now. However, I will try it. Is this released already or is it in master yet?
Yes, it did/does. Precisely, our fix was: https://github.com/ghdl/ghdl/blob/master/dist/msys2-mingw/run.sh#L70-L74. Nevertheless, I believe that the new behaviour will be better for a majority of users. Regarding the second issue (this action producing a dirty state when using |
|
@ericsciple, I ran the tests again: https://github.com/umarcor/ghdl/actions/runs/117853978. I updated the table above accordingly. As you said, the "unshallow" issue seems to be fixed. All However, |
|
For the crlf issue, there is a good discussion here Based on this doc the I agree a |
I understand that. In fact, I think that having this as an option (which can be added to v2) might suffice. Anyway, let's continue in #226. |
|
Aha thanks for the explanation of |
To avoid CRLF in Windows tests, which cause problems with Prettier: https://github.com/upleveled/preflight/runs/1824397400 Suggested here: actions/checkout#250 (comment) Example repo: https://github.com/ghdl/ghdl/blob/aa63b5efcd2be66acc26443032df2b251e4b1a7a/.github/workflows/Test.yml#L230-L232
To avoid CRLF in Windows tests, which cause problems with Prettier: https://github.com/upleveled/preflight/runs/1824397400 Suggested here: actions/checkout#250 (comment) Example repo: https://github.com/ghdl/ghdl/blob/aa63b5efcd2be66acc26443032df2b251e4b1a7a/.github/workflows/Test.yml#L230-L232
While trying to use
git describe --dirtyto get a description of the repo, I found the behaviour of v2 misleading. At the same time, there are certain setups that produce a "dirty" state on Windows. To test it, I configured ~40 jobs in https://github.com/umarcor/ghdl/blob/checkout-dirty/.github/workflows/checkout.yml. Results are summarized in the following table:fatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnofatal: No names found, cannot describe anythingnoOverall, I find misleading that using
fetch-depth: 0does not retrieve tags and, at the same time, it does not allow using--unshallow. It seems not possible to use the Action as is to retrieve some describable state. Some additional step is always required.In my target use case, I need to run
git describe --dirtyin a script that is executed on MSYS2 (both MINGW32 and MING64). As shown in the table, there seem to be two possible setups only, and one of them produces an invalid result.Precisely, cases msys-unshallow-git produce a dirty description, even if the repo is clean. These cases imply cloning a repo with this action and the using
gitinstalled throughpacman. It seems to be some clonflict with line endings, but neither dos2unix nor unix2dos can fis it easily.Hence, in order to get a clean description, users are "forced" to inherit the PATH and to avoid using
gitinstalled through pacman (cases msys-unshallow-inherit). This is undesirable, because other tools might be overriden through the PATH.Alternatively, manually cloning the repo inside MSYS2 works ok, regardless of using
gitinherited from the PATH (cases msys-inherit-clone) or installed throughpacman(cases msys-clone). However, this defeats the purpose of this action./cc @ericsciple
Ref #249 #240 #239 #217 #226
The text was updated successfully, but these errors were encountered: