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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Dec 16, 2007, 10:53 UTC
Message-ID: <20071216105311.GA2937@steel.home>
In-Reply-To: <alpine.LSU.0.99999.0712152124220.5151@castor.milkiway.cos>

Michael Dressel, Sat, Dec 15, 2007 21:33:20 +0100:

Show 17 quoted lines

> On Sat, 15 Dec 2007, Alex Riesen wrote:
>> Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:
>>>> 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?
>>
>> Because merge, in Git language, means connection histories. That one
>> just mixes the text. That's different operation, kind of editing a
>> file.
>
> That's a nice clarification. In my case I wanted that "just mixes the text" 
> thing because I did aggressively do commits during development trying out 
> slightly different approaches and being able to go back to compare them. 
> These different games are not interesting to keep in the history once a 
> good solution has been found.

In this case --squash is almost right. "rebase -i" (interactive rebase) still better: it'll allow you rebuild the development history in a more fine-grained way. It can reorder commits, "mix" them together, edit commit messages or just delete them altogether. Try it, by the look of your situation you'll like it. Actually, it is exactly why Johannes wrote it.