incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: seeking git help
Date Wed, 28 Mar 2012 14:40:29 GMT
Good luck Becky! Fil has been my git mentor too! Go Fil!

On Wed, Mar 28, 2012 at 10:56 PM, Becky Gibson <gibson.becky@gmail.com>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 <fil@adobe.com> 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" <fil@adobe.com> 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" <gibson.becky@gmail.com> 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
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message