Good luck Becky! Fil has been my git mentor too! Go Fil! On Wed, Mar 28, 2012 at 10:56 PM, Becky Gibson <[email protected]>wrote:
> 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 > > > > > > > >
