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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Dressel, Sat, Dec 15, 2007 21:33:20 +0100:
> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux