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:17:57 GMT
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