{"thread":{"id":"60410","subject":"Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'","startedAt":"2023-10-20T19:46:38Z","lastAt":"2023-10-26T03:23:47Z","messageCount":2,"participants":["Yuri","Thomas Guyot"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"483596","messageId":"dd4befe1-dea7-b27d-720d-9f1616b129ee@tsoft.com","threadId":"60410","inReplyTo":null,"subject":"Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2023-10-20T19:46:35Z","receivedAt":"2023-10-20T19:46:38Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"I use git-p4 to use the perforce repository through git.\n\n\nThere are 3 branches:\n\n* master\n   remotes/p4/HEAD -> p4/master\n   remotes/p4/master\n\ngit-p4 syncs remotes/p4/HEAD with the perforce repository.\n\nThen the user (me) needs to merge remotes/p4/HEAD into master.\n\nInitially such merge doesn't cause \"Merge remote-tracking branch \n'remotes/p4/HEAD'\" commits.\n\nBut then, after several cycles of submit/sync something happens, and git \nforces me to commit with the \"Merge remote-tracking branch \n'remotes/p4/HEAD'\" comment.\n\n\nWhat makes the merge from remotes/p4/HEAD into master to require \"Merge \nremote-tracking branch 'remotes/p4/HEAD'\"?\n\nWhat does this mean?\n\nWhat is changed in remotes/p4/HEAD or master that later requires this?\n\nHow to eliminate the need for \"Merge remote-tracking branch \n'remotes/p4/HEAD'\"?\n\n\n\nThanks,\n\nYuri\n\n\n"},{"id":"483878","messageId":"7e307505-3536-4671-a302-3ff13649617d@gmail.com","threadId":"60410","inReplyTo":"dd4befe1-dea7-b27d-720d-9f1616b129ee@tsoft.com","subject":"Re: Why sometimes branch merging is associated with this commit: Merge remote-tracking branch 'remotes/p4/HEAD'","fromName":"Thomas Guyot","fromEmail":"tguyot@gmail.com","sentAt":"2023-10-26T03:23:42Z","receivedAt":"2023-10-26T03:23:47Z","isPatch":false,"sender":{"key":"tguyot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/403890?v=4"},"body":"Hi Yuri,\n\nOn 2023-10-20 15:46, Yuri wrote:\n> I use git-p4 to use the perforce repository through git.\n>\n>\n> There are 3 branches:\n>\n> * master\n>     remotes/p4/HEAD -> p4/master\n>     remotes/p4/master\n>\n> git-p4 syncs remotes/p4/HEAD with the perforce repository.\n>\n> Then the user (me) needs to merge remotes/p4/HEAD into master.\n>\n> Initially such merge doesn't cause \"Merge remote-tracking branch\n> 'remotes/p4/HEAD'\" commits.\n>\n> But then, after several cycles of submit/sync something happens, and git\n> forces me to commit with the \"Merge remote-tracking branch\n> 'remotes/p4/HEAD'\" comment.\n>\n>\n> What makes the merge from remotes/p4/HEAD into master to require \"Merge\n> remote-tracking branch 'remotes/p4/HEAD'\"?\n\nI believe what is happening is once other developers merge code in the \nsame branch your master branch ends up like a topic branch that never \nmerge back to the remote tracking branch.\n\nI've worked a lot more with git-svn but both behaves somewhat similarly \nAFAIK - when you \"send\" your commit upstream (I'm using \"send\" as I \ndon't recall the exact terminology for git-p4) what really happen is \nlike if your commit was cherry-picked on top of the remote branch - P4 \ntracks commits linearly and has an incompatible concept of merges.\n\nWhen you sync later, it will get both your commits and other developer's \ncommit, but because they don't have the same history anymore git has no \nchoice but to merge the branches (this doesn't happen initially if \nyou're the only committer as your branch remain sync with the remote).\n\n> What does this mean?\n>\n> What is changed in remotes/p4/HEAD or master that later requires this?\n>\n> How to eliminate the need for \"Merge remote-tracking branch\n> 'remotes/p4/HEAD'\"?\n>\n\nYou probably don't \"need\" to eliminate this, you can just keep creating \nnew commits on top and pushing them. The end result will be the same for \nother p4 users.\n\nIf you still want to re-sync with upstream all you have to do is to \nrebase on top of the remote tracking branch. You'll end up with the same \nwork tree but your history will get \"linearized\" based on the commits in p4.\nLet's take for example this branch:\n\nA---B---C [master, remotes/p4/HEAD]\n\nNow imagine you and another developer both work on the repo separately \n(let's assume different files, no possible conflicts) and the other \ndeveloper commits before you in p4, you end up with:\n\nA---B---C---E [remotes/p4/HEAD]\n          \\\n`-D [master]\n\nWhen you send *your* change, D, on the p4 repo, it cannot merge like git \ndoes. It will instead apply your commit on top of E - we'll call your \ncommit D' as it's now a different commit hash, although it's the same \nchange:\n\nA---B---C---E---D' [remotes/p4/HEAD]\n          \\\n           `-D [master]\n\nNow if you sync with p4, git can't fast-forward anymore because D and D' \nare different commits (and don't even have the same parent!) therefore \nit will merge (F) with the remote tracking branch:\n\nA---B---C---E---D' [remotes/p4/HEAD]\n          \\       \\\n           `-D-----+-F [master]\n\nF and D' are identical, they have the same work tree contents, but have \na different commit hash (implied by the difference in parents). If you \nrebase master to remotes/p4/HEAD git will discard the duplicate D commit \nfrom your branch and restore it at the tip of remotes/p4/HEAD. If you \nhas any new commit after F, those would be applied after D', for ex:\n\nA---B---C---E---D' [remotes/p4/HEAD]\n          \\       \\\n           `-D-----+-F---G [master]\n\nRebases to:\n\nA---B---C---E---D' [remotes/p4/HEAD]\n                  \\\n                   `-G' [master]\n\n\nPersonally I would always rebase with the remote repo, and with git-svn \nI was actually doing that systematically before pushing anything (I \nthink I had no choice anyway, or maybe I just didn't want any local \nmerge commits...) In any case you should be able to rebase with the p4 \nremote tracking branch before or after committing into p4 and that will \nkeep your history in line with p4's history.\n\nRegards,\n\n-\nThomas\n"}]}