cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorin Beer <lorin.beer....@gmail.com>
Subject Re: [1 of 15] commits
Date Thu, 04 Apr 2013 13:03:37 GMT
the only way I know of to check is manually diff. What's weird is that I
received no merge conflict notification when I reverted Max's fix, it just
silently favoured my version of CDVCamera.h.


On Wed, Apr 3, 2013 at 8:25 PM, Max Woghiren <maxw@google.com> wrote:

> That crossed my mind, but I didn't know of a way offhand to determine if
> anything else was reverted.  My commit's reversion was hidden away in an
> unrelated commit that was merged.
>
>
> On Wed, Apr 3, 2013 at 11:17 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Hmm, another question - Max / Lorin, have you checked if any other
> commits
> > were reverted? (is there a way to check?)
> >
> >
> > On Wed, Apr 3, 2013 at 11:08 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > Note that we mandate pull requests to be rebased on our wiki:
> > > http://wiki.apache.org/cordova/ContributorWorkflow
> > > And we tell committers to rebase as well here:
> > > http://wiki.apache.org/cordova/CommitterWorkflow
> > >
> > > Rebasing is safe in that if you've done it wrong, you'll get an error
> > when
> > > you try to push it.
> > >
> > > In terms of git emails, rebasing does not cause spam unless you rebase
> a
> > > remote feature branch and then force push it. To solve this, we should
> > > probably just not use remote feature branches on apache's git servers
> > (just
> > > use your own github for them).
> > >
> > >
> > > On Wed, Apr 3, 2013 at 4:17 PM, James Jong <wjamesjong@gmail.com>
> wrote:
> > >
> > >> I generally prefer rebasing so that I can see / choose the individual
> > >> commits.
> > >>
> > >> -James Jong
> > >>
> > >> On Apr 3, 2013, at 2:34 PM, Lorin Beer <lorin.beer.dev@gmail.com>
> > wrote:
> > >>
> > >> > I'm leaning towards rebasing. I felt that rebasing was the more
> > >> dangerous
> > >> > option, due to the potential/power of changing history that is
> already
> > >> > upstream, but I find the merge commits annoying as well. It sounds
> > like
> > >> > whenever this happens, our list is going to get spammed regardless.
> > >> >
> > >> >
> > >> > On Wed, Apr 3, 2013 at 11:24 AM, Anis KADRI <anis.kadri@gmail.com>
> > >> wrote:
> > >> >
> > >> >> Things start to suck if everyone does it differently (some do
> merges,
> > >> some
> > >> >> do rebases). I like rebase better because it provides a clear/n
> > >> history. I
> > >> >> usually do merges because I know that most people do that as well.
> I
> > >> would
> > >> >> like to do rebase instead but everyone else has to do that to
avoid
> > >> >> problems/conflicts.
> > >> >>
> > >> >>
> > >> >> On Wed, Apr 3, 2013 at 10:50 AM, Filip Maj <fil@adobe.com>
wrote:
> > >> >>
> > >> >>> In terms of the git notification emails, merge or rebase,
doesn't
> > >> matter.
> > >> >>> Each commit that is being merged in in the case of a merge,
or
> > >> reapplied
> > >> >>> in the case of a rebase, will be sent as a notification. So
we
> lose
> > >> >> either
> > >> >>> way. Woot.
> > >> >>>
> > >> >>> In the case of rebase vs merge in terms of workflow, merge
drops
> all
> > >> >>> commits that are coming in from a branch as a single diff
and
> > applies
> > >> >> them
> > >> >>> in one go to the top of the branch you are merging into. Handling
> > >> >>> conflicts at this point can be overwhelming if you are dealing
> with
> > >> >>> conflicts from potentially multiple commits.
> > >> >>>
> > >> >>> With rebase, you are essentially "grafting" your branch to
the end
> > of
> > >> the
> > >> >>> branch you are rebasing. Each of your branch's commits are
> reapplied
> > >> one
> > >> >>> at a time to the end of the rebase branch. If a conflict happens
> at
> > >> any
> > >> >>> point during application of your branch's commits, one at
a time,
> > the
> > >> >>> rebase stops, and you have to resolve the conflicts. This
can be
> > >> easier
> > >> >> in
> > >> >>> the sense that you have to just deal with one commit's changes
at
> a
> > >> time.
> > >> >>> The downside is if your branch has diverged drastically, you
will
> > >> >> probably
> > >> >>> be dealing with these conflicts on every commit, which can
be time
> > >> >>> consuming and long.
> > >> >>>
> > >> >>> My go-to is usually rebase, as I have a better idea of how
my
> > changes
> > >> >>> modify the codebase. That said, there are times to use merge
as
> > well.
> > >> >>>
> > >> >>> On 4/3/13 1:40 PM, "Lorin Beer" <lorin.beer.dev@gmail.com>
wrote:
> > >> >>>
> > >> >>>> hmm, I was under the impression that rebasing was more
dangerous,
> > >> I'll
> > >> >>>> reassess my workflow.
> > >> >>>>
> > >> >>>> Sorry for the trouble Max!
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Wed, Apr 3, 2013 at 9:03 AM, Filip Maj <fil@adobe.com>
wrote:
> > >> >>>>
> > >> >>>> Merges are dangerous in that sense. Rebase when you can!
> > >> >>>>
> > >> >>>> On 4/3/13 11:59 AM, "Max Woghiren" <maxw@google.com>
wrote:
> > >> >>>>
> > >> >>>>> Just wanted to quickly chime in hereā€¹Lorin, your
sizeable merge
> > >> >> reverted
> > >> >>>>> one of my bug fixes (CB-2732).  Not a huge deal, and
a re-fix is
> > on
> > >> the
> > >> >>>>> way, but try to be extra careful when doing merges
like that. :)
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Tue, Apr 2, 2013 at 8:33 PM, Andrew Grieve <
> > agrieve@chromium.org
> > >> >
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>>> Sounds good. Cool graph Jesse!
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> On Tue, Apr 2, 2013 at 4:49 PM, Lorin Beer <
> > >> lorin.beer.dev@gmail.com
> > >> >>>
> > >> >>>>>> wrote:
> > >> >>>>>>
> > >> >>>>>>> hmm, likely a merge. A local commit before
pulling in upstream
> > >> >>>>>> changes,
> > >> >>>>>>> then doing a merge seems to be the cause.
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> On Tue, Apr 2, 2013 at 1:07 PM, Jesse <
> purplecabbage@gmail.com>
> > >> >>>>>> wrote:
> > >> >>>>>>>
> > >> >>>>>>>> merging most likely, set up a filter.
> > >> >>>>>>>> I commit to master, checkout 2.6.x, pull
master, push 2.6.x
> > >> >> because
> > >> >>>>>> I
> > >> >>>>>>>> want all the work I am doing in 2.6.0
> > >> >>>>>>>>
> > >> >>>>>>>> https://github.com/purplecabbage/cordova-wp8/network
> > >> >>>>>>>> Looks good to me ...
> > >> >>>>>>>>
> > >> >>>>>>>> @purplecabbage
> > >> >>>>>>>> risingj.com <http://risingj.com>
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>> On Tue, Apr 2, 2013 at 12:52 PM, Andrew
Grieve <
> > >> >>> agrieve@chromium.org
> > >> >>>>>>> wrote:
> > >> >>>>>>>>
> > >> >>>>>>>>> There's quite a bit of email spam
from both of you and I
> > wasn't
> > >> >>>>>> sure
> > >> >>>>>>>>> what caused it? Do you know?
> > >> >>>>>>>>>
> > >> >>>>>>>>> rebasing? merging? branching?
> > >> >>>>>>>>>
> > >> >>>>>>>>> Hard to figure out what actually has
changed when these
> > happen,
> > >> >> so
> > >> >>>>>> I'd
> > >> >>>>>>>>> like to figure out what causes them.
I did one recently
> where
> > I
> > >> >>>>>> rebased a
> > >> >>>>>>>>> remote feature branch.
> > >> >>>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>
> > >> >>>>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>>
> > >> >>
> > >>
> > >>
> > >
> >
>

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