Re: git merge --no-commit <branch>; does commit

> Michael Dressel writes:
>> On Sat, 15 Dec 2007, Jakub Narebski wrote:
>>> Michael Dressel writes:
>>>>
>>>> Since "git merge --squash <branch>" does a merge of <branch> into the
>>>> working tree why would you not call it a merge?
>>>
>>> A few illustrations. Commits A, B, C were made on 'trunk', commits
>>> a, b, c were made on 'branch'. You are on 'trunk', running
>>> "git merge <options> branch". We assume that there are no conflicts.
>>>
>>> 1. A non fast-forward case
>>>
>>>   1---2---3---A---B---C   <-- trunk    <-- HEAD
>>>            \
>>>             \-a---b---c   <-- branch
>
>>> 1.2. "git merge --no-commit branch"
>>>
>>>                        /-------- trunk  <-- HEAD
>>>                       v
>>>   1---2---3---A---B---C--*
>>>            \            /
>>>             \-a---b---c/     <-- branch
>>>                       ^
>>>                        \-------- MERGE_HEAD
>>>
>>> The merge commit '*' is prepared, but not yet committed, just
>>> as if there were merge conflict during merge. "git commit"
>>> would commit a merge (and would tell you that it does a merge
>>> commit).
>
>>> 1.4. "git merge --squash branch"
>>>
>>>   1---2---3---A---B---C--[abc]'   <-- trunk <-- HEAD
>>>            \
>>>             \-a---b---c           <-- branch
>>>
>>> "[abc]'" is a _single parent_ commit (it is not a merge commit!)
>>> which incorporates changes made on branch as if it were made in
>>> a single, large (!) commit.
>>
>> Thanks alot for the elaborate explanations.
>
> You are welcome
>
>>> Test of understanding the concepts: what does
>>> "git merge --squash --no-commit" does?
>>>
>>
>> From the man page it sounds "git merge --squash --no-commit" would do
>> the same as "git merge --squash". So in the example 1.4 [abc] should
>> not be a commit.
>
>                       /---------\
>                       v          \
>   1---2---3---A---B---C--*[abc]'  \-- trunk <-- HEAD
>            \
>             \-a---b---c           <-- branch
>
> where *[abc]' is prepared state (staged but not committed changes)
> squashing achanges into commits a, b, c into trunk.
>
> Note that using "git rebase --interactive" you can squash, reorder
> and edit commits; if you rather work in this way, reordering, editing
> etc. "on the go" you perhaps should consider patch-management
> interfaces like StGIT (Stacked GIT) or Guilt (formerly gq).
>
> BTW. in practice [abc]' in squash case is the same as M in normal
> case, only M has two parents recorded, and [abc]' does not.