Re: git merge --no-commit <branch>; does commit
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Dec 15, 2007, 18:26 UTC
- Message-ID
- <20071215182653.GB22485@atjola.homenet>
- In-Reply-To
- <alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos>
On 2007.12.15 19:14:48 +0100, Michael Dressel wrote:
Show 24 quoted lines
> > > On Fri, 14 Dec 2007, Alex Riesen wrote: > >> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100: >>> On Thu, 13 Dec 2007, Alex Riesen wrote: >>>> On 13/12/2007, Michael Dressel wrote: >>>>> git merge --no-commit <branch> does "create" a commit. At lesat the >>>>> head and index are moved to the new commit fetched from <branch>. Maybe >>>>> that is because git was able to do a fast forward? >>>> >>>> Yes. Because fast-forward is what it called: fast-forward. >>>> It does not do any commits at all. >>>> >>> >>> It looks like I misunderstood the meaning of --no-commit. I have to use >>> --squash in this case. >>> >> >> 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?
A "real" merge commit has at least two parents, and retains the individual commits of each branch in the history. It just connects two lines of history. --squash just takes all changes and produces a single-parented commit, destroying the individual commits that originally introduced the changes.
Show 5 quoted lines
> 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?
If you didn't publish your topic branch, use interactive rebasing to re-order/edit your commits.
Björn