RE: git merge deletes my changes
- From
- Eduard Egorov <eduard.egorov@icl-services.com>
- Date
- Oct 12, 2016, 05:51 UTC
- Message-ID
- <AM4PR03MB1636DC3017FFA1DE57BAABADDBDD0@AM4PR03MB1636.eurprd03.prod.outlook.com>
- In-Reply-To
- <94ff5fb3-6957-8983-4aa7-e1d5e2692e82@gmail.com>
Hello Jakub,
Thank you for addition. Eventually, I've merged your explanations into single answer post (http://stackoverflow.com/questions/39954265/git-merge-s-subtree-works-incorrectly/ ). I hope this will prevent other confused people from disturbing you by similar emails on this mailing list.
This is another time I can evidence the power and flexibility the git provides, thank you all for your great work!
With best regards Eduard Egorov
-----Original Message----- From: Jakub Narębski [mailto:jnareb@gmail.com] Sent: Tuesday, October 11, 2016 6:57 PM To: Paul Smith; Eduard Egorov; 'git@vger.kernel.org' Subject: Re: git merge deletes my changes
W dniu 10.10.2016 o 19:52, Paul Smith pisze:
Show 18 quoted lines
> On Mon, 2016-10-10 at 10:19 +0000, Eduard Egorov wrote: >> # ~/gitbuild/git-2.10.1/git merge -s subtree --squash ceph_ansible >> >> Can somebody confirm this please? Doesn't "merge -s subtree" really >> merges branches? > > I think possibly you're not fully understanding what the --squash flag > does... that's what's causing your issue here, not the "-s" option. > > A squash merge takes the commits that would be merged from the origin > branch and squashes them into a single patch and applies them to the > current branch as a new commit... but this new commit is not a merge > commit (that is, when you look at it with "git show" etc. the commit > will have only one parent, not two--or more--parents like a normal > merge commit). > > Basically, it's syntactic sugar for a diff plus patch operation plus > some Git goodness wrapped around it to make it easier to use.
Actually this is full merge + commit surgery (as if you did merge with --no-commit, then deleted MERGE_HEAD); the state of worktree is as if it were after a merge.
Show 11 quoted lines
> > But ultimately once you're done, Git has no idea that this new commit > has any relationship whatsoever to the origin branch. So the next > time you merge, Git doesn't know that there was a previous merge and > it will try to merge everything from scratch rather than starting at > the previous common merge point. > > So either you'll have to use a normal, non-squash merge, or else > you'll have to tell Git by hand what the previous common merge point > was (as Jeff King's excellent email suggests). Or else, you'll have > to live with this behavior.
The `git subtree` command (from contrib) allows yet another way: it squashes *history* of merged subproject (as if with interactive rebase 'squash'), then merges this squash commit.
Now I know why this feature is here... -- Jakub Narębski