incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: seeking git help
Date Wed, 28 Mar 2012 13:56:34 GMT
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