cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: git frustration!
Date Thu, 21 Feb 2013 20:12:42 GMT
I was trying to follow #2 and didn't want the merge commit in the next
branch.  So,  I took a deep breath and slogged through.    I cherry-picked
each commit,  rebased to squash them together, merged into next and pushed
to next.  Then I could  checkout master, merge next, and then push master.
 I can live with the merge commits into master but I wanted to keep the
original author's commit info when I merged the fix into next.

git taxes my brain and my patience!  Thanks for the help!



On Thu, Feb 21, 2013 at 1:57 PM, Michal Mocny <mmocny@chromium.org> wrote:

> I had that same concern at some point, but I've just learned to live with
> them.  In the end, unless they are abused (such as doing work on master and
> having merge commit with each pull), merge commits can be useful and give
> insights, so shouldn't necessarily be avoided at all costs.
>
>
> On Thu, Feb 21, 2013 at 1:27 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > You get a merge commit any time you try to merge in a branch that is not
> > fast-forward (the internet can explain this better than I can).
> >
> > You have two options to not have a merge commit:
> > 1. Cherry-pick both commits, one after the other
> > 2. Create a local branch based off of the remote one, rebase it, and then
> > merge it
> >
> > The work-flow for #2 is on the committer's wiki page (replace master with
> > next for your case):
> >
> > git checkout master
> > git pull apache
> > git checkout topic_branch
> > git checkout -b to_be_merged
> > git rebase master -i
> > ...
> > git checkout master
> > git merge --ff-only to_be_merged
> > git push apache master
> > git branch -d to_be_merged
> > git branch -D topic_branch
> > git push apache :topic_branch
> >
> >
> > Having a merge commit is a bit annoying IMO, but you do end up in the
> same
> > state if you use them, and there are fewer git commands to type.
> >
> >
> > On Thu, Feb 21, 2013 at 12:02 PM, Becky Gibson <gibson.becky@gmail.com
> > >wrote:
> >
> > > I am trying to merge a fix from someone else into my branch that I
> > created
> > > off of the apache/next branch:
> > >
> > > git checkout next
> > > git pull apache next
> > > git checkout -b cb2411
> > > git remote add foo <address>
> > > git fetch foo
> > > git merge foo/branchName
> > >
> > > Why does git want to create a new commit when I do the merge?  It
> > > immediately prompts for a commit message and gives me a generic message
> > > about merging?
> > >
> > > The only way I can get the code into my branch is to use cherry-pick
> but
> > > since the branch has two commits this results in two separate commits?
> > >
> > > Is my only choice to rebase interactive and squash those commits?
> > >
> > > I'm just trying to keep the original author. This is a fairly simple
> > commit
> > > and should not require any merging.
> > >
> > > I'm happy to read more docs about git but to be honest, most of it
> makes
> > my
> > > eyes glaze over!
> > >
> > > thanks,
> > > -becky
> > >
> >
>

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