On 2007.12.15 19:14:48 +0100, Michael Dressel wrote: > > > 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. > 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 - 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
