Please read and understand the comment:
Never rebase branches or trees that you pulled.
Only rebase local branches.
But yes, rebased commits look nicer.
Also nice:
- squashing your commits so your eventual commit is just one virtual commit
instead of your transient commits; I haven't quite figured out when this is
done automagically, and when not. Anyone have guidance, especially
relating to rebasing? I just do the git commit algebra until the tree
looks right, checking what the tree looks like with GitX. Sometimes I need
to try a couple of times.
- making your commit comment's 1st line "[CB-xyz]
description-of-issue-xyz-here". I frankly don't give much of a shit about
limiting the 1st line of the comment to 50 chars, like some folks do; I
guess it makes some command-line logging prettier. ~shrug~
- in the issue you have open for commit, BECAUSE YOU ALWAYS HAVE AN ISSUE
OPEN FOR A COMMIT, please post the link to the commit from the (horrific
but survivable) apache Git repo viewer.
For extra credit, someone could automate all this junk. WebKit does this,
with Bugzilla, SVN, and their git-svn interface. You basically never have
to deal with low-level committing, or adding comments to issues, etc - you
use a command-line tool which posts your patches (somewhere, in their case,
Bugzilla attachments), which kicks off a build, which will then commit your
code for you if it passes the tests in the build, annotating your commits,
issues along the way, and has two-way IRC interaction as well; it posts IRC
messages on the status of what's going on, and responds to IRC messages
from users to roll-back commits, etc.
It's pretty f'ing awesome.
On Tue, Mar 27, 2012 at 18:30, Filip Maj <f...@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" <f...@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.be...@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
> >
>
>
--
Patrick Mueller
http://muellerware.org
