Re: git merge deletes my changes
- From
Jeff King <peff@peff.net>
- Date
- Oct 10, 2016, 15:26 UTC
- Message-ID
- <20161010152626.frc3ypflwnhzidea@sigill.intra.peff.net>
- In-Reply-To
- <AM4PR03MB1636D18D727968F332F16021DBDB0@AM4PR03MB1636.eurprd03.prod.outlook.com>
On Mon, Oct 10, 2016 at 09:39:13AM +0000, Eduard Egorov wrote:
Show 5 quoted lines
> A week ago, I've reset a state of 'ceph-ansible' folder in %current% > branch with code from corresponding branch (that tracks an upstream > from github): > > # git read-tree --prefix=ceph-ansible/ -u ceph_ansible
This pulls in the subtree files, but there's no actual relationship with the commit history in ceph_ansible.
So later...
Show 15 quoted lines
> Then I've committed several changes, including: > > 1. Renamed file and commited: > # git mv site.yml.sample site.yml > > 2. Made some changes and committed > > 3. Pulled updates from original branch by: > # git merge -s subtree --squash ceph_ansible > > It said: > Auto-merging ceph-ansible/site.yml.sample > blablabla > Squash commit -- not updating HEAD > Automatic merge went well; stopped before committing as requested
When you merge from ceph_ansible, there is no shared history, and git uses the empty tree as a common ancestor. It looks like the other side added site.yml.sample, for instance, because that is a change from the empty tree.
> A post on SO: http://stackoverflow.com/questions/39954265/git-merge-deletes-my-changes
As you noted on SO, modern git disallows merges of unrelated history by default, because it's usually a mistake to do so.
If you are doing repeated merges into the subtree, you need to somehow tell git how the histories are related. The obvious answer is to do a "git merge -s ours ceph_ansible" after your initial read-tree, so that git knows you've pulled in the changes up to that point. But I'd guess from your use of "--squash" that you don't want to carry the ceph_ansible history in your project.
So you need to record the original upstream commit somewhere (probably in the commit message when you commit the read-tree result), and then ask git to use that as the merge-base during subsequent merges (which will require using plumbing codes, as git-merge wants to compute the merge base itself). I believe the git-subtree command (in contrib/subtree of git.git) handles this use case, but I haven't used it myself.
-Peff