Thanks, appreciate the detailed response, Fil. I'm determined to become a git guru! -becky
On Tue, Mar 27, 2012 at 6:30 PM, Filip Maj <[email protected]> wrote: > This one's pretty good too > http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into- > the-mysteries-of-revision-control/ > > On 3/27/12 3:20 PM, "Filip Maj" <[email protected]> wrote: > > >Yes, a merge commit is correct and expected behavior following a merge. It > >is unlike a "standard" commit in that it has TWO parent commits. > > > >This is why, as fellow PhoneGap hacker Andrew Lunny once said, "merge > >commits are for people who drink blended whiskey and listen to > >Nickelback". No offense to those who do either! ;) > > > >In my mind, I see a merge commit as "dirtier" - git will do some magic to > >combine the two trees from the parent commits into one. > > > >A cleaner approach IMO is running a REBASE. > > > >Simple ASCII example (with "-" being a commit), you have a master tree (M) > >and a topic branch (B): > > > >-----*-- (M) > > `-- (B) > > > >Above, the topic branch branched off the master tree two commits prior to > >the master tree's HEAD commit (last commit). > > > >If you MERGED B into M, you would get: > > > >-----*--= (M) > > `--' > > > >Where the "=" is a merge commit that has two parents. > > > >If you REBASED, the situation would be different: first, all of the new > >commits in B would be rewound (to the first asterisk), all of the new > >commits in M that B did not have would be applied, and then the commits > >from B would be re-applied one-at-a-time on top of the HEAD commit from M. > >So you end up getting a final tree that looks like: > > > >-------(H)--(B) > > > >A single tree, no branches merging in/out. > > > >I really like this blog post in terms of explaining and visualizing the > >difference between merges and rebases, and why rebases are da bomb: > >http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful-rebase/ > > > >On 3/27/12 2:54 PM, "Becky Gibson" <[email protected]> wrote: > > > >>Ok, so I thought I had a process for committing to Apache git that works. > >> But, since I can't seem to cleanly submit to the mobile-spec repo I am > >>going to publicly admit my ignorance and ask for clarification. > >> > >>My local clone of mobile spec was a mess so I created it again. > >> > >> > >>I cloned my fork of apache-cordova-mobile-spec - this gives me a remote > >>named origin > >>I create a remote named apache to > >> > https://git-wip-us.apache.org/repos/asf/incubator-cordova-mobile-spec.git > >>pull apache master to get everything up to date > >>push origin master so that is up to date > >>fetch origin mediaErr (an existing branch with work I want to commit) - > >>that creates a mediaErr branch on my local clone > >>checkout mediaErr > >>log -5 to verify the log shows the commit I want to push to master > >>checkout master > >>merge mediaErr > >>push apache master - this commits my media change with the original date > >>(March 20) and the commit comment shows "merge branch mediaErr". Is this > >>right? Not sure how else I would have gotten the media change committed? > >>Should I have created a new comment? > >> > >> > >>any explanation appreciated, > >>-becky > > > >
