cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: [1 of 15] commits
Date Thu, 04 Apr 2013 16:54:29 GMT
+1

On 4/4/13 10:35 AM, "Michal Mocny" <mmocny@chromium.org> wrote:

>With all the use of "merge" and "rebase" here I wasn't 100% clear what we
>were advising.  After some discussion, I think the consensus is that:
>
>1. Rebase your branch with master (this changes only your branch, so that
>you apply work on top of most recent master commits)
>1b. Rebase your branch with itself with -i to squash commits (to merge
>work
>into single atomic commits)
>2. merge --ff-only your feature on top of master now
>3. push
>
>Right?
>
>I think saying "I prefer rebase" isn't helping git noobs figure out what
>to
>rebase and that you still need a merge at the end, etc.
>
>As Andrew said, we already advice to do this on the wiki, lets stick with
>it.
>
>-Michal
>
>
>On Thu, Apr 4, 2013 at 9:03 AM, Lorin Beer <lorin.beer.dev@gmail.com>
>wrote:
>
>> 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
View raw message