git force merge - Already Up To Date

Question

Is it possible to merge a tag to a branch when the changes are already incorporated into the branch? I'm trying to populate the Precedes line in gitk

Edit: When I do git merge <TAG> it fails to merge since the branch doesn't have any differences.

Edit2: We are using a gitflow process where we have master, develop, and PTR branches. Our process is to make a release branch from develop. Once tested the release branch is squashed and merged to master. The squashed commit is tagged on master. Then tag is then merged back to the release branch and then merged to develop. The issue we're running into is commits on release do not Precede the tag. It makes it difficult to verify if a commit was part of a build

What do you exactly mean that "the changes are already incorporated into the branch"? — kosist, Sep 21 '20 at 19:07
do you mean your tag failed ? or branch failed ? or remote failed ? or you have a commit in advance ? — francois P, Sep 21 '20 at 19:52
A tag name just points to a commit, or to an annotated object that points to a commit. You should not normally move any tag as other Git repositories that have copied that tag do not expect it to move. — torek, Sep 22 '20 at 01:30
I didn't say anything about moving the tag. I want to force merge the tag to master. ie master contain the tag. — EncryptedWatermelon, Sep 22 '20 at 11:58
If `git branch --contains thattag` includes master then all of that tag's history is already in master's history, there's nothing to merge. If `git branch --contains thattag` doesn't include master, could you provide whatever evidence led you to say "contains" edit: / "incorporated"? — jthill, Sep 23 '20 at 23:10

VonC · Accepted Answer · 2020-09-24T14:31:26.010

when the changes are already incorporated into the branch?

That means:

-x--x--x--x--x (master)
         /
 -y--y--y--y--y (abranch)
        |
     (tagT)

Since the tag reference a commit which was already merged to master, ant git merge <atag> will be a no-op.
And the tag won't be part of the master branch, it remains part of abranch.

That means git branch --contain <aTag> won't include master.
See also "Verify if a tag was done in the master branch".

In the new gitflow context provided by the OP:

Our process is to make a release branch from develop.
Once tested the release branch is squashed and merged to master
The squashed commit is tagged on master

                 (aTag)
                   |
   -m--m--m--m--m--R (master, with release squashed-commit)
         
     r--r--r--r (release)
    /
-d--d--d (develop)

Then tag is then merged back to the release branch and then merged to develop

                 (aTag)
                   |
   -m--m--m--m--m--R   (master, with release squashed-commit)
                    \------------\
     r--r--r--r-----r' (release)  \
    /                              \
-d--d--d---------------------------d' (develop)

The issue we're running into is commits on release do not Precede the tag. It makes it difficult to verify if a commit was part of a build

From the schema:

if a commit has two parents
aTag is reachable from the second parent (git describe aCommit^2)

Then that commit is part of the "aTag" build.

The problem, indeed:

The problem is in gitk, r1,r2,r3,r4 do not show a Precedes: <tag> that was merged in r'

I agree. Gitk won't be able to show that tag.
I would put a tag to r', with a similar name as aTag, in order to get a better idea of the "Precedes" part in Gitk.

Everything you wrote looks like what I described. The problem is in gitk, r1,r2,r3,r4 do not show a Precedes: that was merged in r' — EncryptedWatermelon, Sep 24 '20 at 14:25
@EncryptedWatermelon I agree. Gitk won't be able to show them. I would put a tag to `r'`, with a similar name as `aTag`, in order to get a better idea of the "`Precedes`" part in Gitk. — VonC, Sep 24 '20 at 14:30
Oh, good point. I should tag the RC and that should be good enough. Thanks! — EncryptedWatermelon, Sep 24 '20 at 14:34

git force merge - Already Up To Date

1 Answers1