cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: [1 of 15] commits
Date Tue, 30 Apr 2013 21:38:35 GMT
http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase

Interesting article.

TL;DR

- `rebase` actually messes up history chronology. It separates commits but
they're apparently not in the right order. I did not know this.
- branches should be (ab)used and favored to working on the same branch to
avoid having "Merge" commit messages.



On Thu, Apr 4, 2013 at 9:54 AM, Filip Maj <fil@adobe.com> wrote:

> +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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message