Hello Jakub,

Thank you for addition. Eventually, I've merged your explanations into single 
answer post 
 ). 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:jna...@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:
> 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.

> 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

Reply via email to