Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'

Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'

[Yuri]

I use git-p4 to use the perforce repository through git.


There are 3 branches:

* master
   remotes/p4/HEAD -> p4/master
   remotes/p4/master

git-p4 syncs remotes/p4/HEAD with the perforce repository.

Then the user (me) needs to merge remotes/p4/HEAD into master.

Initially such merge doesn't cause "Merge remote-tracking branch 
'remotes/p4/HEAD'" commits.

But then, after several cycles of submit/sync something happens, and git 
forces me to commit with the "Merge remote-tracking branch 
'remotes/p4/HEAD'" comment.


What makes the merge from remotes/p4/HEAD into master to require "Merge 
remote-tracking branch 'remotes/p4/HEAD'"?

What does this mean?

What is changed in remotes/p4/HEAD or master that later requires this?

How to eliminate the need for "Merge remote-tracking branch 
'remotes/p4/HEAD'"?



Thanks,

Yuri

Re: Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'

[Thomas Guyot]

Hi Yuri,

On 2023-10-20 15:46, Yuri wrote:
> I use git-p4 to use the perforce repository through git.
>
>
> There are 3 branches:
>
> * master
>     remotes/p4/HEAD -> p4/master
>     remotes/p4/master
>
> git-p4 syncs remotes/p4/HEAD with the perforce repository.
>
> Then the user (me) needs to merge remotes/p4/HEAD into master.
>
> Initially such merge doesn't cause "Merge remote-tracking branch
> 'remotes/p4/HEAD'" commits.
>
> But then, after several cycles of submit/sync something happens, and git
> forces me to commit with the "Merge remote-tracking branch
> 'remotes/p4/HEAD'" comment.
>
>
> What makes the merge from remotes/p4/HEAD into master to require "Merge
> remote-tracking branch 'remotes/p4/HEAD'"?

I believe what is happening is once other developers merge code in the 
same branch your master branch ends up like a topic branch that never 
merge back to the remote tracking branch.

I've worked a lot more with git-svn but both behaves somewhat similarly 
AFAIK - when you "send" your commit upstream (I'm using "send" as I 
don't recall the exact terminology for git-p4) what really happen is 
like if your commit was cherry-picked on top of the remote branch - P4 
tracks commits linearly and has an incompatible concept of merges.

When you sync later, it will get both your commits and other developer's 
commit, but because they don't have the same history anymore git has no 
choice but to merge the branches (this doesn't happen initially if 
you're the only committer as your branch remain sync with the remote).

> What does this mean?
>
> What is changed in remotes/p4/HEAD or master that later requires this?
>
> How to eliminate the need for "Merge remote-tracking branch
> 'remotes/p4/HEAD'"?
>

You probably don't "need" to eliminate this, you can just keep creating 
new commits on top and pushing them. The end result will be the same for 
other p4 users.

If you still want to re-sync with upstream all you have to do is to 
rebase on top of the remote tracking branch. You'll end up with the same 
work tree but your history will get "linearized" based on the commits in p4.
Let's take for example this branch:

A---B---C [master, remotes/p4/HEAD]

Now imagine you and another developer both work on the repo separately 
(let's assume different files, no possible conflicts) and the other 
developer commits before you in p4, you end up with:

A---B---C---E [remotes/p4/HEAD]
          \
`-D [master]

When you send *your* change, D, on the p4 repo, it cannot merge like git 
does. It will instead apply your commit on top of E - we'll call your 
commit D' as it's now a different commit hash, although it's the same 
change:

A---B---C---E---D' [remotes/p4/HEAD]
          \
           `-D [master]

Now if you sync with p4, git can't fast-forward anymore because D and D' 
are different commits (and don't even have the same parent!) therefore 
it will merge (F) with the remote tracking branch:

A---B---C---E---D' [remotes/p4/HEAD]
          \       \
           `-D-----+-F [master]

F and D' are identical, they have the same work tree contents, but have 
a different commit hash (implied by the difference in parents). If you 
rebase master to remotes/p4/HEAD git will discard the duplicate D commit 
from your branch and restore it at the tip of remotes/p4/HEAD. If you 
has any new commit after F, those would be applied after D', for ex:

A---B---C---E---D' [remotes/p4/HEAD]
          \       \
           `-D-----+-F---G [master]

Rebases to:

A---B---C---E---D' [remotes/p4/HEAD]
                  \
                   `-G' [master]


Personally I would always rebase with the remote repo, and with git-svn 
I was actually doing that systematically before pushing anything (I 
think I had no choice anyway, or maybe I just didn't want any local 
merge commits...) In any case you should be able to rebase with the p4 
remote tracking branch before or after committing into p4 and that will 
keep your history in line with p4's history.

Regards,

-
Thomas