Git reset --soft BUT preserve Merge workflow

Question

Question:

How do you preserve the branch merge workflow using git reset --soft

Why:

I'm trying to make some auto versioning Git actions. And the 1st implementation is making two (2) nodes indicating a pull request and an autoversioning.

I'm trying to use the following code in the git action to combine the changes

                 - name: Soft Reset to add changes to PR    
                   run: |
                     git config user.name github-actions
                     git config user.email github-actions@github.com
                     git reset --soft "HEAD~2"
                     git commit --amend --message="Version ${{ env.MYVERSION }}"
                     git push --force

What happens is that it properly combines the two (2) commits, but it breaks the diagonal line in the workflow signaling that the branches were merged.

I feel like I'm close, but I'm missing a key item.

2nd bonus question. How would I merge the two commits messages? 'cause I get the new message I force, but I would like the PR commit message too if possible.

Thank you for your time and consideration.

Answer 1

How do you preserve the branch merge workflow using git reset --soft

You don't.

A merge commit is a commit with two or more parents.

After git switch name followed by git reset --soft hash-ID-or-other-commit-specifier, you:

• are "on" branch name (still);
• the name name now selects the commit specified by the hash ID you gave in the git reset operation, instead of the previous tip commit;
• Git's index aka staging area contains the files from the old tip commit; and
• your working tree contains the same files as Git's index.

But running git commit now makes a new ordinary, i.e., single-parent, commit.

Running git commit --amend (as you're doing) makes a new commit whose parent(s) is/are the current commit's parent(s). These are not the same parents as the original merge commit, since you've reset that one away. To get the same parents, you wouldn't reset the merge away in the first place.

You could run git commit-tree—a low-level "plumbing" command—to make a new merge commit. If you plan to do this, though, there's again no reason to use git reset --soft in the first place, as git commit-tree takes the following inputs:

• -p flag: supplies each parent hash ID (one -p flag per parent hash ID);
• -F file or -m message: supplies the commit message text;
• tree: supplies the Git hash ID of the tree you want as the saved snapshot.

The output from git commit-tree is a raw hash ID, which you must then shove into the branch name, the way git commit would; in general you do this with the git update-ref plumbing command.

If you need an updated tree object, you'd git add files to the index as usual and then use git write-tree—yet another plumbing command—to create the tree object first.

If your goal is to update a version file in the merge, rather than as a separate step after the merge, you again don't need a soft reset: instead, you'd check out the merge commit, update the version file, and do a git commit --amend while on the merge commit to make a new merge commit to replace the old merge commit. Note, however, that the result is technically an evil merge.

To avoid the evil merge, simply make the revision bump a separate commit, which requires no fanciness in the first place.