0

We have been using git subtrees for a while, and there's a recurring issue I've only now pinpointed. We split some library code out to a separate git repo, and different people tend to work on both the subtree repo (I'll call remote from now on) and the original parent repo (I'll call parent). We don't normally squash, neither when pulling or pushing.

The issue is that, when pushing from parent to remote, the commits pushed have their hash changed. I can't tell whether this happens on every push or not (and it's hard to play around with since pushing takes 4+ hours), but every commit pushed had its hash changed last time I did a git subtree push. This causes issues down the line, where when we do a pull next time, odd merge conflicts happen, and these commits get pulled in again as if they were new, since their hashes differ.

The only thing I have to go on is an error that gets reported while pushing:

fatal: ambiguous argument '544c7a6e7cb3e15be01870bbfe3f30163de5cca6^0': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
could not rev-parse split hash 544c7a6e7cb3e15be01870bbfe3f30163de5cca6 from commit 702e4af8abb4a1c6b35301d5632c290f48095d8c

This does not stop the push from happening, it goes on as usual. Now, when looking at commit 702e4af8abb4a1c6b35301d5632c290f48095d8c, it's a squash merge from remote to parent. The commit message says:

 Squashed <prefix name> changes from 925a2ddd9e..544c7a6e7c

Commit 544c7a6e7c isn't in the parent's working tree, but it is in the remote, and it's a merge commit.

For now, I've resorted to doing a git pull, git push and then a git pull again to pull in the duplicate commits again. Obviously this results in duplicate commits and isn't ideal, but I'm at least hoping to get rid of the odd merge conflicts next time I pull from the remote.

This looks like a bug in git, since i would never expect a push to change commit hashes, but if the split hash error is causing it, I'm not sure how to fix it.

danronmoon
  • 3,814
  • 5
  • 34
  • 56
shwick
  • 105
  • 1
  • 9
  • 1
    It's literally impossible for `git push` to *change* a hash ID. However, `git subtree split` works by making *new* commits, and new commits *never* have the same hash ID as some old commit that they don't match. The magic for `git subtree split` is that when it makes new commits a second time, from original commits, it's supposed to make exactly-bit-for-bit-matching new commits, that therefore get the same hash ID as the last time it made those new commits. That is, the hash ID is a cryptographic checksum of the bits, so if you have the same bits, you get the same checksum. – torek Jul 31 '20 at 22:28
  • Note that `git subtree push` starts by running `git subtree split`; see the documentation for details. I've not used `git subtree` much and am not sure what actually is going wrong, though. – torek Jul 31 '20 at 22:29
  • You are correct, the existing commits don't change, it's the commits that end up in the remote repo that have different hashes. I'm pretty sure that if i were to do ```git subtree split``` this would also become apparent, but unfortunately that doesn't bring me any closer to understanding why it's happening – shwick Aug 01 '20 at 02:26

0 Answers0