From: Michael Dressel <michaeltilodressel@t-online.de>
Date: Sat, 15 Dec 2007 20:33:20 GMT
Subject: Re: git merge --no-commit <branch>; does commit
Message-ID: <alpine.LSU.0.99999.0712152124220.5151@castor.milkiway.cos>
In-Reply-To: <20071215193741.GB3021@steel.home>



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.

>
>> 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?
>
> I would not recommend doing it at all. If I must, I'd rather use
> git-rebase -i (interactive rebase).
>
>

Yes I didn't use rebase sofar. I should consider it sometimes.

Cheers,
Michael