Skip to content

dim: local_tag_branch variant

Out of frustration of almost losing the entire tag summary and trying to bend myself to a different workflow, this is what I thing dim tag_branch should really be. At least it fits better my workflow. I realize others have different workflow so instead of trying to convert the current tag_branch, I'm just adding a different function. If people agree, then I can try to blend this in the current dim_tag_branch (which is kind of hard because currently dim_tag_branch has an optional upstream arg.

Differences from the current workflow:

    - Adding the tag is a *local* operation. It won't do anything in
      the remote, so you don't risk thinking "oh, crap I'm tagging
      the wrong commit, should abort", just to let the wrong tag be
      pushed to the remote.

    - upstream arg is mandatory. If the intention was to avoid
      needing gitk, we could probably wrap it under $DIM_GITK and do
      nothing if unset. Another option would be to have a
      branch_to_upstream. Then remove the arg.

    - Always use -s to sign and delegate to git config what is used
      to sign. We shouldn't create unsigned tags in 2024 anymore.

    - Redirect stdout/stderr from gitk so it doesn't keep writing
      garbage while I'm trying to type the tag contents. This can be
      easily merged in the current tag_branch

I think this works better. It's maintainer responsibility to then push the tag when creating the pull request. That logic belongs to the pull request submission.

TODO: add documentation if this is kept as an alternative, or amend the current tag-branch doc if we find a way.

This also includes a fix to dim_pull_request that should land independently.

Merge request reports