cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [1 of 15] commits
Date Thu, 04 Apr 2013 03:08:56 GMT
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