-1

I have two remote repositories remoteA and remoteB (one is the mirror) of the other. I commit one change to remoteA and I also plan to make the same change to remoteB.

I could just use below command to port the change from remoteA to remoteB:

git push remoteB COMMIT_HASH_FROM_REMOTEA:mainline

Another way is that I could use git cherry-pick to pick COMMIT_HASH_FROM_REMOTEA in a local branch tracking remoteB branch and then push this commit.

I notice if I use the first approach, the commit id would be the same for both remotes. But for the second approach, the commit id are different.

Is git smart enough to figure out the different commit id are actually identical under the second approach? In other words, if I use the second approach to push the change to remoteB, would this bring any troubles (eg: merge conflicts) for others also work on these two remotes since git somehow thinks these two remotes start to diverge?

Thank you.

Bostonian
  • 615
  • 7
  • 16
  • 2
    `cherry-pick` will always produce a new commit hash. – Jonathon Reinhart Jun 16 '20 at 02:01
  • yeh, my question is more like does `git cherry-pick` also keep some metadata about where this commit originates from, so even under the second approach, we could still say these two remotes does not diverge. – Bostonian Jun 16 '20 at 02:07
  • 2
    No. The commit "originates" from the parent you cherry-pick it onto. – matt Jun 16 '20 at 02:10
  • 2
    Your notion "diverge" makes no sense. Git looks at the commit, not the history. The only time git ever looks at history is when you merge. – matt Jun 16 '20 at 02:12
  • 2
    I recommend using `git cherry-pick -x` when you're picking from a published branch. It records the originating commit hash (just in the commit message). – Jonathon Reinhart Jun 16 '20 at 02:13

3 Answers3

1

So you have two remote repositories with copies of the same code? That’s a little bit of a confusing workflow to say the least. Are these branches and not separate repositories?

Here’s info on your cherry pick commit hashing stuff.

I don’t think you should have issues with additional merge conflicts caused by this on top of whatever you might already have, but you may be able to use some alternative strategies (perhaps with git reset command line arguments) that could alleviate your hash issue.

yes-siz
  • 348
  • 2
  • 9
  • `git reset` will cause their new HEAD to point to whatever the other remote is at, and their changes will not be in the branch. Depending on how divergent it is, that may not be desired. Don't obsess over commit hashes. – robbyoconnor Jun 16 '20 at 02:11
  • Note that I said git reset [command line arguments](https://git-scm.com/docs/git-reset), not just git reset. – yes-siz Jun 16 '20 at 02:14
  • No worries! It happens all the time, and it’s also partly my fault for not bothering to hyperlink my original comment. – yes-siz Jun 16 '20 at 02:16
1

The reason the commit IDs change is because when you do a cherry-pick, the committer ID and timestamp are updated to your ID and the current timestamp and the committer information is included in the hash.

My recommendation is that you just push the same commit. If you know that the branch is named mainline on remoteA, you can just write git push remoteB remoteA/mainline:mainline, which may be easier.

If you decide to cherry-pick and both sides contain the same content, then there won't be any merge conflicts. Merges consider the blobs and the trees, and the root trees on both sides will be identical, so the merges will be trivial.

bk2204
  • 64,793
  • 6
  • 84
  • 100
1

A cherry-pick is a very different thing from simply pushing a commit to a different place.

  • A commit is just a commit and that's all it is. The state of the files is the state contained in that commit. You are saying, "Be this."

  • A cherry-pick is a diff. It is derived by comparing the picked commit to its parent and making a patch. That patch is then applied to where you pick to, to make a new commit that does to the existing head commit what the picked commit did to its parent. You are saying, "Mutate in this way."

    This can give you merge conflicts and all sorts of issues if the changes cannot be coherently played out on the existing head commit. In your case that might not happen, but why bother with such complexity?

So I would say cherry picking is a bad idea here. If you know the state you want to push, push that state, not some complicated patch thing.

Community
  • 1
  • 1
matt
  • 515,959
  • 87
  • 875
  • 1,141