-
Lucas De Marchi authored
Tag just once to avoid the old tag left on the local machine with possibly the wrong message. Even more importantly: the revert of first version was correct, but at least with my current git version (2.44) it doesn't work. The second call to git-tag to amend the commit message will also move the tag to another commit: + git tag -F- drm-xe-fixes-2024-04-18-1 'drm-xe-fixes@{upstream}' + '[' git == git ']' + key_arg=-s + git tag -s -f drm-xe-fixes-2024-04-18-1 Updated tag 'drm-xe-fixes-2024-04-18-1' (was 46d02aa1b02c) So, even if it showed the correct log in gitk and updated the message, it ended up tagging the wrong commit. We could add "$branch@{upstream}" in the second invocation, but I think this also highlight another shortcoming of calling git-tag twice. In this "try 2" to avoid the breakage from v1 with some editors, do not pass the summary as stdin to `git-tag`, but rather create a tmp file. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
Lucas De Marchi authoredTag just once to avoid the old tag left on the local machine with possibly the wrong message. Even more importantly: the revert of first version was correct, but at least with my current git version (2.44) it doesn't work. The second call to git-tag to amend the commit message will also move the tag to another commit: + git tag -F- drm-xe-fixes-2024-04-18-1 'drm-xe-fixes@{upstream}' + '[' git == git ']' + key_arg=-s + git tag -s -f drm-xe-fixes-2024-04-18-1 Updated tag 'drm-xe-fixes-2024-04-18-1' (was 46d02aa1b02c) So, even if it showed the correct log in gitk and updated the message, it ended up tagging the wrong commit. We could add "$branch@{upstream}" in the second invocation, but I think this also highlight another shortcoming of calling git-tag twice. In this "try 2" to avoid the breakage from v1 with some editors, do not pass the summary as stdin to `git-tag`, but rather create a tmp file. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>