I have seen a few similar questions as this, but the solutions listed there do not seem to work for us.
We have a repo containing a number of different subtrees. For some of them, git subtree push works fine, for others it fails with the following:
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
We are focusing on one of these broken subtrees to identify the issue.
In our main repo, we have a branch (we'll call it BranchA) from which the subtree was previously split out (git subtree split followed by git push of the split branch). The remote BranchA was then reintroduced as:
git subtree add --prefix=/path/to/subtree SubtreeRemoteName BranchA
The subtree's remote repository currently only contains a single commit (017f3783), which we gave the same BranchA name.
I can see where the split was added back in BranchA's history as:
$ git show df968c
commit df968c95dd2cd3f2ea1f4e059dfd19b1661d275d
Merge: 6f86ff21 017f3783
Author: Me
Date: Wed Nov 29 11:50:56 2017 -0600
Add 'path/to/subtree' from commit '017f3783af9260c0de29a85916bc5f4776c186c2'
git-subtree-dir: path/to/subtree
git-subtree-mainline: 6f86ff21afbed1a0da60f4019ae20c43f28ee5db
git-subtree-split: 017f3783af9260c0de29a85916bc5f4776c186c2
Since initially adding the subtree, various things have been commited into the main repository's BranchA and we are now attempting:
git subtree push --prefix=path/to/subtree SubtreeRemoteName BranchA
which returns the above error.
Things we have tried:
git subtree pull --prefix/path/to/subtree SubtreeRemoteName BranchA
Returns:
From https://ourgitserver/path/to/subtree/repo
* branch BranchA -> FETCH_HEAD
+ 50a42087...017f3783 BranchA -> SubtreeRemoteName/BranchA (forced update)
Already up-to-date.
I did find the "forced update" comment there potentially interesting, but seeing as the commit hashes seem to still line up, I don't know if it matters.
Further, running:
git branch --contains 017f3783
Returns:
* BranchA
Confirming that the necessary commit is, in fact, already in BranchA.
One SO question (Git subtree - subtree up-to-date but can't push) suggested that the subtree push should be broken apart into separate split/push commands and the force flag added to the push. While that does work (in the sense that the push succeeds), it also rewrites the existing commit, which will break our other repos that also have this as a subtree.
If I checkout a new branch from the commit immediately prior to splitting out this branch and run a new split of the subtree (essentially repeating the split that was originally done):
git subtree split --prefix=path/to/subtree -b TempBranch
As expected, the created TempBranch appears with the same hash (017f3783) which is then merged in as shown in the earlier merge commit. Interestingly, if I try to delete the TempBranch, it acts like it isn't merged:
$ git branch -d TempBranch
error: The branch 'TempBranch' is not fully merged.
If you are sure you want to delete it, run 'git branch -D TempBranch'.
It requires a force delete (-D flag) to actually delete it.
If I instead run the same split from the current BranchA, I get a single commit which has no parent:
$ git show bcc9f
commit bcc9f244f855d99ee1547ee309ba1606ed7a35fc
Author: Me
commit bcc9f244f855d99ee1547ee309ba1606ed7a35fc
Author: Me
Date: Wed Nov 29 15:49:50 2017 -0600
Commit text.
Running split, but passing the "onto" flag:
git subtree split --prefix=path/to/subtree -b TempBranch --onto=017f3783
Just creates that same bcc9f244 commit that has no parent.
Any suggestions?
