From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Sat, 15 Dec 2007 18:26:53 GMT
Subject: Re: git merge --no-commit <branch>; does commit
Message-ID: <20071215182653.GB22485@atjola.homenet>
In-Reply-To: <alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos>

On 2007.12.15 19:14:48 +0100, Michael Dressel wrote:
>
>
> On Fri, 14 Dec 2007, Alex Riesen wrote:
>
>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:
>>> On Thu, 13 Dec 2007, Alex Riesen wrote:
>>>> On 13/12/2007, Michael Dressel wrote:
>>>>> git merge --no-commit <branch> does "create" a commit. At lesat the
>>>>> head and index are moved to the new commit fetched from <branch>. Maybe
>>>>> that is because git was able to do a fast forward?
>>>>
>>>> Yes. Because fast-forward is what it called: fast-forward.
>>>> It does not do any commits at all.
>>>>
>>>
>>> It looks like I misunderstood the meaning of --no-commit. I have to use
>>> --squash in this case.
>>>
>>
>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>> is not a merge.
>
> Since "git merge --squash <branch>" does a merge of <branch> into the 
> working tree why would you not call it a merge?

A "real" merge commit has at least two parents, and retains the
individual commits of each branch in the history. It just connects two
lines of history. --squash just takes all changes and produces a
single-parented commit, destroying the individual commits that
originally introduced the changes.

> Anyway that was what I wanted. Merging <branch> (a topic branch) into my 
> current branch (the main branch) but being able to create commits that are
> more suitable for keeping in the history of the current branch than the
> commits I created during developing on <branch>.
> Would you recommend a different way of doing this?

If you didn't publish your topic branch, use interactive rebasing to
re-order/edit your commits.

Björn