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

[Jakub Narebski <jnareb@gmail.com>]

Michael Dressel <MichaelTiloDressel@t-online.de> writes:
> On Sat, 15 Dec 2007, Jakub Narebski wrote:
>> Michael Dressel <MichaelTiloDressel@t-online.de> 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.
-- 
Jakub Narebski
Poland
ShadeHawk on #git